Disciplined Agile Applied

We just released DA 5.4 today. The release notes are published here. Several interesting points:

1. We published the details behind the Portfolio Management process blade. In future releases we're going to continue to publish more details like this.
2. We published all of the goal diagrams for the process blades as we have them to date. There are several that we have not yet published, such as Sales and Finance, but about 2/3 are there now. 
3. We had originally aimed for January 15th but I allowed the schedule to slip a bit. Hopefully that won't happen again. Next release is scheduled for the last week of March, either March 24th or March 25th.

My question to you: What would you prefer we focus on for the DA 5.5 release? Should we finish the goal diagrams for the other process blades, or should we focus on documenting the details behind the diagrams we have? Depth or breadth?

I'm often asked how can someone learn about the Disciplined Agile (DA) tool kit.  There are several ways that you can do so:

1. Watch a 2 minute video. We recently released a short video that summarizes key aspects of DA.    
2. Read a 5 minute article. The article Introduction to Disciplined Agile is a short overview of the four layers of DA.
3. Attend a Disciplined Agile (DA) presentation hosted by your chapter.  Many PMI Chapters now have DA Champions who can either give a DA presentation themselves or invite a DA partner to give a great presentation.
4. Take a 8 module online workshop. Our self-paced, online workshop the Basics of Disciplined Agile takes a scenario-based approach to teaching you fundamental DA concepts and how to apply them.  Better yet, you'll earn 10 technical PDUs doing so.
5. Attend certification training. Training partners around the world are now offering 2, 3, and 4-day workshops to prepare people to certify in Disciplined Agile.  You can find training here.
6. Read a book.  The book Choose Your WoW! provides a comprehensive overview of the Disciplined Agile Delivery (DAD) portion of the DA toolkit, the DA mindset, and Guided Continuous Improvement (GCI). At 400 pages this book is a key reference for any agile software development team.

Estimation is an important skill required by many professionals. My experience is that there are three distinct levels of how people think of estimates.  My goal is to focus on the third level, estimates as probability distributions, in this blog.

Let’s begin with a quick overview of the three estimation mindset levels:

