Disciplined Agile Applied

Earlier today I was on a call where we discussed the results of a research study.  I brought up the issue that it would be really interesting to parse that data by project type so as to determine whether there are different behaviours associated with each type.  Unfortunately the researchers hadn't asked about project type, but perhaps next time they could do so.  

This then led to the issue of what types of projects occur that they should ask about, and I then volunteered to put together a list.  My original thought was that surely there was a common taxonomy out there somewhere, but I couldn't find a solid one.  There are several opinions about the subject, as far as I could tell, but nothing that's generally accepted within the community.  

So I started putting something together based on the various articles and papers that I did find.  Here are my questions to you:

1. Do you know of an accepted project type taxonomy that I missed that is at least as comprehensive as what I have below?
2. What do you think of the list that I've developed?  Imagine for a minute that this list was presented to you as options in a survey question.  Can you identify the type of project that you're currently involved with?
3. Would you want to be able to select more than one option to describe the primary project you're currently involved with, or is single selection sufficient? 

Potential project types:

• Business implementation
• Foundational (business improvement)
• IT infrastructure improvement
• Product development (IT)
• Product development (non-IT)
• Physical engineering/construction
• Physical infrastructure improvement
• Procurement
• Regulatory/compliance
• Research and Development (R&D)
• Service development
• Transformation/reengineering
• Other

Looking forward to hearing your thoughts on this matter!

We are often asked how Disciplined Agile (DA) and PMI-ACP fit together and whether DA is meant to replace PMI-ACP.  Fair enough.  So I thought I would write this short blog to help clear the air.  Here are the key points:

1. PMI-ACP isn't going away.  The PMI-ACP program has been very successful, so of course we're keeping it.
2. DA and PMI-ACP fit well together. We will release an updated agile certification roadmap towards the end of August that makes this very clear.  We're currently finalizing our testing of the strategy out in the marketplace and will publicly release it very soon. Stay tuned here for a detailed announcement.
3. The PMI-ACP certification will evolve over time. At some point it would be reasonable to see the ACP certification explicitly include the advanced agile and lean concepts that DA encompasses.  Don't worry, we'll let you know about any changes to the PMI-ACP certification long before they happen, just as we do with other certifications.
4. PMI-ACP and DA are running in parallel right now. The two programs each have their own schedules. When and if we decide to merge them in some way we will make that clear to everyone.  
5. We're working together.  The DA team is working with many teams within PMI to bring you world-class offerings, including the ACP team.

In summary, you don't have anything to worry about and it's only getting better. 

Update: We now have an Agile Certifications landing page that explains the program.

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.

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:

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.