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.

Don't let sustainable pace stop you from further improvements

The classical XP/Agile view of velocity relies on a graph which indicates that the velocity of a team stabilizes over Iterations as the team goes through the cycle of Forming,Storming,Norming and Performing It is also an indicator of team achieving sustainable pace.

A lot of Agile project managers/coaches/leads fall into the trap of sustainable pace, and stop thinking about ways to improve efficiency, one the velocity graph shows signs of stabilization. This also gets complemented by the fact that customers are reasonably happy with the velocity the team is currently achieving.

This often stops Agile practitioners from innovating and coming up with even better means to increase throughput of the team.

As an example, imagine a team merrily churning 20 points of stories in an Iteration on an average and the customers are quite happy with the progress. The team probably has an average build time of 20 mins with SVN as a source control, and most often, if this team is in this happy rhythm , it wont bother about the build time, even though there is scope for improvement there. In my previous project, we moved from SVN to GIT as a source control and it reduced our build time by 70% approx. If someone started doing this in the imaginary team with a velocity of 20 points, they can surely speedup by 5 points atleast, considering the huge number of continuous builds in a day.

Another example which I see quite often is teams getting stuck on to sweet release schedules and not striving to improve further. Sometimes a team starts of with a 6 month release cycle, takes a lot of pain and then moves to a 3 month release cycle. When moving to a 3 month cycle this team, tries to improve their processes quite a bit which can involve things like bumping up the functional test suite coverage to 80%, reducing build times etc... But very soon, the 3 month cycle becomes a sweet spot, if the customer is not demanding any further. The point here is not to reduce the release cycle even further, but do more of the optimizations you did to the build times and functional tests and maybe even more things, which will continue to cut down waste. Unfortunately once the sustainable pace is achieved, inherently the motivation to think out of the box to reduce waste goes away.

There is always scope for improvement in a team. Agile practitioners/leads should always have the hunger to make their team better. Think of building teams iteratively. The Forming, Storming, Norming model itself is an iteration at each stage where the team is getting better. But dont stop at performing. Always be hungry for more and don't stop yourself at sustainable pace.