Rescuing Agile projects in distress

With the current trend of large organizations struggling to adopt flavors of Agile, one often encounters Agile teams in distress.These teams find it difficult to work in a sustainable pace and deliver predictable results to their customers. Bringing such teams back on track is an interesting challenge faced by Agile practitioners all over the industry. Being an Agile Coach in such an environment can be quite overwhelming and it is important to iterate through the steps intended to bring the project and team back on track.

Definition of DONE

The team needs to have a clear definition of DONE for stories in the project. A story is DONE and accounted for, in the velocity of an Iteration, only if it is accepted by customer. In teams which are plagued with various issues, this definition of DONE often gets compromised. Teams tend to call "Development Complete" or "QA Accepted" as DONE. Both of these only allow sub optimization of the value stream and it is better for the team to move towards "Customer Acceptance" as DONE, as soon as they can.

Minimize work in progress

An incremental backlog of "In Progress" stories starts getting built, when a team does not achieve the same velocity as what was being planned for. Before you know this backlog becomes huge and unmanageable. A lot of stories often tend to get stuck in the QA phase with a lot of bugs. If stories do not follow INVEST principle, QAs also.find it difficult to test these stories. Stories might get stuck in development for a long time, if developers on the team are busy cleaning technical debt as a part of a functional story.

It is extremely important to stop the line and fix some of these problems, by doing all it takes to get the stories "In progress" to "Customer Acceptance" before signing up for new work. If you have a huge QA backlog, try and understand the root cause of it. Is it because QAs are not getting good builds to test on ? Or is it really a capacity issue ?

Bring in Scope Control

Controlling changes in scope at all times is important to ensure that the team is working on stories which provide the maximum business value to customers. Sometimes teams struggle with this because they are dealing with product owners who defer any commitment, either for signing off story narratives, or accepting a story in a build. Product Owners (Customers) should be made to understand the scope of each and every user story during release and iteration planning.

In a situation where there is lot of change in requirements, introduce a release level baseline of stories. Create a light weight change control with a group of people who approve any changes to the release baseline. This board should include at least one stakeholder who is responsible for the cost/budget of the project, along with a lead business analyst from the team. This ensures changes are well accommodated into the release plan before they are developed.


Prioritize bug fixes

A common smell with too many bugs is prioritization. Almost every bugs ends up being critical, and hence triaging bugs with customers on a regular basis becomes essential. This ensures that the team is fixing only bugs which add maximum business value considering limited development capacity. It is also important that enhancements are explicitly called out and not buried as bugs. This should also happen during the daily triage of bugs.

(Fixing the Criticals and Highs is more important)

There is a good chance that if a team is running behind schedule then there might be a lot of bugs being introduced in the system. Analysis of these bugs more closely should yield patterns such as fragile areas in the codebase, lack of unit tests, tricky UI issues etc. which could be primary causes of these bugs. It is important that these causes are talked about regularly in standups and unit tests written to cover the issues wherever necessary. Fragile areas also highlight technical debt in the codebase which should be prioritized and cleaned up.



Prioritizing technical debt in the codebase

Technical debt slowly starts getting accumulated when refactoring areas of the code is deferred due to project pressure to deliver functional stories. If this continues for longer, it begins to hurt the team by manifesting itself in the form of bugs and longer development times for stories. It is essential to start prioritizing technical debt and playing the higher value tasks every iteration. Technical leads within the team can help with this prioritization and bring to the table technical stories that can be played during the Iteration planning meeting. Awareness about this technical debt needs to be created by writing on big visible charts, talking about it in standups, and by even conducting group refactoring sessions.


Regular Status Reporting

When a project is in distress, everyone is concerned and wants to know where the project stands almost everyday. It is vital to provide this level of visibility to customers, especially when they are paying for it. One needs to constantly provide information of the risks and issues impeding the project and the way the team proposes to deal with it. If the team's velocity is low for an iteration, it is important for the customers also to understand the reasons behind it. This ensures that the customers and the delivery team work together as a unit towards a common goal,and eliminates any uncecessary friction.


Continous Integration and Automation

It becomes all the more important to keep the Continuous Integration system stable and running when a project is struggling to be on schedule. Discipline around not checking in on a broken build and periodically cleaning up the build files to improve build times go a long way in eliminating delays for the team.

It is also important to run a suite of Automated functional tests that ensure that the application is not broken with any checkin. A small set of Smoke tests can be identified by the team that can cover the breadth of the application. An exhaustive suite of regression tests can also be run periodically to minimize manual regression efforts.



It is always the people

It is always the people in the team who make it work. You always need a highly motivated set of individuals with a strong resolve to pull things through difficult times. If you are a PM/Coach, it is important to constantly talk to people in various roles in the team and continuously set expectations for the near term. It is also key that people in all roles work together as one team. The mythical man month still holds good in an Agile project and adding more people later in the release will only delay it even further.