Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

The Importance of Letting Go in Agile Development

DZone's Guide to

The Importance of Letting Go in Agile Development

Be ready to let go of tickets when they are not in the best interests of the sprint, the project, and the team as a whole.

· Agile Zone
Free Resource

See how three solutions work together to help your teams have the tools they need to deliver quality software quickly. Brought to you in partnership with CA Technologies

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 or replaced or exorcized 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 they're 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: prioritization, fear, and pride.

Prioritization

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 of a 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

Fear is the second factor I often see as an obstacle in letting go of tickets. Developers are often afraid to admit that 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.

Pride

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.

Conclusion

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.

Discover how TDM Is Essential To Achieving Quality At Speed For Agile, DevOps, And Continuous Delivery. Brought to you in partnership with CA Technologies

Topics:
agile ,sprints ,scrum ,development

Published at DZone with permission of Francis Adanza. See the original article here.

Opinions expressed by DZone contributors are their own.

THE DZONE NEWSLETTER

Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

X

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}