3Back Team Blog

You Don’t Do the Agile Process You Are the Agile Process

Saying it this way puts and emphasis on starting with self and looking inward before blaming outward.

For an agile process to be successful, and probably any process at all, it must allow some focus on people, passions and teams working together.
• Without an aim we have no purpose and not much of a reason to be a team. When we have that product aim we can test our ability to work together by looking at the results of our product development effort.
• Without a focus on people we often on mechanics of the process to the exclusion that people matter.
• And without working towards our passions we fail to ignite the energy within ourselves and we fail to contagiously spread our enthusiasm to others around us.
When we properly include the above three in our line of vision and don’t fall prey to using a model of software development that is so complex there is no room in our heads for the above three, we can win BIG time. What we focus on matters and if the process is so complex there is little room to think about anything else, then we loose.

A recurring pattern, that we have observed in large scale adoption of Agile “The Pursuit of Enterprise Agile” . Is a successful pilot that really focuses on the people working together.

Typically, organizations get started by contracting with outside an outside expert who advises them how to start agile. The advice is typically some setup a pilot that will be small enough to influence yet important enough to keep attention focused. The idea behind a pilot is simple, “Let’s setup a little experiment with this thing called agile and see how it works out for you?” After a business case review or senior leadership buy-in, the pilot is set up with an appropriate amount of autonomy.

Usually, an internal person is to be part of the pilot and run it. That person is charged with setting up the pilot and documenting their observations so that the organization can learn. A team is formed, trained and started down the agile path. The team works shoulder to shoulder with an on-site agile consultant who demonstrates the habits and values of agile while in motion. Often the team quickly emulates the behavior and then falls into a rhythm of product development and delivery.

Then someone “process experts” typically take the observations of the people working together and abstract them. Now things really get whacked. The process expert believes they can take observations of the pilot and fold lessons learned into the enterprise methodology view. This is a too “hard problem” we have been trying to do this for years and are still in our infancy for understanding basic communication. However, based on what is written and documented in classic process literature you would be lead to believe we have evolved far more than we have.

After organization have absorbed the lasted round of process learning into their enterprise methodology. The very real skills and valuable team behaviors that were gained are lost. The next agile effort looks very much like the old process the organization ran before just with new words and language. The part that made the pilot effective is lost.

That is why “You Don’t Do the Agile Process You Are the Agile Process” works so well as a phrase. It constantly reminds me that agile starts with self.

People, Passions and Teams must be elevated above Principles, Philosophies and Practices. Without the first three the last three will not matter.

Perfect Planning — Best Practices for Successful Agile Planning
written by Guy Beaver

A successful sprint starts with the planning session. This is where the team reviews the work about to be undertaken, and after a few hours of questions and answers, estimates the work required to complete the user stories reviewed, and then as a team, commits to a prioritized list of stories and tasks that are within the team’s calculated capacity. This light set of procedures is well documented in Scrum and Agile literature [1],[2], but included here are some observable traits and best practices that have been found in well-formed, hyper-productive Agile teams.

A well-formed Agile team establishes an intangible sense of rhythm, and enjoys the transition time between iterations or sprints. This period provides closure for work completed, and anticipation of new work. Ideally, the Agile planning session should follow a demo and retrospective (all in the same day), to give the team a chance to celebrate, reflect and get better. Sprints should be consistent in length to help the Agile team develop this sense of pace. An experienced Agile Leader understands that shorter sprints (10 days is ideal) are much easier to plan & estimate. Longer sprints (> 10 days) tend to allow teams to decrease the sense of urgency during the first several days, and it is more difficult to contain and understand total scope than shorter sprints. In Complex Adaptive Systems [3], rapid feedback is critical to convergence.

The purpose of the Agile planning session is to present a collection of user stories to the team and allow them to be estimated. This is where the team effort gets aligned with business direction, and is the essence of the Agile phrase let the product lead. At the end of the session, the team should feel committed to completing the work required to implement the agreed-upon list of user stories during the next sprint. An information radiator [4] should be loaded and prioritized with the sprint backlog of stories, and the team ready to begin the next day with Daily Scrum for day 1.

A well-formed Agile team has a product owner who is prepared for the planning session, and ready to present sprint goals and a prioritized list of stories for estimation by the team. This prioritization has a rhythm all its own, as the product owner should review the product backlog frequently so that stories are staged and ready-to-go for planning sessions based on the latest business priorities. A best practice that helps make this happen is to visibly display the product backlog close the the product manager’s office, so that he/she can has a constant reminder of the upcoming prioritization [5].

