As you may or may not know, I’m an active agile coach. I often get asked to enter new teams and jump-start them or assess their overall level of agile-ness. One of the ‘smells’ that I look for in a strong and healthy agile team is what I’ll call controlled chaos or perhaps a better phrase would be guided chaos.
You see, the atmosphere in these teams isn’t safe nor predicted too far in advance. The teams don’t have a false sense of security. They’re working on a short list of features in close collaboration with their Product Owner. They know that challenges will rise up to meet them. Risks will fire. Team members will get sick or get married or tend to ill parents. And the design approaches and code won’t always work as advertised.
They may or may not have the technical skills to interface with the new third party vendor you’ve just signed an agreement with. They also struggle mightily to deliver software of sufficient quality—scratch that—they struggle to deliver solid software—even though they focus on it daily.
What I’m trying to say is that in these dynamic teams—“stuff” happens. The plans shift daily and the team must respond to this landscape. To be undeterred in their commitments to sprint and release goals and to be creative and relentless in attacking impediments. Agile Project Managers need to understand this chaotic reality—in fact they need to create, foster and embrace it! Here are a few ideas on how to do that.
Don’t Ask for Specific Commitments
Imagine yourself in a canoe on a river you haven’t navigated before. You have a map, so you know generally where you’re going. You have a GPS, so you know specifically where you are. Now you get an emergency call from your boss and they want to know exactly when you’ll arrive at the take-out location. What do you say?
From my point-of-view…not very much. You simply don’t know how long it will take. You can guess and give your boss a sense of comfort OR you can tell her the truth. I’m here and my hourly rate appears to be this. My map implies the following obstacles and journey length. I think I may get there sometime between 4-5 pm.
A key here is that in highly variable and complex situations, we often don’t have a very clear idea of how long something will take. Instead, we need to triangulate to get to our destination. We’ll take daily samples of progress, looking ahead on our journey and then reducing the uncertainty as we gain knowledge, make progress, and get closer to our goal.
That’s the reality of complex systems. So the question for an effective agile project manager becomes, do you want the truth, with incremental triangulation, or a façade of absolute certainty? I think we need to emphasize the integrity of the former and support it with active team focus, high communication & collaboration, and full transparency. And leave the façade for those who can’t handle the truth.
Don’t Allow the Team to Plan Too Far in Advance
There a planning technique used in agile teams called release planning. You see it coming out of a few different methods with slightly different names:
- Extreme Programming – Planning Game
- Scrum & Jim Highsmith – Release Planning and Agile Project Management techniques
- Crystal – Blitz Planning
- Jeff Patton – StoryMapping
All of these techniques are driven towards gaining a high level, end-to-end view of your project—leading towards a release point. It turns out that they’re all incredibly useful for envisioning where your project is “going”. Let’s say providing the map in my earlier canoe example.
The danger comes when you start doing detailed planning (tasking, dependency mapping, detailed design, etc.) too far ahead. You and the team will get a false sense of comfort—thinking that you know where you’re going. But along the way there will be rapids and nasty weather that will surely knock you off course.
Trying to fully anticipate them is mostly a fool’s errand and can be very wasteful of your time. Being prepared for them and reacting quickly when you encounter them is the way to go. As an Agile PM, you’ll want to plot out a fair distance in your planning, but not too far. You’ll want to stay out of the micro-details too.
In my own teams I share a heuristic for this. It surrounds the following:
Do end-to-end, release planning for your current release only! And complete it before 25% of your release execution has occurred.
- Keep your User Stories mostly at an Epic level before release sequence entry, but early on refine them to well-sized user stories
Sprint or Iteration look-ahead:
- Have your next 2-3 sprints (in User Stories relatively well defined – towards 80% clarity); Beyond that, they’re mostly high-level Epics
- Have your next release (User Stories) planned at an Epic level; when your within 1-2 sprints of your current release and beginning the next release. Within 1 sprint of the new release, start to do more granular decomposition—getting ready for your next round of Release Planning
Always remember that backlog grooming is an iterative process that needs continuous attention. These tend to guide teams towards the right level of look-ahead and appropriate granular planning.
Don’t Write Everything Down
Here I’m speaking to requirements and other project artifacts. You’ll want to apply the 80:20 rule or Pareto Principle in both directions here. From a writing things down perspective in project artifacts, I would contend that only the most important parts of the project need recording—serious design elements, important bugs, retrospective results, user stories or other agile requirements, acceptance tests, are good examples of what might fall into this category.
As a heuristic, try to influence your team to record only 20% of the things that they would normally try to record. Guide them towards the more important artifacts, while trimming out the excess or waste. You know the ones—usually driven by some process checklist or the teams’ false desire to leave more legacy details than anyone will ever read.
The other rationale here is that software changes…quickly. So information surrounding it has a very short half life and decays quickly. You’ll want to ensure that you are keeping the most important bits up-to-date and with that comes a cost.
Turning it around, another heuristic is to target 80% completeness of your User Stories prior to their execution. We never want fully vetted, zero ambiguity, stories hitting our teams. Stories where everyone looks around and thinks they have a “complete understanding”. When that occurs, conversation and collaboration stops, which is the enemy of agile requirements.
In both of these situations, agile project managers take on the role of fighting for ambiguity in documentation. You should fight for terseness and for just-in-time and just-enough thinking and action within your agile teams.
You want to hear lots of conversations. Heated debates around a particular feature and lots of discussion surrounding quality. Your first and second levels of documentation surround the code, the tests, and the stories—so keep you priorities focused there. You want clarity to be achieved not in planning or at the beginning of an iteration…no, that’s too soon. Instead you want clarity to result from collaborative execution and delivery of completed stories.
You see, clarity comes at the end of agile iterations—when we demonstrate a user story to our customer and they say YES, that’s exactly what I was looking for.
Back to Chaos
Wrapping up, healthy agile teams need to be uncomfortable, leaning into the unknown, and tense with anticipation. They need to be on the edge of chaos with just-enough clarity to get their canoe to the next segment in the river. And with an eye towards impediments and risks that might be right around the corner.
In a word, they need to be agile and adaptive. Great agile project managers continuously foster this environment within their teams—looking to stay on the hairy edge of chaos. They don’t push too hard for data or commitments when the teams’ state isn’t close enough to warrant it. They truly understand the notion of triangulating towards a goal and maintaining a healthy balance between the “knowns” and “chaos”.
Now doesn’t that sound like fun?
Thanks for listening,
Bob.