Agile Development Hell: 3 warning signs

Agile Development Hell: 3 warning signs

Let’s let a look at some specific warning signs that tell us when a project is heading for significant problems…or is already there.

Thomas is already in it.

1.  Unchecked growth in the Backlog

Unchecked growth can refer to estimates wildly outside of the scope project, endless new and incomplete additions in the backlog or just sheer volume of entries. The backlog is intended to be the vision of the project, generally in user story format with a focus on goals that relate back to the key features that define the project. The backlog is also where initial estimates appear to start sizing out features and development work which help bring clarity to the scope and capacity necessary to complete a given feature. Once the project begins the purpose of the backlog is to track development work and to flush out unexpected work that must be added to the backlog to complete the project successfully. Typically there are scope and capacity limits that have been carefully determined for the project in relation to its original scope. If the scope of the project grows in the backlog without regular grooming you have a traditional scope creep problem.

Without intervention in the form of direct action to redlining your backlog you will lose the ability to meaningfully track your project in the backlog. It will become a mismatched listing of half-finished features, new ideas and work that will never be complete. Without the ability to track progress in your backlog, you will turn to extreme reporting.

After going over the reports the Bob’s would like a word…

2.  Extreme reporting

Reporting is an important part of the feedback loop for the managers and team members. It serves to help monitor and track progress in a number of ways and can help you gain valuable insight into different aspects of your project, especially when you need to determine if corrective actions are required when things start to derail. When you can’t track your backlog proactively, you often turn to reactive reporting. And the worse things get, the more the project gets behind and confusion mounts on priorities and dependencies, the more reports you begin to run. Reports can help show you where structural deficiencies are in your process, which can help you prioritize getting your backlog back in order, re-evaluating your sprint commitments or looking at the skillset composition of your teams. 

The big danger here is that you use reports to start running your project through a triage workflow that resembles the way you work with bugs during an alpha/beta process. Instead of looking at the big picture and planning your development strategically, you are now concentrating on the very immediate short-term priorities in an effort to get the project back on track. But with short term planning and triage-like workflows the problems will keep piling up. The thing to remember here is to use the reports to target structural and procedural problems in your production management process and to make them your highest priority to resolve. Take a look at the basic execution of your project and reinforce the areas that are failing to get the job done. You need to know exactly why you measure what you measure and what decisions you are going to make based on the issues you track. In fact, everyone involved in the metrics-gathering should be very clear of this so that people are: 

Remember that reporting can be a huge hindrance to a project if you are constantly measuring metrics that do not address your core development problems.

Of course you will fit. What could possibly go wrong!

3.  Consistent sprint failures

Sounds fairly obvious right? If you are encountering consistent sprint failures, you are most likely not progressing well with your project. The issue here is that many development teams do not recognize sprint failure as problem. They define failure so completely and utterly that significant alterations to the sprint are considered acceptable, even when they completely move the goalposts for the sprint or make the sprint planning session redundant due to constant change.

Warning signs for concern include:

The purpose of the sprint planning meeting is to recognize sprint goals, commit stories and do some more detailed estimates within the sprint before work begins. This process is as much to guide the team through the next sprint iteration as it is to gain insight into the features you are building out. Significant failures can result when:

Recognize the root issues and address them directly, do not wait to clean up the sprint once it’s started. Proactively address the changes sprint to sprint and get the requirements nailed down. Accept that velocity is designed as a measure of organic team progress that is invaluable. If used properly it gives you a realistic understanding of your team’s capacity based on actual effort. If abused it can be used against the team to ungratefully load them with more and more work, until agility is lost and sprint failure is inevitable.

Though there are certainly many signs your project could be headed for trouble, these are three of the top issues encountered working with developers.  If any of these issues describe your project or sound very familiar, you should probably sit down and re-evaluate what you are trying to accomplish on your project and how to plan to get there.