Blocking and Tackling on Agile Projects

Chickens, Pigs, and Goats

How's your luck in controlling all the animals on a scrum?

If you're familiar with scrum projects, I'm sure you've heard the story of the chicken and the pig who considered opening a Ham 'n' Eggs restaurant. Of course, the pig declines because he's a lot more committed than the chicken!

For those not familiar with the story, it’s a fable that symbolizes the players in around your Agile project, using farm animals. The pig in the story represents the core project team, because they’re fully committed to the outcomes and success of the project. The chicken represents those stakeholders who are involved and impacted, but not actively responsible for delivering the result.

The reason we tell this story to the scrum-curious is to make it clear that chickens are fine to observe what's happening with the pigs; however, they must not interfere with how the pigs govern, execute, or control their project.

I’d like to introduce a third farm animal to the story—a goat. In my version of the fable, the goat is interested in eating at the restaurant, but only has a vague sense that the chicken and the pig are even discussing the venture. The goat represents stakeholders (like chickens) that have heard of your project, and may be impacted by your project, but have no clue as to how it’s being managed or why. They definitely need to steer clear of the pigs, because they don't have any context at all into what's going on.

Well, it would be easy if the chickens and goats just respected the rules of the game and left the pigs alone. That's where theory and reality have a fanciful relationship.

A Playbook for Coaches and Business Analysts

To survive an Agile project, the coach or ScrumMaster and the business analyst must work strategically to block and tackle incoming chickens and goats. I've never seen an Agile project where outsiders don't actively interfere with the core team. In the early 2000's, I ran an Extreme Programming project at a large data systems company. I had to deal with this goat who couldn't contain himself when passing by the team. Every time he walked by, he made a destructive comment about the way we were doing things. It was very distracting and disruptive.

Agile practices are so visibly novel; chickens and goats can't help but be curious. Curiosity is fine, but in almost all cases, it goes too far. For instance, the behavior that's expected from a chicken during a daily standing meeting is silence. But invariably, you'll get chickens interjecting and in some cases over-facilitating the coach. This is unacceptable, but it's hard to defend unless you're prepared.

That's why, before the project even starts, the coach and the business analyst must formalize their strategy for protecting their realm. This is more than just a casual discussion; they need to develop a defensive playbook.

Buffer Zones

The first strategy in the playbook is setting up buffer zones. These are project team members who surround the pigs, but aren't part of the core development team. They could be analysts, subject matter experts, interns, or any other type of helper. It's okay to treat them like pigs (i.e., engage them in brainstorming and decision-making); they're in the inner circle and they're just as responsible for the outcome as the rest of the core team. What makes them different than pigs is that they're not developers and they don't follow all the developer practices. They do know a lot about what’s going on and that's what makes them valuable in the buffer zone.

I setup my team at a large technology company this way and it worked perfectly. We developed a grassroots data warehouse for government compliance and I ran it Agile so we could be flexible with the requirements. I had a core team of six database professionals, a lead, a business analyst, and two finance analysts. The lead, business analyst, finance analysts, and I served as the buffer–and we needed it. There were over 50 curious stakeholders counting on us to deliver (which of course we did).

Defensive Plays

The coach (or ScrumMaster) is ultimately responsible for protecting the core team, but it's very difficult to do without the business analyst. The coach must stay close to the core team so he or she can monitor progress and provide motivation and support. From a blocking and tackling standpoint, you can think of the coach as the last line of defense. I have physically intercepted and blocked low flying chickens from disrupting my team.

The business analyst handles chickens as well, but he or she is most valuable with goats. Remember, unlike chickens, goats haven’t been brought into the mechanics and reasoning of how your agile project is being executed. This is all the more reason why somebody needs to manage their expectations and involvement. For instance, there may be an executive in a completely different business unit who’s suddenly taken an interest in what you’re doing. With the right influence and the wrong context, this could be very a disruptive challenge. The business analyst is the perfect person to handle these situations.

Where the coach provides the last line of defense, the business analyst provides the first line of defense. Having a good relationship with all the stakeholders makes this possible. It's hard for the coach to keep tabs on everyone impacted by the project, but this is the business analyst's primary responsibility. With a good stakeholder analysis, the business analyst should have a solid perspective of who needs to know what and when–even those who aren't aware of the project details.

It's always good to advertise the fact that you have other team members (in the buffer zone) who are aware of what's going on. That way, when curious chickens and goats come around, they have someone to talk to other than the developers.

When All Else Fails

There are some chickens and goats that can't be blocked. Take for instance a high-ranking executive who insists on redirecting the efforts of the team. It's not that I won't try to run interference with an executive, but I'm not willing to lose my contract over it. In these cases, you need executive sponsorship. Sponsorship is not something you can deploy ad-hoc, so make sure you plan for it upfront as part of your strategic playbook.

All Agile projects need sponsorship–regardless of the circumstances. This is more than a blocking and tackling strategy; it's an overall Best Practice. Agile projects are fragile projects. This slightest disruption from the wrong place can throw things into a tailspin. The only way to block executive-level interference is with executive-level countermeasures.

I had very strong leadership in place on the data warehouse project. I had a senior director in my corner who would take out anyone who tried to interfere with my project. It was wonderful. I just stayed behind her for the entire project and I never had a problem.

Conclusion

When it comes to running scrums and other Agile projects, there's one rule that will certainly be challenged. Just like the fable of the chicken and the pig reminds us, the core development team must be left alone to follow good agile development practices. Unfortunately, that's not the way it works in real life. In practice, there's constant interference from outsiders: anything from mild distraction to absolute subterfuge. Don't let this happen on your project.

The coach and the business analyst are the perfect team to run interference, but it must be thought through. Develop a defensive playbook that details buffer zones and defensive plays. Use the business analyst in the field, while the coach stays close to home. And always have executive power waiting in the wings to handle the toughest problems.

If you're planning or running an Agile project, take some time today to develop your playbook. If you don't, the chickens the goats will eventually get the best of your pigs. And that's a recipe for disaster.