How to Reduce Agile Risk with Monte Carlo Simulation

Man with dice








I love to gamble, but I prefer to gamble with dice, not software delivery.

Precisely predicting what can be completed in a release, and accurately accounting for risk, is one of the most important responsibilities of a program manager, IT leader, project manager or executive; yet the majority of our predictions have the same odds as winning the lottery.

Given those odds, can you improve the accuracy of predicting when software will be delivered?

Why Linear Forecasting Isn’t Optimal for Reducing Agile Risk

For decades the people managing software projects have attempted to predict software delivery dates with mixed results. In most cases, these predictions relied on linear forecasting techniques. While these can be useful, they fail to consider the risk associated with human involvement. Linear techniques assume a fixed future velocity based on an average historical velocity. As any investment broker or financial advisor will tell you “past results do not guarantee future performance.”

Consider a simple scenario where two teams both have an average velocity of 7.5. Using this average, either team could deliver the next 45 points in 6 iterations. However, suppose Team A’s historical velocities values were 10, 4, 5, and 11, and Team B’s historical velocities values were 7, 8, 8, and 7. The average is the same, but because the velocity values for Team A have a higher variance, there is greater risk when predicting future results. Furthermore, as stated above, the historical velocity values are not indicators of future performance. Either team could encounter a scenario that significantly improves or degrades velocity.

Another problem with linear forecasting is the fact that it yields a single date; nothing more. Yes, you can forecast a cone of uncertainty using the best and worst historical values, but in the end you only have dates; the best case date, the worst case date and the average date. There is no information to help you determine why any given date is better or worse than another.

Therefore, when asked to commit to a delivery date, you’re left with “trusting your gut” based on your knowledge of the team and other perceived trends. Unfortunately, many people would look at the upward trend of Team A and conclude “velocity is going up; that’s a good thing; they must be getting better.” The significant drop from 10 to 4 in the second iteration would be considered an anomaly “because the team was just getting started.” These factors result in a false confidence that leads to a more optimistic date commitment.

Given nothing more than a forecasted delivery date, and limited insight into the probability of hitting any date, you are left negotiating a contract, the delivery date, with limited information. Therefore, it is not a surprise that we consistently pick the wrong date and scramble at the end to “deliver something”.

There are better techniques for forecasting delivery dates that account for risk and give us the information necessary to effectively collaborate on a delivery date.

Reducing Agile Risk using a Monte Carlo Simulation

A Monte Carlo Simulation is a forecasting technique that can be used for predicting software delivery dates and accounting for risk. A Monte Carlo Simulation is “a problem solving technique used to approximate the probability of certain outcomes by running multiple trial runs, called simulations, using random variables.” The technique gets its name from the city of Monaco, a place renowned for its casinos long before the likes of Las Vegas or Atlantic City. Monte Carlo methods have been effectively used for years in the physics, engineering, financial application and even predicting election results. Douglas Hubbard, author of “How to Measure Anything”, states, “running Monte Carlo is the only way to analyze big uncertain decisions.“

A Monte Carlo Simulation considers the historical values of control variables, in our case velocity, as opposed to relying on a single value. It then simulates the completion of remaining work and produces a histogram showing the distribution of possible delivery dates. From those results, you can calculate various percentiles, or confidence levels, on each possible delivery date.

You’re probably thinking, “Whoa! That sounds really complicated!” Well, maybe if you were building the simulation yourself, but there are solutions that make it very simple. VersionOne is the first agile lifecycle management solution to offer predictive project modeling through Monte Carlo Simulation. The solution leverages quantitative information and risk factors to help forecast project completion dates at various confidence levels so that project managers understand when all of the planned work is most likely to be completed.

Sample Monte Carlo Simulation

Going back to the example presented earlier. When asked to determine when Feature X is going to be available, you can use a Monte Carlo Simulation to have an informed conversation about various dates and the confidence level of delivering on those dates. And now you are collaborating with the business on a delivery date rather than negotiating.

Even if you made customer commitments that Feature X will be included in a given release, you can use the Monte Carlo Simulation to determine, much earlier in the delivery cycle, the likelihood of the feature being delivered on time. By having this information earlier, you can make better business decisions, rather than waiting until the end of a delivery cycle.

