Overview: Panic is never good, but proper preparation can keep it from seeping into your Agile sprint planning meetings. Use these 7 tips to help plan properly and avoid panic.

At times, Agile sprint planning meetings can cause panic, and that’s never a good thing. One example is when items aren’t defined clearly enough—it becomes difficult to allot stories when they aren’t clearly understood. Agile development is by nature fast-paced, but if planning is done right you shouldn’t be in a situation that leads to panic. Here are 7 tips you should consider to avoid panic at your next planning meeting.

1. Schedule a mini-refinement. If research will be completed right at the planning meeting, schedule a mini-refinement meeting a day or two before the planning meeting to discuss dependent stories based on current knowledge. If things substantially change before the planning meeting, you can adjust then.

2. Don’t over-refine. Know that you won’t have every detail worked out. Sometimes you don’t know until you are deep into it – there can and will be surprises. Stories do need to be well –refined, but realize that they will never be totally refined and not all questions will be answered. Be efficient and refine just enough to commit to the work.

3. Refine with the likely path. “Pencil in” the way you currently feel it will be and adjust if things change. Granularly refine. That is, refine all the stories ahead of time to the best of the team’s ability and continue refining the more you learn about the dependent stories.

4. Refine what you know. Consider breaking stories into subtasks and refine the ones you know, leaving the questionable ones to be filled in later.

5. State the things that are unclear. Talk about the “elephant in the room;” point out the items that are unclear and match them with the stories that will provide the answers. That way, when it gets down to the mini-refinement, you can refer to these stories.

6. Research and code. Sometimes it’s better to apply a hybrid approach. Having them together means that you avoid the lag that’s associated with starting another story. If you do this you might want to schedule a quick review before turning to coding.

7. Establish checkpoints. If certain criteria should be met before you go to the planning meeting, then it’s a good idea to schedule checkpoints to keep the criteria aligned. Scheduling a checkpoint during sprints where a story may block future work allows for quick exchange of thoughts which prepares the development team and reduces panic during the next planning meeting.

You do need to thoroughly refine but sometimes schedules won’t allow you to refine at a set interval. We recommend that you take a step back and understand that the process is iterative, and each cycle produces its own piece of the puzzle. You can’t pause progress to meet the ceremonies, but you can work toward a balance. Adopting these practices will help you to produce more, with less refinement panic.

Overview: When finding a previously unnoticed bug you may feel compelled to fix it before moving on. But there can be unintended consequences to doing so. Before making any changes, speak with stakeholders and determine if a fix is necessary immediately and the consequences of such an action. And be sure to document what you’ve done!

We have all been there: you’re deep into code and find a bug that has not been noticed before, or some code that should be cleaned up. You are right there so why not fix it? Sometimes the answer is yes, it makes sense to fix it then, following the old backpacker’s mantra of leaving things better than you found them. But other times the answer is no. How do you decide?

Here are some questions to ask. To proceed, the answer to each must be favorable.

• Will this prevent you from meeting the requirements of your Sprint commitments? Will this push you over the allotted time?

• Do you have a high level of confidence in your understanding of the code and that your change will not cause any side effects? Is it better for you to do this now rather than having someone else to do it later as a bug fix?

• Should time be spent now to fix this? Speak with the Product Owner to set priority, there could be other things which are more strategically important.

• Are you the one to fix this? Should this be put on the team and allotted to someone else? It could be that they have better skills in this area or the reverse; this could be a suitable place for someone to expand their skills, improving the team.

• Can the fix be easily tested, particularly using automation? Does it require any complex configuration in order to reproduce?

• If this relates to UX, can you make this change now without the time for feedback on your solution?

Discuss and Document

Sometimes a second or even third opinion helps. You can provide a demo to the important stakeholders to gauge their opinion and how they prefer this problem be fixed. Stakeholders could include the Product Owner, quality assurance (QA) and user experience (UX) teams, or even your fellow development team members. If the bug was introduced recently and it is possible to talk to the person who wrote the code, they may have a unique perspective on how to fix it.

If you do decide to fix something “while you are in there” make sure that this is carefully documented. Do not try to cut corners to keep your time commitment by forgoing UX, comments, documentation, and testing. Failure to do so will end up causing more problems in the future. Do not forget that there is a code review.

Preparing for a Future Fix

So, what do you do with things you cannot fix in your sprint? Create the reports in your issue tracking tool and document them thoroughly. Document why you thought it was a problem. If you have a suggested fix, lay out why you feel it will fix the issue and point out any questions you may have about your approach. Also, keep in mind that fixing legacy bugs may have unintended consequences. This could mean adding more bugs than you are actually intending to fix or that users have created a process that accommodates the current behavior.

On that note, if you feel that it should be fixed sooner rather than later, before the release deadline, then it might be a good idea to speak to the stakeholders involved such as the Product Owner and UX team in order to relay that a fix for this bug is required. This then allows the Product Owner to plan ahead of time and re-shuffle any upcoming sprint commitments, if needed.

Establishing Guidelines

There is a balance to leaving things better while still meeting your commitments. This will not happen naturally; it will need your attention and the cooperation of your team. If you feel that the process is not well-nurtured amongst your team, then reach out to other developers you work with and see how they feel about this topic. By not having team guidelines related to this slippery slope, you may be increasing the list of tech debt items or slowing down your sprint velocity. Consider what guidelines you personally follow and let those spark a discussion with your teammates.

Overview: Commenting on code can seem like a chore but documenting changes and their purpose is key to helping others understand your code. These five rules serve as a handy guideline to help you make the most of your comments and make sure they’re seen and understood by others.

