The importance of letting go in agile development
The following article is a guest post to Zephyr from Rodney West, Senior Consultant and the Editorial Director at Isos Technology. Isos Technology is a partner of Zephyr and is the market leader in solving complex enterprise challenges from Agile adoption and QA to DevOps and they help teams improve quality and speed delivery.
The end of the current sprint is rapidly approaching and you aren’t close to finishing your tickets. How did things go so sideways?
We’ve all been there. There are many factors that cause tickets to be left on the table, from unexpected production P1s to personal emergencies to your trusty laptop deciding it needs to be reimaged/replaced/exorcised and it won’t take no for an answer.
I’m going to focus on one of the areas where I see Agile developers falter, whether green college graduates or industry experts with over a decade of experience: not knowing when to let go of a ticket.
As a generalization, software engineers are puzzle solvers. Dump a box of puzzle pieces in front of a software engineer, and their hands start working of their own accord. Leaving the puzzle incomplete causes anxiety and a sense of failure. While this thought process is a benefit when developing software, it can be detrimental when letting go.
I have seen three common problem areas: (1) prioritization (2) fear (3) pride.
The biggest issue is one of prioritization. I am speaking about both the importance of specific tickets and overall time management. Once tickets are doled out, developers often focus on one or two tickets they deem to have the highest priority. This is a good thing, and is something developers become better at as they progress in the field.
The problem arises when these choice tickets take more time than was originally budgeted for. Whether the result of greater complexity or “being in the zone” and losing track of time, the end result is other tickets suffer. Depending on the number and importance of the other tickets, this may be a minor issue or a more impactful threat to the sprint.
Mitigating this early can be accomplished through continual clock management. Pay close attention to how long a particular ticket is taking. If you are reaching the end of the estimated time and you “just need an extra hour or two”, look at the other pending tickets. Decide if the current ticket is actually higher priority than pending tickets and how they will be negatively impacted. You MUST be willing to set aside the ticket you are currently working on.
If the ticket is much more complex than originally estimated, perhaps it should have been multiple tickets from the start. Be prepared to break up the ticket into less complex parts. This will often allow you to reach a stopping point on the portion(s) of the ticket you have already completed and reprioritize your other tickets.
Fear is the second factor I often see as an obstacle in letting go of tickets. Developers are often afraid to admit a ticket is beyond their capabilities. This is more prevalent in junior developers, but it can affect developers at any experience level.
As developers, we are supposed to be able to research and solve any-and-all problems tossed on our plate. Admitting you can’t solve a problem feels like saying, “I can’t do my job”. Most developers I know are affected to some degree by imposter syndrome, and fear of “being found out” is a huge roadblock.
A developer who is afraid to admit they are unable to resolve a ticket puts other sprint tickets at risk. Fear can also prevent them from asking other team members for help, missing out on insights from someone who may have encountered the issue before or who has expertise in the area.
The third factor that can put the tickets in a sprint at risk is pride. Maturity as a developer comes more effective use of time and broader expertise. This easily translates to, “there’s no problem I can’t solve and I don’t need any help”. While confidence is good, overconfidence is very, very bad. This may be a bucket of cold water, but just remember, “you don’t know everything, you can’t solve every problem and everyone needs help sometimes”.
Pride keeps developers from asking for help from someone with more expertise. It easily leads developers to spend far too long going down the wrong path because they refuse to admit that their assumptions are incorrect. This results in holding on to tickets longer than is healthy.
As a developer it is important to know when pride is keeping you from letting go of a ticket.
Fortunately, the Agile process has a built-in balance for these issues: the daily SCRUM. During the SCRUM other members of the team can help with all of these issues, providing technical input and guidance. Project management can and should identify roadblocks and aid in ticket prioritization. The key is communication. Let your team know what is going on and be ready to let go of tickets when they are not in the best interests of the sprint, project and team.
Author Rodney West: Rodney West is a Senior Consultant and the Editorial Director at Isos Technology. He has over 17 years of experience in Software Development, Software Architecture and Technical Leadership in a wide range of industries. His approach to software development focuses on the interaction between corporate culture and development processes in the delivery of software.