Start Accurately Accounting for Agile Risk

In closing a word of caution: the Monte Carlo Simulation is not a panacea nor is it a crystal ball that lets you see into the future. Rather, the results of a Monte Carlo Simulation provide a more informed forecast that accounts for risk. And with the Monte Carlo Simulation capabilities in VersionOne, these simulations are faster and easier than you might imagine. In fact, it probably takes more time to deal with dissatisfied stakeholders after a missing a date because of a poor prediction.

I hope this article has inspired you to more precisely predict what can be completed in a release and more accurately account for risk using a Monte Carlo Simulation.

In addition to Monte Carlo Simulation, find out how VersionOne provides better insights for making better decisions.


Posted in Agile Adoption, Agile Benefits, Agile Development, Agile Management, Agile Metrics, Agile Project Management, Agile Software, Agile Tools, Enterprise Agile, Scaling Agile | Leave a comment

Is DevOps a People Problem AND a Technical Problem?

weinberg secrets of consultingOver the past few years, I’ve become more familiar with the works of Jerry Weinberg.  One of his best is a book called Secrets of Consulting, which I highly recommend to all those who give advice for a living.  Among the many rules and secrets that he shares, there are two that stand out time and again:

  1. There’s always a problem.  If they’re bringing a consultant in, there’s a problem to solve, even if they don’t really know what that problem is.
  2. It’s always a people problem.  Even in the most highly technical of scenarios, at the end of the day there’s a people issue at the root of it.

Now I don’t want to be one to quibble, but I believe that DevOps is that unusual scenario where getting good at it is both a technical and people problem.  Let’s take a look at what that really means.

nasa-control-roomThe Technical Problem

When we look at the practices that are so important for DevOps, we see a lot of technical solutions.  These practices enable DevOps to run smoothly and efficiently and make a huge difference in the success of an IT organization.  Many of them require a high level of technical sophistication as well as discipline, to achieve.

What are they?   Most of these practices are well understood as the foundation of DevOps. Items like Continuous integration have been around a very long time, and require a CI server as well as the concurrent automated Unit and Acceptance Tests to make Continuous Integration worthwhile.  This also requires a tight integration with the version control system, so that everything can be under version control.  All artifacts of delivery need versioning to truly be successful and, dare I say it, safe in a Continuous Delivery environment, which is of course the logical conclusion of a DevOps approach.

But wait, there’s more

So yes, there are technical practices that are required to truly “do” DevOps.  But in order to do those practices, we need people.  Bringing operations into the Team Room requires a new_shimmermindset and a willingness to change that can be very difficult to engender.  I’m not just referring to the difficult things like learning to automate and *choosing* to automate all Acceptance Tests, but also simple things like remembering to include monitoring items in all of your stories.

This is a big shift in thinking.  Development teams are used to finishing something, handing off to operations, and moving on to the next thing.  They don’t want to be bothered with something in production unless there is a bug, which they will often see as an inconvenience.  Building a culture that goes beyond deployment, but treats development and operations as a single, holistic entity takes a lot of support and willingness on the part of everyone.

Sometimes it’s just about language.  We need to start asking different, or more, questions during our analysis of stories.  Instead of asking if a particular test should be automated, familyTherapyask instead “how will we automate this one?” Including automated deployment and monitoring in our definition of done, or at least in the tasks we identify, will take us very far in the culture of DevOps.  This brings the whole cross-functional team into a world where the success or failure of a story doesn’t stop at the Sprint end.  Getting our team members to all take that to heart, and looking for the operational aspects of a story is hard, and requires patience and nurturing.  For that matter, so is getting the team into the mindset that automating tests is not optional, but required to ride this ride.   This also takes patience and nurturing.

Darn it, Jerry Weinberg is right again!  It really is a People Problem!

Posted in Agile Adoption, Agile Benefits, Agile Coaching, Agile Leadership, Agile Management, Agile Methodologies, Agile programming, Agile Software, Agile Teams, Agile Testing, Agile Tools, Continuous Integration, DevOps, Distributed Agile, Enterprise Agile, Extreme Programming, Software Craftsmanship, Test Driven Development, Uncategorized | Leave a comment