1. Estimates as point-specific numbers.  For example, a point-specific estimate would be that this is a million-dollar project that will take six months to complete.  In the case both the cost and time estimates are fixed, scalar numbers. This mindset often stems from a desire to have an “exact number” on which to base decisions.  
2. Estimates as ranges. An example of a ranged estimate is that this project will cost between $800,000 and $1.4 million and take between 4 and 10 months to complete.  In fact, PMI’s Practice Standard for Project Estimating (2^nd Edition) suggests that a project in the start-up phase, what Disciplined Agile (DA) calls Inception, may have a rough order-of-magnitude (ROM) guesstimate of -25% to +75%.  On software projects, Barry Boehm has found that -75% to +300% occurs in practice (see Software Engineering: Barry W. Boehm's Lifetime Contributions to Software Development, Management, and Research).  Yikes.  This estimation mindset often stems from discovering that “exact” estimates often prove to be unrealistic in practice and as a result they need to be more flexible in practice.
3. Estimates as probability distributions.  This is an evolution of ranged estimates in that it reflects the observation that there is a chance that a project will come in below budget (or early) and that there is a chance that a project will come in over budget (or late). This is a strategy that I first learned from Murray Cantor, author of Software Leadership, when I worked with him at IBM Rational.  This estimation mindset tends to be held by people with a strong background in mathematics, in particular statistics.

Figure 1 depicts an estimate as a probability distribution.  It shows a point-specific/fixed estimate, such as $1 million, which is aligned with the peak of the curve.  The area under the graph to the left of the fixed estimate point is the chance that the project will come in under budget and the area to the right is the chance that the estimate will come in over budget.  This probability curve would be determined from past history of previous projects within your organization.  The curve in Figure 1 is “positively skewed” in that there is more area to the right of the curve’s peak than to the left.  The implication is that there is a greater chance of the project being over budget than there is of it being under budget.

Figure 1. Estimates as probability distributions.

Let’s work through how you actually apply this knowledge in practice.  Figure 2 shows an estimate distribution for a fictional project where we are quoting estimates in terms of probabilities.  For example, the chance that this project will come in at $900K or less is the area under the graph to the left of that line, in this case it looks like it’s about 8%.  The chance that it will come in at $1M or less looks to be about 22%, $1.1M or less about 45%, and $1.2M or less about 65%.  The implication is that depending on the level of certainty your stakeholders require you can use this graph to provide an estimate that meets their need.  If your stakeholders wanted 95% surety, for example, then you’d find the point on the estimate distribution where 95% of the area is to the left of the line, in this case it looks like it would be around $1.5 or $1.6 million.  This would be a lot easier, of course, if you were using software to come up with these sorts of numbers rather simply "eye-balling" a graph.  Once again, all of these numbers are based on the past history of previous projects within your organization.

Figure 2. Quoting estimates as probabilities.

There are several challenges with the concept that estimates are probability distributions:

1. Many people don’t understand the concept of probability.  For example, I just opened the weather app on my phone and it says that there is a 70% of snow this hour.  So, if it doesn’t snow in the next hour is the app right or wrong?  It’s right, because there was a 30% chance that it wouldn’t snow.  But what if the app said there was a 90% chance that it will snow, but then it doesn’t?  The app was still right.  The point is that many people will hear a probability such as 70% or 90% and assume that it’s a certainty (100%).  Conversely, they’ll hear that there is a low probability of an event and then assume that it won’t happen and won’t be prepared if it does. 
2. People who desire “predictability” don’t like this idea.  There are still people who prefer the “certainty” of a point-specific estimate, or at least an estimate with a very tight range.  While these expectations might be reasonable on straightforward projects they certainly aren’t on projects where stakeholder needs or implementation strategies evolve constantly (as is typical on software projects, for example).
3. Estimates don’t follow a normal bell curve distribution.  As I indicated earlier, estimates tend to follow a positively skewed distribution.  This is the result of overly-optimistic estimation or pressure to produce an estimate that is palatable to decision makers.  This positive skewing can be frustrating for many people because the implication is that you’re more likely to be over budget or late than you are to be under budget or early respectfully.  

In the next blog in this series we’ll work through the strategy of ranged estimates in greater detail.  

I'm proud to say that I will be giving the opening keynote speech at Agile Middle East (ME) 2020 on March 11th in Dubai. My title of my keynote is #NoFrameworks: How We Can Take Agile Back! which is a reprise of my keynote from the XP 2019 conference last May in Montreal. 

A fundamental philosophy from the early days of Agile is that teams should own their process. Today we would say that they should be allowed, and better yet, enabled, to choose their own way of working (WoW).

This was a powerful vision, but it was quickly abandoned to make way for the Agile certification gold rush. Why do the hard work of learning your craft, of improving your WoW via experimentation and learning, when you can instead become a certified master of an agile method in two days or a program consultant of a scaling framework in four? It sounds great, and certainly is great for anyone collecting the money, but 19 years after the signing of the Agile Manifesto as an industry we’re nowhere near reaching Agile’s promise. Nowhere near it.

Agile had it right in the very beginning, and the lean community had it right all along – teams need to own their process, they must be enabled to choose their WoW. To do this we need to stop looking for easy answers, we must reject the simplistic solutions that the agile industrial complex wants to sell us, and most importantly recognize that we need #NoFrameworks.

As you can see from the conference schedule there is a great line up of speakers. To help support the conference Project Management Institute (PMI) has gotten the organizers to agree to a 20% discount when you use the code "PMI" in all caps when you register. I'm looking forward to the event and if you're in the area I hope you will choose to attend the conference.

In The Art of Guesstimation: Why Should We Estimate? we explored the reasons for why it can make sense to estimate the cost or time that an endeavor will require.  But this isn’t the whole story.  An important principle of business analysis, and in project management for that matter, is to not only define what is in scope but also to indicate what is out of scope. The implication is that it also makes sense to explore why we shouldn’t estimate an endeavor, which is the topic of this blog. 

There are several reasons why we should consider reducing the amount of effort we put into estimation if not eliminating it entirely:

1. Estimation takes time and money. There is a cost associated with creating an estimate. As with any other activity, we want to perform the least amount of work possible that gets the job done and no more because anything more than that would be a waste.  The article The Value of Planning provides a detailed explanation of the importance of creating artifacts, in this case estimates, that are just barely good enough (JBGE).  
2. Estimation is an overhead.  From a lean point of view we want to reduce, and better yet eliminate, any waste in our process.  As the #NoEstimates movement is very clear about, estimation is an overhead that does not directly add value to a customer (except in the form of providing inputs into their decision making process). At a minimum we want to find ways to reduce the amount of effort that we put into estimation and ideally to eliminate it completely where possible. 
3. People commit to important decisions too early. The more effort that we put into producing an estimate, typically because we desire greater precision in the estimate, the more motivated we are to commit to whatever decisions that we make when developing the estimate.  For example, to develop a reasonably precise estimate for a software project we may need to invest several weeks, or even months, to identify the requirements and architectural solution for an endeavor.  The more work that is put into defining the requirements, or the architecture, the greater our reticence to evolve those decisions later in the project.  Even in the face of a different market environment, or an improved understanding of what our customers actually want, we will be wary of rethinking the commitment that they made earlier to the original requirements upon which the original cost and time estimates were produced.  In effect we’ve made very important decisions early in the project when our understanding of the problem, or the potential solution, was vague at best. In the end we may be on time and on budget, but we’ll have produced the wrong solution to the problem and thus have still failed in the eyes of our stakeholders. 
4. Estimates answer the wrong questions. A cost estimate tries to answer the question “How much do we believe X will cost?” and a schedule estimate tries to answer the question “How long do we believe X will take?”  I appreciate that this will sound like heresy to many people, but should we not be focused on more interesting questions than that?  For example, rather than focusing on cost should we not strive instead to spend our money wisely?  Is getting a low-quality product on budget really a win?  Particularly when we’ll need a second effort to fix the quality problems?  Similarly, rather than focusing on a delivery date should we not strive to deliver what our customers need when they actually need it?  Is getting something built to specification delivered on time really a win when the requirements evolved while we were building the product?  Would it not be better to let the date slip and produce something people actually want, or deliver a partial solution early that meets some of their needs right now?
5. Better ways of working (WoW) require less estimation.  You can dramatically reduce the effort required to estimate something, and even eliminate it completely, if you adopt effective WoW.  For example, consider a long-standing team (often called a product team) who are following Disciplined Agile’s (DA) Continuous Delivery: Agile lifecycle.  This is a team of fifteen people and they release into production every Wednesday morning at 11 am.  Estimating the delivery date for the team is easy, it’s “Wednesday at 11 am.”  Estimating the cost of that release is also easy, it’s fifteen times the charge out rate for one person for one week.  It’s at this point in the conversation that people say that it’s not that easy, because you still need to indicate when you’re going to deliver a specific thing.  Yes, you’re still going to need to do a bit of work prioritization and in the case of regulatory work or contractual work you’ll have to size your work somehow, prioritize it, and manage to the date.  So keep your sizing effort as simple as possible, or organize your work into similarly sized chunks, which also requires a bit of effort to accomplish, to enable this level of work management.  In short, improve your WoW and squeeze out the management bureaucracy.

The point that I’m making is that although we’ve seen that there are reasons why we what to estimate time and cost there are also reasons why we don’t.  A fundamental observation of the Disciplined Agile (DA) toolkit are that there are no “best practices,” that every strategy has strengths and weaknesses, that every strategy makes sense in some situations and not others.  This observation applies to estimation, just like it applies to everything else.

In the next blog in the series we will work through why estimates are probability distributions.