Project Management

Disciplined Agile Applied

by
This blog explores pragmatic agile and lean strategies for enterprise-class contexts.

About this Blog

RSS

Recent Posts

Getting Started With Disciplined Agile (DA)

How to Improve When You Can't Adopt New Technologies Easily

The Art of Guesstimation: Truisms for Better Estimates

Going Beyond Remote Agile: Are You Ready For Your Next Change?

The Art of Guesstimation: Updating Ranged Estimates Over Time

Getting Started With Disciplined Agile (DA)

You'll wish you started today - Getty Images

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.

 

 

 

Posted on: June 17, 2020 07:40 AM | Permalink | Comments (8)

How to Improve When You Can't Adopt New Technologies Easily

Technology

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.

Disciplined Agile Process Goal: Coordinate Activities

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.

 

Posted on: May 27, 2020 03:46 AM | Permalink | Comments (6)

The Art of Guesstimation: Truisms for Better Estimates

Categories: estimation, guesstimation

On targetFor 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:

  1. The work is small. For example, it’s easier to estimate the amount of liquid in your water glass than it is to estimate the amount of water in the ocean.
  2. The work is near term. We have greater motivation to think through an estimate when we’re just about to do something than if that work will be done at some point in the future.
  3. The work is understood. Imagine someone coming up to you and saying “I’d like you to update the web site, how long do you think that will take?” The request is far too vague to respond with a reasonable estimate. Until you identify what that update is, there’s a big difference between fixing a grammar mistake on a page and adding an ecommerce marketplace to sell products on your site, you really can’t estimate the work.  Furthermore, you also need to understand the architecture of your site and the work processes involved with updating it.  Fixing and deploying a grammar mistake may be five minutes of effort or five hours of effort depending on your environment.
  4. The work is stable. When the requirements for the work change so must the estimate. What seem to be simple requests, such as asking for multi-currency support in your ecommerce marketplace when you originally said you only needed to support a single currency, can be an expensive and time-consuming change.
  5. You know who is going to do the work. People are unique, they aren’t fungible resources that you can easily swap.  For example, when building a fence, a team of three people who build fences for a living will very likely get it done faster, better, and for less cost than a team of three people who are building a fence for the first time.  A master craftsperson with years of experience may be 10 times or even more productive than a novice.  In software development, studies have shown that the most productive programmers are 25x more effective than the least productive programmers.  And we all know that some people just aren’t going to work well with others, so team configurations are also important considerations.
  6. The process and tools are understood. When estimating how long it will take to dig a hole for the foundation of a house, it would be good to know if it’s being dug by three people with shovels or one person with a backhoe.  
  7. The estimator is also the doer.  Someone who is going to do the work is much more motivated to get an estimate right than someone who isn’t going to do the work. 
  8. The estimate is being committed to.  When you know that you’re going to be held to the estimate that you produce you are much more motivated to get it right.
  9. The estimator has done this sort of work before.  People who have done the work before have a better understanding of the issues involved than people who haven’t.  
  10. There are several estimates being combined.  In high-risk situations I strive to estimate something using several different strategies, ideally involving different people, and then combine the results to get a better quality estimate.
  11. It is treated as a probability distribution. By treating estimates as probability distributions (which they are), and not as point-specific scalars, we can apply our estimates in a realistic manner.

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.

Posted on: April 22, 2020 06:00 AM | Permalink | Comments (6)

Going Beyond Remote Agile: Are You Ready For Your Next Change?

Categories: India, MANAGEIndia, Remote Work

ManageIndia April 2020I 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):

  1. Recognize that remote agile isn't new. Others have already dealt with the challenges that you face.
  2. Geographic distribution is only one of several scaling factors that you face. You may need to address other, even harder, challenges in the future. 
  3. Choice is good. If you know what options are available to you, it's easier to choose your WoW to meet the context that you face.
  4. You don't need to work everything out on your own. The Disciplined Agile (DA) toolkit provides consumable, proven, agnostic, and pragmatic options.
  5. We need to do better than "fail fast." You can fail a lot less often with a bit of help that we call guided continuous improvement (GCI).

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.

Posted on: April 14, 2020 08:36 AM | Permalink | Comments (6)

The Art of Guesstimation: Updating Ranged Estimates Over Time

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.

Ranged estimates over time

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.

Ranged estimate 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.

 

Posted on: April 02, 2020 10:12 AM | Permalink | Comments (5)
ADVERTISEMENTS

"I love deadlines. I love the whooshing sound they make as they fly by."

- Douglas Adams

ADVERTISEMENT

Sponsors