The Trojan Retrospective – From Crickets to Conversations

rear view

This blog is part of a series on “Agile Trojan Horses – Covert Appetizers for Agile Discovery.” This series is intended to help spark conversations that restore focus on agile fundamentals, whet the appetite to discover more about agile, and help apply agile in day-to-day decision-making.

One of the elements that I love about Agile and Scrum is the focus on humility, reflection and continuous inspection and adaptation. One of my favorite Agile Principles is #12…

At regular intervals,
the team reflects on how to become more effective,
then tunes and adjusts its behavior accordingly.

One of my favorite Scrum events is the retrospective. As the Scrum Guide says…
The sprint retrospective is an opportunity for the Scrum team to inspect itself and create a plan for improvements to be enacted during the next sprint…

…The purpose of the sprint retrospective is to:
– Inspect how the last sprint went with regards to people, relationships, rocess, and tools;
– Identify and order the major items that went well and potential improvements; and,
– Create a plan for implementing improvements to the way the Scrum team does its work.

Some common impediments prevent teams from applying the agile principle of regular reflection and from having effective Scrum tetrospectives.

LACK OF ATTENDANCE – Team members not showing up to the retrospective.

- LACK OF PARTICIPATION – Not hearing anything at the event besides the sound of crickets – team members showing up, but not sharing anything.

- LACK OF TRANSPARENCY & INSPECTION – Meaningless conversations – no transparency and no inspection. Nothing other than whining, finger-pointing and complaints.

LACK OF ADAPTATION – Meaningful conversations – healthy transparency and inspection but no meaningful adaptation. No follow-up actions to make things better.

Besides creating safety, one of the most important elements needed for a team to have meaningful inspection and adaptation is an ice-breaker. For many team members new to agile, the act of reflecting on the team in a safe setting, is awkward and unfamiliar.

I usually begin by putting up some flip charts with the questions…

1.    What worked well?
2.    What could have worked better?
3.    What actions will we take in the coming sprint to make it more effective?

I add a couple of additional questions…

4.    What was the most valuable knowledge we gained in this sprint?
5.    What contributions would we like to acknowledge in this sprint?

In most cases, with a few nudges here or there, the team starts opening up and we have a meaningful conversation. However if the team is still not talking, you could try this approach…

In this approach, we put up a bunch of assertions in front of the team and ask them to share their responses to the statement. These approaches fall into five major categories that also help raise the team’s awareness of key elements relevant to agility…






For each assertion, ask the team to respond by choosing one of four categories…

HUH…? - We are unaware of or unclear about what this means.
HEALTHY – Our team is healthy in this area. No adaptation needed.
NEEDS SOME ADAPTATION – Our team could use some adaptation here.
BLOCKED! NEEDS URGENT ADAPTATION- Our team needs urgent adaptation here.

If the team is co-located, you could create a grid on flip charts and the team could put up colored posts.

Encourage each team member to also jot down why they chose a particular post-it, maybe with an example, if they can. If not, it is completely OK, they can just put up a blank post-it.

If the team has specific ideas on how they might adapt the next sprint to be more effective, they can jot them down on a post-it and put it up in the last column.

The grid might look something like this…ResponseOptions
If the team is distributed, you could send them an online survey and have them respond either before the retrospective event or during the initial portion of the event.

Either way, once the team has finished responding, you can sum-up the responses in a table like this…ResponseScores

You might try jotting down your responses as you read this blog as well, before you take this idea to the team. Now that we have set the stage, let’s start reviewing the assertions…


We begin with a section adapted from the Agile Manifesto. Reflect on how aware your team is about the Manifesto and how effective you all feel you were in applying it to your work. time-box this section, and review feedback as a group.Manifesto


The next section encourages reflection on the Agile Principles. Ask the team to consider each principle and share their thoughts on how effectively you all applied them. Discuss as a group.Principles 1-6

Principles 7-12

Let’s start reflecting on one of the frameworks under the agile umbrella – Scrum. At a high level, the Scrum framework has three core objectives. As a team, reflect on whether the processes you used helped accomplish these objectives.


