Football players spend a lot of time studying their Playbooks. And Coaches spend a lot of time creating and updating them. These guys are serious. The stakes are high in the NFL; millions of people are watching. Their stated goal is the same each week; to win. That means they gotta work really well together and know what they’re doing.
I think the game of American football is a great example to follow as an Agile team in the corporate world. We all need some help with remembering stuff, and getting it down so we can execute on game day. Even if we’ve done it many times before, it’s easy to get forget; there’s just so much to know and remember. This is hard stuff we’re doing, and it’s in constant flux. We often find ourselves wanting someplace to go for reference, clarification, advice, dare I say… ‘best practices.’
I’ve had several clients (both large and small) ask me for something they could use to document the way they ‘do Agile.’ If they’re new to the game, often they will look to a consultant or Agile Coach to guide them or help create this information.
Enter ‘The Agile Playbook.’
So what is an ‘Agile Playbook,’ anyway?
In short, it’s a helpful guide. It can come in many forms. For now, let’s stick with the football analogy. If you’ve watched an NFL game recently, you’ve probably seen the coach holding up a play sheet, as he decides what play to call. If you (or your kid) has an XBOX or PlayStation with Madden NFL, you know it has a Playbook feature built into it. Note: this could be an interesting feature opportunity for Agile Lifecycle Management (ALM) tool providers, huh? But I digress. So, as for the Playbook itself, I think of this as the larger, over-arching deliverable.
Transferring this idea of an NFL Playbook into the world of Agile software development is natural. I’ve heard it referred to by different folks in similar ways, like ‘Agile one-stop shopping’, or an ‘Agile Coach in a Box’, or ‘How we do Agile here at Company XYZ’. I personally like the term ‘Agile Playbook’ because it’s short, simple, descriptive, and I believe it drives home the team concept nicely.
Who wants an Agile Playbook?
Can you imagine an NFL team without an organized list of plays? So why would we think it’d be any different in our Agile organizations? I remember playing pickup football and we’d draw pictures in the dirt of what we wanted to do. That was fine for a pickup game, but even my nine-year-old son’s flag football team has a playbook. So the question of ‘Who wants it?’ is an appropriate one. If we think of Mike Cohn’s user story template (As a ___, I want to ___, so I can ___), this is the ‘As a’ piece. Who are we doing this for, anyway? Is it the PMO Director? The ScrumMasters? Product Owners? The Team? Program and Portfolio Management? Executives? The answer, in my six years of personal Agile consulting experience, is ‘all the above.’ If they don’t ask about this at some point, it’s usually because they haven’t thought about it yet.
Why do they want an Agile Playbook?
Hopefully, because it adds value. This is the ‘So I can’ part of the story. It’s a guide to help them get where they want to go. It’s something we can point to when someone asks, “How are we doing Agile in our organization?” It’s something we can go to for reference when nobody else is around. It can even be used as an onboarding tool.
The Agile Playbook also gets us thinking not only about how we work, but how we can improve our processes. Are we really being empirical? Give it a little love in your retrospectives. Perhaps there’s an opportunity to update the Playbook. Oh, and if by chance you don’t see any value in it, simply don’t do it.
Yes, it’s a document.
OK, I know what many of you must be thinking by now… The Agile Manifesto says ‘Working software over comprehensive documentation.’ Yes, an Agile Playbook is a document. And yes, it’s likely to be pretty comprehensive. But that’s a relative term; more specifics on this will follow in a bit. The Agile Manifesto doesn’t say documents are evil. In this case, I believe it’s a very helpful and necessary document to have available in order to get everyone on the same page, and to show auditors that our processes are documented (they like that kinda stuff, ya know). An Agile Playbook is a big deliverable. It takes a lot of time, effort and know-how to put something like this together.
When I did one for a client a couple years ago, we employed a full-time Tech Writer for about a month. That was a huge help. I had initially tried to do it on my own, in my spare time, but that didn’t work out too well. The folks in the Agile PMO, including myself, provided the content, primarily.
But I’ve seen other organizations go with almost nothing documented, just pulling in a coach or two and letting it roll. Maybe sharing a few slide decks on an internal page. No strong desire to document the why, when and how we do stuff. I wonder if that’s because they hadn’t thought about it, didn’t want it by design, or just didn’t have the bandwidth. Or maybe there were other reasons. Personally, I believe that not documenting something this important to the agile transformation of your organization is irresponsible.
And having it documented – but all over the place in different formats – can be chaotic. I don’t like to make people go hunt down stuff, let alone guess or assume anything.
My opinion is that this should be as close to one document (or series of web pages) as possible, not multiples; i.e., not nine Powerpoint slide decks, seven Excel spreadsheets, and 12 Word documents with a bunch of buried links to even more documents, slide decks and spreadsheets. Make it as simple as possible. It’s one place to go. One thing to print off (if you desire to have a hard copy) and carry with you for reference. One URL to save as a favorite.
It can help us realize gaps in the way we work.
What I learned early on is that the hard work of creating an Agile Playbook forces us to give a long, hard look at the way we’re working now, and how we want to work in the future. It’s cathartic. It helps us identify areas where we can improve our processes. It forces us to ask some difficult questions. And make some difficult decisions.
One way in which to identify areas of improvement around your process is to identify your value streams. This is a basic Lean principle. I’m sure we’ve all done something like this. How efficient are we in going from start to finish (request to deployment, concept to cash)? Our goal should be to optimize this. Look to reduce delays, inefficiencies, and improve our cycle time.
How do we document tools and technical practices?
Let’s not forget how our tools and technical practices play into this, as they’re an important factor in how we get work done. If your organization is using an Agile Lifecycle Management tool, the Agile Playbook might include best practices on how to use that as well – either melded throughout, or as a separate section.
Same goes for development tools that help us with…
– Continuous integration – Jenkins, Hudson
– Defect Management – Bugzilla, JIRA, HP Quality Center
– Integrated Development Environment – Eclipse, Visual Studio
– Test Management – HP Quality Center
– Source Code Management – Git, Subversion
– Agile Portfolio and Project Management – VersionOne, et al.
This can be a lot of information, so when documenting for the Agile Playbook, this is an area where I make heavy use of links to information beyond the basics of each of the tools we use.
It should be comprehensive, yet brief.
If you can’t fit the Agile Playbook into your front pocket comfortably, it’s probably too big. When I say brief, I mean about under 50 pages for a large organization. Any more than that, I think folks begin to feel overwhelmed and push it away. Any less, and it’s hard to be comprehensive. There’s no science behind that decision, but if I apply my own average attention span to the matter, this sounds about right. I think much of this also depends on the format you use: Microsoft Word, Powerpoint, HTML, etc. Again, where appropriate, I like to make liberal use of links to other documents/sources to help minimize the length. I recommend placing it on a well-known organizational site such as Wiki, Sharepoint, etc. Provide a highly visible and pronounced link from your internal company home page, and give the option of printing out a hard copy. In fact, I like to have several hard copies available in the Agile PMO to hand out to folks who want one. You’d be surprised how quickly they go. I’ve found that a nice ringed binder works best. That way, if there are changes, you can swap out a page or two. That said…
Did you know…
Most NFL teams now use tablets (iPad or Surface) almost exclusively for their Team Playbooks?
If you’ve watched ‘Hard Knocks’ on HBO, you already know that the phrase “Turn in Your iPads” has started replacing “Turn in Your Playbooks” when players are cut from an NFL team. Those teams have discovered that the technology goes far beyond the old playbook capabilities. There’s a product called ‘PlayerLync,’ which is at the forefront of this movement. It has revolutionized the way teams push out film and significantly altered the way they communicate. Beyond saving printing costs, digital playbooks are improving the effective, real-time communication by allowing coaches and quarterbacks to add and share plays with the click of a button. Every time new data, film or information is added, a banner alert pops up (like a text message), signaling players to view the updates.
Oh, and PlayerLync isn’t just for professional sports teams. Here’s a short clip on how Chipotle and others are using it to push content to their teams:
Uniqueness and commonalities
I’ve helped put together a number of these Agile Playbooks for different clients now, and each was both unique. But there are many commonalities, like the general Agile principles and practices. At the end of the day, folks want to know what to do, who does it, when to do it, and why. All these things can be exclusive to the organization or industry. The extent to which Scrum, Lean, and XP practices are applied also varies from company to company.
The fear seems to be centered around teams in an organization that are using both the framework and the tools differently. It could be that we’re not all using the Agile Lifecycle Management tool in the same way. How in the world can we expect to have rolled up views into the different management levels (Portfolio, Program, and Project) without a common agile project management tool? This opens the door to confusion on many levels, especially when we start talking about agile metrics/reports. But it’s not just the management level that has a problem if we’re not all on the same page. The individual team members also experience fear… fear of doing the wrong thing, or doing it incorrectly, getting called to the carpet or, worse yet, being publicly shamed, written up, or fired. The idea is that if we’re all on the same page, and everyone knows what’s expected, this fear diminishes greatly. Life gets better for everyone.
Start with an outline…
Finally, you were probably wondering when I was going to get here. By the way, each organization’s Agile Playbook is their own. I cannot share the exact Playbooks that I’ve put together with clients, as that information is proprietary. But I can share with you a more generic outline of what an Agile Playbook might look like:
About the Agile Playbook
What is Agile and Scrum?
Implementing Agile and Scrum at Company XYZ
Essentials of Agile and Scrum at Company XYZ (How ‘We’ Do It)
Agile Reporting/Agile Metrics
Staying Compliant with Agile
Company XYZ Communities of Practice (COP)
Do you have a Playbook for how you ‘do Agile’ in your organization? If so, what does it look like? If not, why?