Mention comments and documentation to a group of developers and you are likely to get a “heated discussion.” Documentation may be a good concept, but it is rarely even done, let alone done right, and can never be expected to be fully up to date. When we get to comments, it seems to be more a matter of degree. We see the need, but how many should we put in and how much should we have to rely on them?

If you struggle with commenting, you are really struggling with your logic.

We suggest following these 5 simple rules to form a guideline for using comments.

1. Your documentation should reside in your code, not outside. Having the documentation in the form of comments means that it travels with the code. There won’t be any hunting for it or questions about whether it is the latest. The only exception to this rule is when documentation on the usability of the software is written. This can reside outside the code, in the form of a Confluence page, development manual page, etc.

2. Comment on the line close to action. Comments need to be right where the code is. You shouldn’t place comments lines above and expect someone to find it or realize it is related. When an update is done on a line, if the comment is far away, the comment may not be seen and therefore not updated. Keeping the comments and lines together makes understanding the code faster, and the comments are more likely to be current. It is important to remember that Integrated Development Environments (IDE) do not correlate comments with their corresponding code counterpart, hence why the location of the comments is important.

3.If logic relates to another section of code, comment there to relate. Something in the section you are in may have an impact in another part of the code. You need to form a bridge to make the connection visible. Building in impact analysis could actually point out problems with your code. If you feel the need for a lot of these comments, your structure could be bad. If your comments are trying to explain the code, then that simply signifies a need to refactor. If the code structure is already well established and refactoring cannot be done, it is important to comment on the way it should function when the refactoring is complete. This helps future developers understand why code smells exist.

4. For automated testing, a general rule is to leave comments in relation to what that test will do. If an automated test fails, then the individual in charge of maintaining these tests can use the comments to debug the primary process of the test and figure out what the issue is, minimizing the time to debug the issue. Comments give you the opportunity to search for keywords in the future and help you see where the code has deviated from the workflow of the given test, and whether the test case needs to be changed to reflect that. Write the general sense of what the test will do. Link your tests to the code, not the other way around.

5. Pay as much attention to the comments as to the code. Don’t make comments an afterthought, don’t ignore them in code reviews, and most importantly, continue to update them as the code continues to change.

It can be easy to overlook comments because of the concentration on code, but they are important. Following these five rules can help you make the most of comments and treat them as what they are-an investment in the future.

Overview: APIs provide access to valuable mainframe data, but deciding whether to add to an existing API or create a new one can be a difficult task. Evaluating a variety of factors can help make it easier to determine which option makes sense.

As applications evolve, they will often need access to data and processing on the mainframe. If the necessary APIs are available, this becomes an easy task, however the architecture isn’t always there, creating a roadblock. Teams are faced with choices on how to deliver value quickly and set up the architecture to address future challenges.

Assuming you have calls that may not deliver all the information you need, the choice is whether to add on to the existing call or produce a new call. How many calls should you have to do? When does it make sense to take the development time to make just one call? Conceptually speaking, one must look at the structure/design and make decisions based on what is already in place. Questions may arise, such as which applications are currently using this API and how changes will affect them. On that note, one must also keep in mind the complexity of adding additional APIs, whether it is on the side that is consuming the API or on the opposite side that is producing it. Your goal may be to always have just one call for information. That might be desirable but isn’t always necessary. Don’t let this desire for one-call purity stop you from innovating.

Just because it isn’t “right” doesn’t mean that it’s “wrong”.

In most cases, you will find teams extending an existing call, in order not to expect anyone consuming the API to be forced to change theirs. When thinking of whether to go with one or multiple calls, look at the core functionality and determine whether there are cases where breaking down APIs truly makes sense or whether a single call is enough. Always think about the future.

There is a lot that goes into this decision but considering the following factors will help you to make the right decision.

When you should take the time to streamline it with one call:
• When it’s frequently used – putting this in place will open up many more uses. Instead of duplicating the API work on the front-end, the front-end can just call the API to handle most of the work. Thus, reducing code duplication and bugs that may be caused by changing the behavior in one place and not the other. One centralized location that fits the needs of every API call.
• Performance – adding simple logic. If you are only adding something simple like a new field or some simple logic to an existing call, it can have better performance than creating a new call.
• Saving development time – putting it in now could save much-needed time in the future. If you see that soon there will be a request for an API call that handles everything, then it might be worthwhile investing the time to do it right the first time.

When you may be able to use more than one call:
• When time is of the essence – there is a critical need right now. We’ve all been here before, the so-called software dilemma where we need speed, quality, and features… now pick two. Sometimes the picks are speed and features and there isn’t much time to perfect the API.
• If the API is not used a lot – when it’s a smaller cog in the machine. Going back to the software dilemma, in this case it’s like picking speed and quality. It may only introduce a small number of features that will not be further expanded in the future.
• When testing a prototype in the field – testing with users gives feedback and time to respond. Create something quick that can be streamlined later down the line. Feedback on the flow of work is more important here than low-level process of the API.
• If separating the API calls – it may allow for a modular approach, where in future work, using only a partial number of the calls may be needed. This is more common than you’d think. Especially dealing with large amounts of data, it may be better suited to break the API into parts.
• Performance – dealing with distinct operations. Performance on the back end is usually better than on the front-end, especially dealing with any CRUD (create, read, update, delete) type operations. Creating a call for each operation will perform better than having a call perform multiple operations.
• When a part of the API will eventually be replaced – if there are cases where there is a temporary solution in place, then it may be wiser to create a separate API for this temporary part of the call so it can be replaced in the future without causing further issues.

Expanding mainframe usage is important but can be daunting—don’t let it be. Sometimes getting something now is better than nothing. Incremental improvement based on feedback is what Agile is all about. You can use this as a guide for your developers in how to approach these decisions. The important thing is to innovate and extend the value of the mainframe for the benefit of your users.