Scrum is not just about rituals or “what” we do as a team. The heart of scrum are the core Scrum Values that define “how” we work together as a team. Pull up the Five Scrum Values and allow the team to share their thoughts on the team culture and how close it was to being true to the Scrum Values. Discuss as a group.


As described in the Scrum Guide, Scrum is based on the three pillars of empirical process control. Ask the team to share their thoughts on how effectively the team applied empiricism in their work. Discuss as a group.


The Scrum Guide clearly lays out the accountability for each role in the framework. Ask the team to reflect on how effectively each role or group delivered their accountability. Discuss as a group…ScrumGuide-2


The Scrum Guide clearly lays out the purpose and desired outcomes for each of the five events in the framework. Ask the team to reflect on how effective they thought each event was. Discuss as a group…ScrumGuide-3


The Scrum Guide clearly lays out the purpose of each of the three artifacts. Ask the team to reflect on how closely each artifact accomplished the purpose defined in the Guide. Discuss as a group…


Scrum can only be as effective as the level of transparency in the organization. Reflect as a team on how transparent you feel the organization is. Discuss as a group…


Mary and Tom Poppendiek have done some amazing work how the lean principles from manufacturing offer a better approach to software development. These principles are available on their website – and I have taken the liberty to adapt them for our approach.



Reflect as a team on how effective you were in applying the lean mindset and discuss as a group.

By now, hopefully, the silence and crickets at the beginning of the retrospective have been replaced by meaningful conversations about how the team can inspect and adapt its work.

Hopefully, these conversations have dispelled some common myths about what agile is and is not and acted as an appetizer for the team to explore some more about agile software delivery.

When you sum up the responses, the graph might look something like this…

Before you end the session, ask the team to pair up and pick up at least one action item to make a thin slice or process improvement in the next sprint. Without adaptation, the transparency and inspection of a retrospective are meaningless. If there are too many options to choose from, use dot-voting to help rank the options and pick the ones that fit the capacity constraints of the team.

Try out this approach even if you begin with baby steps by reflecting as an individual.
Either way, please share your thoughts. If you like, you can use this Excel spreadsheet as a starting point.

Either way, please share your thoughts. Keep calm, and Scrum on!

Posted in Agile Adoption, Agile Benefits, Agile Development, Agile Methodologies, Agile Teams, Agile Training, Scrum Development, Scrum Methodology, Scrum Software, Scrum Tools, Uncategorized | Leave a comment

Psssst! I Can Get You Fixed Cost AND Fixed Dates!!


I have an offer you can’t refuse…

You don’t have to be afraid, just because I am Sicilian.

I am talking about Product Development here, not “garbage collection”.

I know it frustrates you that all this Agile stuff talks about uncertainty and fluffy stuff. I have a secret for you, however. It’s one of the most overlooked aspects of Agile. I will even let you in on this secret for absolutely FREE.

Here it goes…

In Scrum, there are fixed timeboxes or iterations we call Sprints. You probably knew that. However, what you probably didn’t realize is that if your Scrum Teams establish fanatical discipline and rigor around only releasing things that are in line with their strong and comprehensive Definition of Done every Sprint, you will have…


What will undermine this is if they compromise on the various criteria in the DoD, effectively cutting corners and introducing risk into the product. Also, if they extend the Sprints, change the duration repeatedly, or have nonsensical practices like magical mystery Sprints where hardening, innovation, and planning suddenly take place then all bets are off in terms of having…


So, let the Scrum Teams be responsible and empowered to make the critical decisions that no one else can truly and effectively make. They will make the product sound in accordance with changing customer needs and technological advancements by baking quality in, integrating along the way, practicing emergent design, improving by coming up with new ideas, and doing smaller increments of ongoing planning, as Scrum intended. The result will be…


Now, we all know that a Development Team in Scrum is supposed to be 5-9 (7±2) people, right? If we use a blended rate of, say, $100k to represent the average salary for team members (including consultants), then we know for certain that a Development Team will cost $500-900k / year. Voila! We have…


