Tuesday, October 21, 2014

3 Ways to Get Control of Your Agile Teams

Your company rolled out its Agile initiative 6+ months ago. A team or teams under your leadership received the green light to manage itself in the approved flavor of Agile (usually Scrum). Team members have attended training. The team meets every day or at least once an iteration. There has been a Scrum Master appointed to the group. Yet the project(s) worked on seem to be slipping as each week goes by. You are assured that stories are being completed, yet you have no idea whether you are going to meet the deadline, let alone what is being developed toward that goal. Your situation feels less Agile and more like Anarchy.


Dire as this example seems, it is not far off the mark for many teams and companies who have given this 'Agile thing' a go. Here are three tips used by successful Agile teams you can use to regain control of your team, its delivery of value and avoid the brink of chaos.

1) Agile Metrics.
 Despite the impression of some that Agile is just a free wheeling approach to development, the best Agile teams know that the built in feedback loops provide the perfect means to collecting tons of accurate data. Even if your teams have not implemented the tightest loops, like those around automated testing and pairing, they should be able to give you a fairly current Velocity measurement of the team's progress toward completion of the project as it is currently defined. This measurement is much more than a simple ratio of work not done to work remaining, but rather provides insight into numerous impacts on a team, including partial allocations, tech debt, changes in requirements, or lack of experience. Get your scrum master/project manager/team lead to track the team's velocity iteration after iteration. Trouble spots will become readily apparent and it will give you and the team something concrete to figure out how to improve. The team should start measuring its progress and those metrics should be openly communicated.

Here are some other metrics that you can glean from the Agile feedback loops available to you:
If your team is having trouble coming up with a velocity or their velocity is varying wildly, it might be time to empower the team to develop some:

2) Agile Discipline.
While this may seem contradictory at first, the most effective Agile teams seem to hum like a fine tuned German sports car. This is similarly achieved via a seemingly Teutonic application of discipline. However, you do not achieve this simply by broad mandate. The discipline should be applied as the team becomes aware of deficiencies. If the team is having difficulty meeting its sprint commitments and as such cannot provide a healthy, consistent velocity, the reaction is often to let up the slack... just extend the iteration. Soon iterations go from two to three then to four weeks. In the mean time evidence of progress toward the release goals is further delayed. Instead of lengthening the iteration, shorten it. Ask the team what it can commit to delivering in a week. You don't have to release every week, but the team should have produced release ready solutions in that time. Run four-to-six one week iterations and you and your team will very quickly develop a predictable velocity from which you can begin to more accurately extrapolate real progress toward completion or begin to see what other steps might be needed to improve. 
Similarly, I often see teams that have a scrum/standup every day, perhaps multiple times a day, but they are still disorganized. Efforts may be duplicated, progress and blockers may go unseen, and no one may really know how close we are to 'done' let alone what the next highest priority item to work on is. This is often due to an overloading of the Scrum. Instead of quick team sync up, they become a catch all, rapidly devolving into half to hour long design discussions, requirements gathering, bug reports or ad hoc planning sessions. Again the time-box is your friend. Have the scrum master limit the scrums to fifteen minutes. Anything not relevant to the standard team sync questions of a stand-up or scrum should be tabled for discussion after. Not only does this allow team members to get back to work, it also quickly brings to light related issues which can actually greatly improve the delayed discussions. 
Further more, set limited, regular meetings for grooming, planning, the showcase and your retro with clear outcomes for each. Grooming should produce estimable stories with clear acceptance criteria, planning should produce an estimated commitment of delivery of some of these well defined stories and the showcase should clearly demonstrate how the acceptance criteria of each have been delivered. Obviously, each requires the previous one starting with the grooming session(s). Therefore making a rule that a grooming session must conclude with a percentage of the considered stories defined is helpful. To facilitate this I have sometime even set time limits on discussion of stories. 5 minutes per story. If it is not enough the team can vote to extend 5 more minutes or to push the story back in the queue. At the very least this drives progress towards story definition. Even if a story cannot be fully defined due to externally missing information, the team is more aware of the scope and caveats of the story than they were before. Moreover, this is all documented in the even partially groomed story. The alternative is no documentation, no progress, a long discussion ending with a bunch of questions and looks of confusion on the team's faces. Worse yet, the team gets to planning and nothing is understood well enough to commit to and the planning session is postponed. 

Here are further details on some Agile disciplines:
Of course, this means that all those Agile meetings are actually important. Once they are run in a disciplined manner, their value becomes quickly evident. However, the most important of the Agile meetings/rituals is routinely the first casualty in teams floundering with implementing Agile:

3) Regular Retrospectives.
For a team trying to get into a productive groove with Agile, the retrospective is the single most important Agile ceremony. Think of it like a professional sports team taking the time to regularly watch and critique their last game. If they don't do this, all they are doing is playing game after game and improvement is almost accidental. By taking even a short bit of time to call out one or two areas to improve upon for their next game or iteration, a team makes steady, focused improvements. This can be a powerful way to eliminate the most deleterious bad habits/practices and replace them with the habits which will make your teams deliver and succeed.

More on Retros: