I'm often asked how can someone learn about the Disciplined Agile (DA) tool kit. There are several ways that you can do so:
I was recently part of a business agility webinar for PMI's MENA (Middle East and North Africa) chapters. At the very end of the webinar we were asked a question that was along the lines of "How can you apply DA when you're unable to adopt new technologies?" which I answered quickly as we were out of time. My answer was a bit harsh at the time, which I share below, and in hindsight I wish I'd had time to answer more thoroughly. Hence this blog posting which presents a more thorough answer.
First, improvement doesn't always require new technology. Many of the techniques referenced by the Disciplined Agile (DA) toolkit are technology independent. For example, consider the Coordinate Activities process goal diagram of Figure 1. Many of the techniques are manual in nature, such as Agile Modeling sessions (OK, you require the "technologies" of whiteboards, markers, and sticky notes), architecture owner teams (a cross-team group of people), and release windows (scheduled times when it's possible to release/deploy something to your customers). On the other hand, some improvements may require new technologies. For example, the strategy of adopt collaborative tools to coordinate between locations explicitly requires the adoption of agile management tools such as Atlassian's Jira or Zoho's Sprints. The point is that your organization's potential inability to adopt new technologies doesn't completely prevent you from making improvements to your way of working (WoW). As always, it depends.
Figure 1. The Coordinate Activities process goal.
Second, it's not that you can't adopt new strategies, it's that organizationally you choose not to. Stop looking for excuses to not improve, to not do what needs to be done for your organization to survive in the new competitive landscape that you face. Really. You need to stop making excuses. Your competitors are finding ways to adopt new technologies and so can you. You need to start making some hard choices now. My recommendation is that choose to succeed, and then choose to do the hard work required to do so.
Third, if you can't respond and improve quickly in the age of COVID-19 you're not likely to survive. This was pretty much my answer in the webinar. If there are groups in your organization preventing you from making the improvements that you need to compete and better serve your customers then you need to remove those blockers now. This may mean that you educate those people as to why you need to improve, help them find budget to support the changes, or even ask them to get out of your way. Yes, that final strategy may require leadership within your organization to rethink whether those people should still be employed by your organization - even if that includes some of them.
Fourth, helping your organization improve sounds like a great opportunity for your project management office (PMO). Earlier in the webinar PMI's Srini Srinivasan had addressed the issue of what role PMOs have in an agile organization. He understandably indicated that PMOs must offer real value and be seen doing so. If your organization is struggling to make the changes it needs to improve, that sounds like a pretty good opportunity for a PMO to add tangible value.
I can't tell you exactly what the "new normal," or perhaps more accurately the "new abnormal," will be in the COVID-19 and post COVID-19 environments. But I know that it will be much more competitive than what you've been used to up until now. I also know that it will require you to be able to better sense and respond to the changes in your environment. The Disciplined Agile (DA) tool kit can help you to do exactly this.
For years I’ve been involved with estimating a wide variety of things, have read about and then experimented with different estimation strategies, and taught and coached others in estimation. I’ve worked with, and learned from, hundreds of people who also have a wide range of estimation experience. Throughout all this I’ve identified several things that I believe to be true about the act of estimation.
In my experience, the quality of an estimate increases when:
The further away you are from these truisms the less dependable an estimate will be. As the old saying goes, “garbage in, garbage out.”. In the next blog in this series we will explore the trade-offs associated with estimation.
I recently wrote an article for PMI's ManageIndia magazine entitled Going Beyond Remote Agile: Are You Ready For Your Next Change? In the article I argue that coronavirus disease (COVID-19) is a “black swan event” that has forced most organizations to scramble to figure out how to do their work remotely. Many agile teams are struggling to work remotely, this being particularly tough for some agilists who had mistakenly convinced themselves that they needed to be co-located to be agile. Most teams now are well on the way to adopting common solutions to this challenge.
But what about next time? I work through five important points to lead you to organize your work smoothly and what you can do the next time you need to identify a new way of working (WoW):
We live in interesting times. The article Going Beyond Remote Agile: Are You Ready For Your Next Change? goes into detail and should provide valuable insights. You can download the full issue of PMI's ManageIndia April 2020 as a pdf.
A common practice is to present estimates in terms of ranges, such as $500K to $900K, rather than point-specific scalars such $650K. The size of the range that you provide reflects the quality of your understanding of what you’re estimating. PMI’s Practice Standard for Project Estimating (2nd Edition) suggests an initial guesstimate of -25% to +75%, in general, on projects. We want to present our estimates in ranges so as to set realistic expectations with our stakeholders.
Your mileage may vary, sometimes dramatically. Barry Boehm, one of the most respected researchers in the software engineering world, has found that a range of -75% to +300% occurs in practice on software projects (see Software Engineering: Barry W. Boehm's Lifetime Contributions to Software Development, Management, and Research). The initial range is so large because our stakeholders often don’t know what they want, or can’t agree on what they want, and thus it makes it very difficult to estimate. As Boehm shows this problem is particularly acute in the software world due to the flexibility of software, expectations around software, and the unfortunate tendency of software professionals to agree to requested changes (and then delivering on those promises in sometimes questionable manners). Marc Bastien presents an insightful exploration of these challenges in his recent book Understanding the Corporate IT Strategy Game.
Figure 1 is based on an actual software development project taking a “predictive” serial approach where the original estimate of 10 months was based on an up-front function point (FP) count. This is depicted by the first line in Figure 1, as a point-specific scalar estimate. But as we know estimates are probability distributions and should therefore be presented as a range. The second line in Figure 1 shows the initial estimate as a probability distribution. Although it appears to have a large range, which can be disconcerting to anyone hoping for a scalar estimate, this team was able to tighten the range to be 9 to 13 months due to the significant investment they made in function point counting. Over time, as our understanding improves and the uncertainty shrinks the range of the estimate also shrinks.
Figure 1. Ranged estimates will narrow over time on a healthy project.
An interesting aspect of Figure 1 is that after 3 months you can see that the range of the estimate has tightened a bit and has shifted to the right (the project is likely to take longer than originally believed). Notice how I said likely to take longer and not going to take longer – that’s because estimates are probability distributions and not certitudes, so I choose to be careful with my language and not imply that the estimate is precise. Similarly, at the six month point we’re seeing a much narrower range, that’s because we have a much better understanding of both the problem we’re hoping to solve and the solution that we’re implementing to do so. Figure 1 indicates that the likely project delivery date is clearly slipping over time, with a peak of about 10 months, 13.5 months, and 14.5 months respectively. Needless to say the project manager had a few testy conversations with the project stakeholders throughout this period. In the end this team delivered at the 16 month point and then had a second release 6 months later to address quality problems and dropped scope as the result of the “rush job” required to release after 16 months. So the 10 month project took 22 months in practice.
Tracking Ranged Estimates Over Time
An estimation trend chart, see Figure 2, is a useful way to depict ranged estimates over time. This diagram corresponds to what we saw in Figure 1, albeit with monthly rather than quarterly estimates. The vertical bars represent the ranged estimate each month and the dashed lines are the smoothed trend lines for high and low ends of the ranges. These two lines indicate what is called the “cone of uncertainty,” an indication of relative risk surrounding the precision of your estimates over time. On a healthy project the two lines will converge at the end of the project, on an unhealthy project that is trending towards failure they will not converge (more on this in a minute).
Figure 2. An estimation trend chart.
At the start of a project you will very likely begin with a guesstimate, which is an estimate with a very wide range. Over time the range narrows and your guesstimates evolve into estimates. The point at which guesstimates are considered estimates is up to your organizational culture. In the case of the project depicted in Figure 2, I suspect that was around the fourth or more likely fifth month of the timeline.
I would be remiss if I didn’t point out that if your estimation range isn’t shrinking over time then that is a sign that your project is in trouble. There are several potential causes for this to happen, including a lack of agreement amongst stakeholders as to the scope of the effort, an inappropriate solution architecture/design strategy, or challenges around how your team is formed (typically you don’t have the right people or sufficient people to get the job done). In Disciplined Agile (DA) we specifically address these common risks via the stakeholder agreement milestone, the proven architecture milestone, and explicit advice about forming teams respectively. In short, on healthy projects your ranged estimates will tighten over time and on unhealthy projects, if you’re being honest in your estimations, they very likely will not.
The fact that estimates should be presented in ranges is a critical concept for both your executives and your stakeholders to accept. If they don’t understand the implications of this, and that these ranges really represent probability distributions, then they will not be able to govern effectively. In the next blog in this series I’m going to share a collection of truisms about estimation that I believe you will find interesting.