Now, we can figure out what a Sprint costs by doing simple division. Let’s say a Sprint is two weeks. That gives us ~$19,000-$35,000 / Sprint depending on the Development Team size. Further, let’s assume our releases are every 3 Sprints (6 weeks). Now we know that a release costs us ~$57,000-105,000. That’s a beautiful thing. That’s…


You can’t ask for more!!

No, I mean literally, you can NOT ask for more; like Fixed Scope, for instance. In order to get fixed costs and fixed delivery dates in Scrum, the trade-off here is that the Scope is flexible. This is good, don’t freak out.

Having flexible scope ensures that we are able to roll with the punches and change as customer needs change, technology changes, and most importantly, business priorities change. To help us with this, we want the Sprints to be as short as possible. If we have one week Sprints, then we can formulate smaller increments in planning and ultimately have very granular refinements in our strategy rather than very drastic course corrections which are costly.

We still have higher level elements of planning that map to overall strategy: Vision, Roadmap, Release level planning, and insisting upon a Sprint Goal for every Sprint. This helps to keep us on target and focused with our longer term strategy.

So, not having fixed scope is a good thing. We could still have releases that are structured around fixed scope instead of fixed delivery dates. But it’s simply not realistic or REAL WORLD to expect to have more than one element fixed, one element firm, and one element flexible from among Scope, Cost, and Time. Those who demand to have all three fixed (so-called “firm fixed price”) are best served in taking this up by seeking an audience with OZ in the Emerald City, since they are indeed in fantasy land…

So, there it is:

Happy weekend!

Peace and blessings-


Posted in Agile Adoption, Agile Benefits, Agile Development, Agile Methodologies, Agile Teams, Agile Training | 3 Comments

Self-Organizing Teams… Really?

“Why aren’t self-organizing teams allowed to self-organize?” Self Org

This question came up in a Certified Scrum Developer (CSD) class I was in last week… To clarify, what he went on to say with more specificity was, “Why don’t we let our agile teams self-organize ‘at creation’ when we’re putting together a new team?” He went on to note that, in his experience, this is determined by ‘Management Fiat,’ primarily based on the talent and maturity of the individuals. Hmmm, interesting question…

What does Scrum say about this?

The best architectures, requirements, and designs emerge from self-organizing teams

One Agile Consultant in the class said he’d been doing this for a long time, and he’d never been in an organization where folks were allowed to actually self-organize into agile teams. They were all handpicked by someone at the management level.

But what if we gave the teams a goal and let ‘em fly? What if we truly allowed them to self-organize into agile Scrum teams on their own, without being told who would be on what team? Would we end up with a bunch of experienced folks on one team and a bunch of inexperienced on another? Would it become a bunch of cliques, like high school? Would we have agile teams that consisted of only developers, and other agile teams only of testers?


Let’s assume that it did. Then what? Would we expect management to say, “Stop right there. We need to be smart and fair about this. You go here, and you go there,” until the teams were more evenly spread with the ‘right mix’ of roles and experience. I suspect this is what would happen in the vast majority of cases.

But management isn’t impervious to making mistakes. The teams should be allowed to as well. We’re empirical. We inspect and adapt. If there’s a change needed among the teams, allow the teams to make the change. Involve management as needed.

Have you ever been given that kind of freedom to self-organize into agile teams? If so, what was your experience? If not, are you willing to have a conversation with management to give this a shot?

What is Scrum? Scrum is easy. Scrum is hard. Let’s hear your thoughts.

Posted in Agile Adoption, Agile Coaching, Agile Management, Agile Project Management, Agile Teams, Scrum Methodology, Uncategorized | 8 Comments

Agile is NOT For You


Guest post from Daniel Gullo, Apple Brook Consulting

You are talking with two consultants about how to transform your organization into an Agile development company so that you can go faster and keep ahead of your competitors.

You explain to them that your stakeholders have a need to know what is going on and to that end, there are reports that need to be created. Furthermore, your product is governed by Sarbanes-Oxley controls, which absolutely MUST be followed. Funding for your projects is allocated two to three years in advance and is based on detailed estimates, which are in turn derived from the Work Breakdown Structure (WBS) for the project. None of this can change.

