Exercises in Agile Discipline

In my previous post I wrote about how one of the primary things lacking in teams floundering with their attempts at Agility is a lack of discipline. I also linked to articles on two particular disciplines: Timeboxing and Feedback loops.

In reality, every process part of Agile Delivery can be thought of as applying a timebox, setting up and using feedback loops, or a combination of both. The timebox and the feedback loops are the mechanics by which we traverse problem domains in an Agile manner. Problem domains can be delivery of a product (software or other), organizational transformation, team or self improvement, holding a party, or any other problem complex enough to be broken into steps, but also vague enough that the understanding of the constraints around successfully solving it will change over time until the time of the completion of the solution.

Every timebox should be defined as the shortest amount of time in which to produce a meaningful result. By meaningful result we want to focus on:

1. Delivering requested value,
2. Coming to a better understanding of what value to deliver next,
3. Coming to a better understanding of what value remains to be delivered, or
4. Coming to an understanding on how to better do the first three.

Feedback loops are essentially a series of timeboxes in which one of points 1-3, as well as some information about point 4 is gleaned from each timebox and fed into the next in the series.

In another prior post I compared using these disciplines to the use of footwork in a martial art. In the fencing salle, footwork is so important, so foundational, that we have had new students spend at least a month doing nothing but footwork before they were even allowed to touch a weapon.

If timeboxing and feedback loops are such foundational disciplines in Agility, we should all be rigorously exercising in using them. To that end, I propose the following challenge exercises. These are simply suggestions of where to apply the disciplines, not a complete exercise regimen. You can choose to do one, some or all of them and in whatever order you deem appropriate. Better yet, come up with your own regimen from these or other exercises and post it here for others to try!

• Pick some chore or home project you are having difficulty finishing and set aside a timeboxed amount to work on it each day for a week (notice, the week is itself a timebox). Assess your progress after each session and at the end of the week.
• Pick some chore or project your kids are having trouble finishing. Have them determine the timebox for each incremental progress. You facilitate the assessment at the end of each increment and the end of the week.
• Try using the pomodoro technique at work or at home.
• Take one of your agile ceremonies or meetings on your team and try to make it more effective using timeboxing.
• Apply timeboxing to breaking down large stories.
• (This can be done individually or even better, as a team exercise) Make a list of all the time-boxes your team is employing - whether consciously or not. Now, from this list, make a list of all the time-boxes where feedback could be collected but is not. Pick the most impactful missing feedback timebox. Start tracking the feedback from this timebox and discussing it before the next subsequent, related timebox. See if performance improves from loop to loop over time.

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:

• http://agileatlas.org/articles/item/metrics-for-a-scrum-team
• http://www.leadingagile.com/2013/07/agile-health-metrics-for-predictability
• http://salhir.wordpress.com/2011/09/18/agility-health

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:

• http://redpoint.github.io/RedpointWay/feedback_loops.html
• http://redpoint.github.io/RedpointWay/time_box.html

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:

• http://agile.dzone.com/articles/%E2%80%9C-4-questions%E2%80%9D-retrospective
• http://agileretrospectivewiki.org/index.php?title=Retrospective_Plans
• http://redpoint.github.io/RedpointWay/retrospectives.html