3Back Team Blog

Technorati Profile

This is the start of my blog.

When people consider what got them to their current market or look closely at how their competitors are succeeding they see smart, sharp, fast hyper-productive teams. They find that some organizations possess a knack for rapidly configuring themselves into a shape and deploying their hyper-productive teams to rapidly build new product capabilities. Some competitive organizations can do this within days or a few months not years. By the time a competitive analysis is completed of what the competition is doing the market is already changing and moving on. What we see is a need for continuous analysis, consumption of that analysis and a rapid deployment of new capabilities.

After peering closely at what got them to their current position of success we see a “well formed team”. It is amazing how quickly people in corporate america can forget the power that was present from these teams and what they are able to produce. One thing is clear. A WFT was at the heart of their success and everytime they try to create that magic without a WFT ideas just don’t seem to flourish.

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.

Agile is gaining mainstream acceptance. In a recent poll run by business week they ranked agile software development as item #33 (read here) in things that are shaping the business world.

This is great and seeing agile gain acceptance at this level as well as publications from mainstream places like Business Week and CNN is a huge step forward.

Why they don’t seem to “get it”
Many of the remaining trends are focused on individuals and not teams. This continues to be counter to the agile movement where brilliance is really a team commodity and that corporations are still looking for the individual to lead them to greatness. Our need for education remains strong in the area of teaching people to join teams and leverage the emergent qualities of social brilliance. In other words have a conversation that establisher a trusted report so that we get smart together.

- Doug

A colleague writes:

Over the past few weeks, I’ve been digging into links, blogs, forums using this term (Post-Agile)… Have you seen this term? Followed it’s discussions? Any comments?

…Pliant Software is another term that seems to be associating itself with Post-Agile…

I think the software world is sort of like a customer who has an idea of what they want or need, but can’t put it into words. But, and after several iterations of “Requirements Gathering”, has come out of the room with more terms and an RD that is better than it was at the start — but not perfect, yet!

(italics mine)

Yes, I have comments!

1. I agree that the newness of agile has worn off, and the immediate benefits from it have been tapped dry by many.
2. I’m annoyed at the PliantAlliance site’s claim for “a new way of thinking about developing software” — pliant sounds like adaptive to me, and Scrum has been saying this for a while.
3. While the immediate benefits of agile have been tapped, the deeper benefits that can be realized by changing the way we collaboratively build product — not just the way developers write code — have a long way to go. Before we decide that “agile didn’t work,” I’d like to see more organizations actually practicing basic agile behaviour, and I’d like to see actual practices in use catch up to the huge body of literature describing deeper agile practices.

Good Software is a craft, like smithing or theatre. There was never a school that turned out expert blacksmiths; novices had to progress from apprentice to journeyman to master. The “Fame” school doesn’t promise its graduates fame, they have to go out and earn it through experience.

Good Software is the result of human thought — not just human labor — and is highly resistant to being made into a detailed process/algorithm, or body of knowledge.

Good Software is the result of collaboration. Social Science and more enlightened ways of interacting can help, but trying to describe them is missing the point.

I understand that post-Agilists see themselves as giving a name to an existing movement, rather than trying to create a new movement. But it smacks of picking a new name for your club because one member of your club is acting silly, and people are now making fun of you: you fragment the group, you tacitly approve of the bad behavior by distancing yourself from it rather than correcting it, and you spend too much time and energy on labels rather than action.

My friend’s point is right on: the SD world is like a user with a poor Requirements Doc, who “knows what they want, they just can’t describe it yet.” Trying to describe it, trying to codify it, is ulitimately a losing game and a waste of time — just like writing big RDs is a waste of time.

Build successful, adaptive teams who can make good, useful software, point to them and say “THAT is what Agile is.”

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

It seems that the more we connect, the more we create gravity around ourselves and the things that we want to do. In my experience this is even more true for team’s that are involved in product development.
The rule at work here seems to be:
“Teams are alive as they can build meaningful connections.”
This is perhaps why I love working in the agile software community. The more I play to my strength of connecting with other folks, especially teams, in meaningful ways and adding value, then the more the universe seems to respond by generating gravity that can then be used to spur on those interests.

- Doug Shimp