You continue to explain that the teams are geographically distributed across four continents and 10 time zones and that restructuring the teams and bringing the teams together, even just for release planning is not possible. Your organization also has no budget to buy things like webcams, additional monitors, team rooms, or even open wall space.

The ScrumMaster in your organization will be “in charge” of 10 to 15 teams and may have other responsibilities as well. Also, the “Product Owner” is really in charge of an entire business unit and won’t be writing any User Stories, so the business analysts will need to be a “Product Owner Proxy” for each team.

After spending 20 minutes relating all of this (and more) to the consultants, including how none of this is negotiable, you ask, “So, what are your thoughts on the best way to implement Agile development here?”

There is silence.

After what seems like an eternity, one of the consultants clears his throat and says “Agile development is NOT for you.”

Did you really just hear that??? Doesn’t this guy get it? Is he really so independently wealthy that he is going to throw away the money that is on the table??

There’s a saying that goes: “If you didn’t get the joke, then the joke was not for you.”

If your company is not open to change or trying new things or running experiments in order to learn, then, Agile is NOT for you.

If your organization is not interested in having happy employees by focusing on people or they aren’t willing to make an investment in tools or to look at simple measurements of customer satisfaction such as the Happiness metric or Net Promoter Score, then, Agile is NOT for you.

If you are not willing to explore what “possible” really means and thus, have an open mind to doing the unconventional, then, Agile is NOT for you.

I’m sorry. I really am.

Agile is not magic. We can’t produce something from nothing or make other trade-offs go away. In order to get X, then you must do Y. You can’t expect to maintain the status quo AND improve. It’s simply not the “real world.”

Agile is all about embracing the uncertainty of change and learning how to use it to your advantage.

As a consultant, I often test the waters a bit when going through the discovery stage with a new client. I might say something that represents a “worst case” scenario to see if they are prepared to go there if it comes to that. I also ask a lot of questions around seeing how they think about people, constraints, etc.

My educational background was in Law. I am inclined to look at possibilities. I often find myself in a workshop or training session orating as if I were in court:

“In your expert opinion as a Senior Software Developer, is it POSSIBLE that you could build production-ready features, albeit very small slivers, that are capable of functioning from end to end by cutting through the entire architecture?”

“No. We can’t produce anything of value in less than six weeks.”

“So, it’s NOT POSSIBLE to release a single field on a webpage with a submit button that applies some business logic and then inserts a value into a table in a database that only includes that field? That’s absolutely NOT POSSIBLE??”

“Um, well, yes.”

“I rest my case, your honor.”

Becoming Agile means being open to possibilities and options.

In a sense, BEING Agile is like acknowledging and understanding what innovation truly means in the same sense that an artist understands what “creativity” means. Is someone who simply slaps paint on a canvas with no understanding of what they are doing considered an “artist?” Most of us would say that they are not.

Likewise, I can explain the agile values, principles, practices, and dynamics of agile culture to someone, but I can’t tell them how to be innovative. That’s something that has to come from within.

It’s uncomfortable, change.

And, through discomfort, we learn and grow.

If you are comfortable with how everything is going, then you aren’t learning.

If you aren’t comfortable with the prospect that Agile is going to make you uncomfortable, then sorry; Agile is NOT for you…

Posted in Agile Adoption, Agile Benefits, Agile Coaching, Agile Development, Agile Leadership, Agile Methodologies, Agile Teams, Agile Training | 21 Comments

The ‘Agile Playbook’

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?

broncos-120423If 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 Planning
Agile Execution
Agile Cultivation
Agile Tools
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?

Posted in Agile Adoption, Agile Benefits, Agile Development, Agile Management, Agile Methodologies, Agile Project Management, Agile Teams, Scaling Agile, Scrum Development, Scrum Methodology | 2 Comments

My Life as an External Agile Coach (Part 3 of 3)

Here’s the last article in a three-part series from Susan Evans. As we ring in the New Year, this post describes a day in Susan’s life as a Product and Agile Consultant for VersionOne with various client engagements, travel and a family at home.

[Back to Part 1: “99 Problems But Coach Ain’t One”]

[Back to Part 2: “My Time to Evolve as an Agile Coach”]