A well-formed Agile team has a product owner who can clearly state the Vision (why the Agile team exists) and can formulate clearly the goals for each Sprint [5]. This clearly stated vision and sprint goals should be used to begin the sprint planning session, so that guiding principles can be applied to each story considered for estimating. New stories are typically unfolded as the team asks questions of the product manager during the planning session.

The Agile Leader calculates the sprint capacity by assuming each team member has no more than 6 hours to commit per day. This buffer prevents the team from being over-committed, and is a responsible approach for accounting for distractions. This helps enforce the Lean Software Development principle “Limit work to capacity” to ensure that the hyper-productive state is sustainable.

The Agile Leader is focused on setting the Agile team up to be successful in creating business value during the sprint being planned. The Agile Leader creates an environment where each day is seen as an opportunity to close stories, and visibly see daily progress in the Agile-V [6], reinforced by a satisfied Product Manager. New Agile teams typically have questions of how to handle time away (vacation, training, etc). A well-formed Agile team is extremely tolerant of team members’ vacation and other time-away needs, as paired programming and role-sharing prevent silos of code territories to build up. When a team member is away, the well-formed Agile team can easily adjust and continue creating business value.

Determining the team’s capacity is critical to a successful planning session. This should be the first activity in the planning meeting. Two best practices for determining the team capacity are:
1) The total capacity of the team should be based on the number of team members times the number of days in the iteration times (no more than) 6 hours.
2) Start the planning session by establishing who has vacation time planned for the upcoming sprint, and capturing that information in a vacation story. The vacation story has tasks for each team members’ time away, which account for some of the team’s capacity when stories are being committed. As the sprint progresses and the vacation days are hit, the burn-down chart reflects these time-away tasks being completed along with any other tasks. This prevents the burn-down from falsely indicating a problem.

For example, a 5-member well-formed Agile team is planning a 10-day sprint. The capacity of the team is quickly established to be 5 members X 10 days X 6 hours per day, which gives a capacity of 300 hours. The ideal daily burn-down becomes 30 hours. If 4 team members attended training during day 1 of the sprint, this can be easily accounted for by creating a time-away story that has 4 tasks, each with a 6 hour estimate. These tasks get completed on the first day, so the burn-down chart correctly shows the time burn-down.

The Perfect Planning session can be summarized in the agenda below. Try variations of it to plan your next sprint:

9:00-9:15 Daily Scrum (last scrum of ending sprint–discuss any unclosed stories and agreement on how to handle)
9:15-10:00 Demo of stories delivered over the course of the last sprint
10:00-10:15 Break
10:15-11:15 Sprint Retrospective (what worked well, what can work better)
11:15-12:15 Lunch
12:15-1:00 Determine Vacation and establish Team Capacity for the planned sprint
1:00-2:00 Visioning (Product Owner presents: Review OBT, Discover Sprint Goals, Discover Roles. Product owner presents each story in priority order)
2:00-4:00 Team reviews stories, creates estimated tasks for each
4:00-5:00 Team commits to chunk of stories to Product Owner, ready to start daily scrum tomorrow

A purely Lean view of the Agile planning session sees planning and estimating a batch of stories as waste. Dave Anderson and Rick Garber (both of Corbis) gave a great presentation at the Lean Product Development Summit [7] where they demonstrated a pure Kanban implementation for software development that had no planning or estimating, and pulled stories in as capacity freed. This approach has the obvious potential of further raising productivity for standard Agile processes. For some situations, the pause between sprints allows teams to celebrate and catch its collective breath while the retrospect provides feedback required for convergence of the complex adaptive system. It would be interesting to take a well-formed Agile team, and migrate it to pure Kanban to see what productivity gains could be realized. I think for new Agile implementations, the light rules of Scrum with Agile/Lean principles provide a proven transition to Lean Software Development, however the beauty of the principles behind Lean and Agile dictate that the best implementation is one that can inspect and adapt. The Corbis implementation of this Kanban approach reinforces the application of situational agility, and I’m grateful for Dave Anderson and Rick Garber for illuminating this so well in their presentation.

References
1. Agile Project Management with Scrum, Ken Schwaber
2. Agile Estimating and Planning & User Stories Applied, both by Mike Cohn
3. Agile Management for Software Engineering (chapter 2), by David J. Anderson
4. see Information Radiator, Alistair Cockburn
5. see Eye on the Prize: Best practices for Aligning Agile efforts with business goals
6. see Agile-V Scorecard
7. see A Kanban System for Sustaining Engineering on Software Systems, by Dave Anderson & Rick Garber