Part One: Protecting the Agile Team
Problem: I try to protect the team, but support issues and dependencies always seem to pop up mid-iteration. If I push back too hard against the Product Owner or Stakeholders, I look unreasonable. If I give up, I feel like a failure. Sometimes, just when I think I have a handle on this responsibility, it turns out team members are working on all kinds of side-projects and how should we handle unplanned work?
Solution: This is a common problem for new Scrum teams and Scrum Masters, but it can also be an anti-pattern that lingers for years if a team does not mature toward more advanced tools. It helps to look at the underlying logic of Scrum that evolved from applying to new product development certain lean manufacturing principles as championed by the Toyota Production System. The simple mantra, “Scrum is Kanban disguised as meetings,” will reveal what goes wrong and what to do next.
While the Lean focuses on reducing the handoff from one workflow step to the next, immature Scrum teams often continue to focus on the performance (and utilization) of the individual team members. If they have a positive attitude and a cooperative spirit, co-location of developers and testers will achieve minor gains in efficient handoffs and effective communication, but this is often where Agile Teams plateau and stagnate. Using the metaphor of a rugby team, the mature Agile Team focuses on moving the ball forward rather than who runs the ball the most.
Of course, modern enterprise can often be even worse. Developers may be co-located in one country while testers are co-located several time-zones away. The managers of each group need to keep their people busy, especially when the “star” developer is actively complaining about being held back by the team, testers, or scrum master; or when some crisis-of-the-day or fire to put our pops up. This results in an oscillating system–giant pendulum swings between overwhelming amounts of work versus nothing to do.
Please take a deep breath: this is not the Scrum Master’s fault, nor is it your sole responsibility. You are the Scrum “Master of Ceremonies” like an entertainer hosting the Grammys, not some glorified bouncer at a very nerdy night club. The most common root cause across the many Agile Teams in this situation is that the team has no idea how much work is in process, where all that work is coming from, what the status of any of the work might be, or what the oscillation is doing to their team health (not to mention their mental and emotional health). Breaking your team out of this anti-pattern can only be accomplished by showing them, as a team, the reality of their own situation and facilitating their conversations about how they can take ownership of that reality.
A Few Valuable Lessons from an Advanced Scrum Master
Visualize the flow of work (the way it actually gets done)
Value stream mapping is a proven approach to understanding everything from product development to supply chain logistics. It has officially stood strong against the test of time. The practice of mapping how value flows through a system (whether a factory floor or a Scrum team), then representing this flow on a Kanban board allows us to observe the flow of value at a glance, identify bottlenecks and quality lapses, then make improvements to the way we work. It is so essential to SAFe that it is a practice applied prior to transformation as well as at every level of the framework on a repeat basis. Moving past “To Do – WIP – Done” is the first step in maturing beyond this root cause. Next, the Agile Team should look at Work-in-Process (WIP) Limits and WIP Policies like swarming and pair work; adding each successful improvement to their Team Agreement.
Acknowledge different types of work
Unless you happen to be developing a completely new or “greenfield” product, there is no escaping maintenance, technical debt, and production support. Moreover, if you happen to be on a completely “greenfield” product team, it is likely this separation of Development from Operations is a huge bottleneck. In reality, either your team should be expecting some unplanned work or should be wondering what massive impediment is occurring downstream due to the “wall of confusion” built between Dev and Ops. Once you have a value stream mapped out on a kanban board, the next piece of the puzzle is your Classes of Service. By separating how Standard, Fixed Date, and Expedited work is visualized and how it should flow through the system, the team is empowered to track the sources and regularities of their unplanned work. They can expect the unexpected, plan for the unplanned, and mitigate the risk of ruined Iterations.
Move toward single-piece flow
Large batches of work encourage team member isolation and high WIP that tends to be hidden, which lengthens cycle times and increases variability in outcomes. Story-splitting is a critical skill for every Agile Team and every member. Every story can be made smaller. When it starts to seem too small, you have a DevOps impediment to solve–do not ignore it!
Give your Team Agreement a reality check
In addition to Kanban WIP Limits, WIP Policies, Classes of Service, and a hearty Definition of Done, the Team Agreement can also include a Capacity Allocation plan that ensures technical debt is paid off, time is made for process improvement, and unplanned work is planned-for reality. Each Team Retrospective should result in an Improvement Item added to the next Iteration, complete with improvement hypothesis. When the experiment succeeds–add the improvement to the Team Agreement!
Agile Rising provides consulting, coaching, and training to organizations embracing enterprise-scale Agile, DevOps, and Business Agility, as well as Technology Business Management transformations. Contact us to learn more about our services! Follow us on LinkedIn to learn more about our team.