Working for VersionOne as a Product and Agile Consultant has been a dream come true. All of my Job Satisfaction Acceptance Criteria have been met, and I couldn’t be happier.

Being an agile consultant and traveling for my job were new concepts to me, so thankfully I had the opportunity to shadow some talented individuals to help get my feet wet, show me the ropes, and build my confidence. I’ve experienced agile failing fast, but I’ve also experienced lots of inspecting and adapting that lead to success.

As an agile consultant, I have the chance to share my knowledge and experience with the goal of steering clients away from failure and closer to success. What I love is that I get to help clients in a variety of ways so I’ll never get bored. No two engagements are the same with different clients and their unique cultures, different cities in different seasons, and all of the lively individuals I meet. I’ve been fortunate to work with clients by learning their process and helping to configure and implement the VersionOne agile lifecycle management (ALM) software platform to enhance their agile practices. It’s a great coaching opportunity and a chance to gain insight into how different companies operate.

I also have engagements where I train people who are new to VersionOne, or want advanced training. Both are very satisfying because I get to help people be more proficient with VersionOne, making their agile process that much smoother. I’ve also had the privilege to guide clients through their agile transformation. It’s so rewarding to have people repeat your words back to you and truly be excited to try something new.

Image credit:

Image credit:

All of those different clients in different cities means that I’ve slowly become a frequent ‘traveler snob’ and can relate to George Clooney’s character in the movie ‘Up in the Air.’ Being that I live in Atlanta and have Delta as a hub at Hartsfield International Airport, the nonstop flights have been great. All other airports and hotels look the same and I complain when I have to take a shuttle to the rental car, or if my room doesn’t have a mini fridge. When I get settled, I take full advantage of being in a new city. I’m an adventurous person and have really enjoyed the travel. I like to explore the touristy areas and have dinner with the locals. I was afraid that I would be lonely, but surprisingly am enjoying my alone time and it’s easy to make friends when I want some company. And my family is just a Facetime away so I can share my adventures with them, too.

I have two children in elementary school, so I was skeptical about traveling and missing out. However, my engagements are typically two to three days during the week with the occasional Monday through Friday. I’m able to block out important dates such as birthdays and recitals to ensure that I’m home.  Thanks to modern technology, I’m able to easily stay in touch with my family. My daughter likes to see my hotel rooms and my son likes to make silly faces at me. I’m still able to talk with them about schoolwork, their friends, and extracurricular activities.


I wouldn’t have been able to pursue this career if it weren’t for my very supportive husband, who also works and does a great job of holding down the fort while I’m on the road. I’m thankful beyond measure. I’ve gained so much experience and knowledge but I still have so much more to learn. Thankfully, I have an amazing network of agile coaches from which to learn and an active community to speak with and listen to. The fun is just beginning and I can’t wait to see what’s around the corner!




Posted in Agile Coaching, Agile Leadership, Agile Management, Agile Tools, Agile Training | Leave a comment

My Time to Evolve as an Agile Coach (Part 2 of 3)

This article is the second in a series about Susan Evans’ journey from an internal agile coach to an external agile coach. In this part, Susan will cover how she used the agile principle of reflecting on effectiveness and adjusting accordingly by making changes for the better.

[Back to Part 1:  “99 Problems But a Coach Ain’t One”]

I strongly believe that if there’s anything in my life that I’m unhappy about, it is only up to me to do something about it. So when I found myself considering a complete career change, I knew it was time to inspect the situation and see what needed to be changed. As hard as it was for me to admit, I found that, as the internal agile coach, I was no longer being heard and, therefore, no longer making a difference.

My confidence was shaken until I elicited feedback from the development teams and discovered that they valued my involvement, but they felt that the executives didn’t agree. In fact, they felt the executives were good at ‘talking agile’ but not good at ‘living agile,’ and no matter what I said or did, the culture beyond the development teams would never truly embrace agile.

That was a very sad day… I helped guide agile teams that were growing, shrinking, shuffling, international, self-managed, and completely brand new with an ever-changing process that evolved to fit the situation. Yet, executives still wanted ‘one throat to choke’ instead of understanding that a self-managed team either succeeds or fails together, not due to a command-and-control manager.


I knew it was time for me to do something about it. So I proposed a solution to the CTO, who was my boss at the time. To make a difference again, I needed to be empowered to influence the culture, which meant that I needed to be a peer with the executives as a Director of an Agile PMO. Unfortunately, he was not interested in an Agile PMO Director so this solution was not available to me. I knew that the environment that the CTO would foster and support was not one in which I would thrive and, therefore, it was my time to evolve and move on to a new opportunity.  I asked myself, “What do I do now? In what kind of company and industry do I want to work? What will make me happy?”

To help provide focus and know my priorities, I wrote a simple user story with acceptance criteria:

“As Susan Evans, I want to change jobs so that I enjoy working again.”

Job Satisfaction Acceptance Criteria:

  • To make a difference and help people and organizations be happier and more productive and, therefore, proud of my work.
  • To respect the leaders of the company I work for in their ability to grow the company and do the right things for their customers. I wanted to work hard to make money for my executives.
  • Work for an agile organization… I CANNOT go back to the “dark side!”
  • Work for an established and stable medium-sized company where I can work with, and get exposure to, many departments.
  • The culture of the company must be causal with attire and work hours, and strive to have happy employees with fun activities during and after hours. I want to feel a part of a hardworking family.
  • I want to be challenged and provided the opportunity to learn and grow my skills.
  • I want a supportive manager who will trust me to do my job to the best of my ability and provide guidance when necessary.

As Peter Saddington said during a speaking engagement at a Scrum Meetup in Atlanta, life is too short to hate your job. So, I challenge you to write down and prioritize your acceptance criteria for job satisfaction and assess how you’re doing.

Don’t miss my wrap-up (Part 3) of this series coming soon, where I will discuss my experiences as an external agile coach.

Back to Part 1:  “99 Problems But a Coach Ain’t One”

Posted in Agile Coaching, Agile Leadership, Agile Management, Agile Project Management, Agile Teams, Scrum Development | Leave a comment

99 Problems But a Coach Ain’t One (Part 1 of 3)

This article is the first of a three-part series that provides insight into what it’s like to walk a mile in an agile coach’s shoes. Susan’s journey starts as an internal coach and then evolves to her current role as an external consultant.

I was a rockstar for the first nine months to a year as an internal agile coach helping to improve various areas in application lifecycle management (ALM). Once the easy issues were resolved and we were left with the hard executive and cultural changes, then my returns were diminished and it became harder to see how I was making a difference as an agile coach. Even when change was happening all around us (team assignment, desk location, code build tool, projects/product owners, deployment process, agile process, ALM software, etc.), it was still very time consuming to see the results of my influence. With every issue we were able to check off the list, it felt like there were 99 more problems to address.

I started documenting all of my ‘Proud Mommy Moments’ where we were successful so I could see the progress we were making. I read Lyssa Adkins’ book “Coaching Agile Teams” for new ideas and reassurance that I was doing what I was supposed to be doing. But most importantly, I stopped blaming myself for the failures. As an agile coach, ‘keeper of project management,’ with a growing list of issues to address, you feel like you have the weight of the world (well the company) on your shoulders and it is up to you to champion improvements in the ‘broken’ process.

But you can’t do it alone.

I was able to get the right people together to talk through the issue and determine a solution. We even communicated the change to all involved. However, many of the decision makers and key leaders never changed their way to follow the new process. I took this very personally, thinking that they did not respect me and I felt like a failure. It took several conversations over beers with my boss and my agile mentors, Scott Brown, John Miller and Luanne Willimon, to realize that, while it was my responsibility to set and communicate the process, it was not my responsibility to enforce individuals to follow it. I had neither authority over them nor the ability to influence them. I can provide guidance, therapy sessions, suggestions, and pros and cons around decisions, but I couldn’t make them do anything.



Up next in this series – Part 2:  “My Time to Evolve”

Stay informed. Subscribe to the Agile Management Blog now.

Learn about VersionOne’s ALM software

Posted in Agile Coaching, Agile Leadership, Agile Management, Agile Project Management, Agile Teams | 2 Comments