Project Management

Disciplined Agile

by , , , , , , , , ,
This blog contains details about various aspects of PMI's Disciplined Agile (DA) tool kit, including new and upcoming topics.

About this Blog

RSS

View Posts By:

Scott Ambler
Glen Little
Mark Lines
Daniel Gagnon
Valentin Mocanu
Joshua Barnes
Michael Richardson
Klaus Boedker
Kashmir Birk
Mike Griffiths

Recent Posts

Disciplined Agile: An Executive's Starting Point

Using Lean Agile Procurement (LAP) in complex procurement situations

Vendor Management in the Disciplined Agile Enterprise

Asset Management: What Types of Assets Might You Manage?

PMI and Disciplined Agile at Agile20Reflect

Put Practices in Context: #NoBestPractices

There is no such thing as a “best practice”, except perhaps from a marketing point of view.  All practices (and strategies) are contextual in nature.  In some situations a practice works incredibly well and it other situations a practice can be the kiss-of-death.  Two of the philosophies behind the Disciplined Agile (DA) tool kit are that choice is good and that you should understand the trade-offs of the options available to you.  In short, practices are contextual in nature and you should strive to adopt the ones that work best for the situation that you find yourself in.

Let’s work through an example.  A hot button for many people are strategies around cost estimation, typically used for budgeting and forecasting purposes.  In DAD initial estimation is addressed by the Plan the Release process goal, the goal diagram for which is shown below.  As you can see with the Estimating Strategy factor there are several options available to you.  We’re not saying that these are all of the potential estimating options available, but we are saying that this is a fairly good representative range.  The arrow on the left-hand side of the strategies list indicates that the strategies towards the top of the list are generally more effective for initial planning than the strategies towards the bottom of the list.  Your mileage may vary of course.

Plan the Release process goal

The following table summarizes the trade-offs involved with two of the estimating strategies, in the case formal point counting (such as function points) and an educated guess by an experienced individual.  One of the reasons why Choose Your WoW! is so thick is that much of it is tables like this communicating the trade-offs of the hundreds of practices and strategies encapsulated by the toolkit.  As you can see, there are advantages and disadvantages to both strategies.  You can also see that there are situations where each strategy potentially makes sense.  Although you may not like a given strategy, I personally abhor formal point counting, you should still respect the fact that the strategy is viable in certain situations (perhaps not yours).

 

Strategy Advantages Disadvantages Considerations
Formal point counting
  • Fulfills contractual obligations in some situations – for example, the US Government often requires function-point based estimates.
  • Provides a consistent way to compare projects and team productivity.
  • Often increases the political acceptability of the estimate due to the complexity of the effort to create it.
  • Greatly extends the Inception phase effort.
  • Provides a scientific façade over the estimation activity, even though estimation is often more of an art in practice.
  • Reduces team acceptance of the estimate because the estimate is typically produced by a professional estimator.
  • Historical data won’t exist for new technology platforms or development techniques, requiring you to guess the value of some complexity factors.
  • Provides a mechanism to compare the productivity of development teams, which can motivate them to over estimate and thereby decrease comparability and the value of your historical database.
  • Total cost of ownership (TCO) is very high as it motivates questionable specification practices, which in turn motivate change prevention and other poor behaviors by the development team.
  • Overly long estimation efforts in an effort to get the “right answer” often prove to be far more costly than the actual benefit provided.
  • Beware of misguided desires for “accurate” or “consistent” estimates which prove costly to produce in practice yet don’t improve the decision making ability of senior management to any great extent
Educated guess by experienced individual
  • Very quick and inexpensive way to get a reasonable estimate.
  • Requires that you have an experienced person involved with your project (if you don’t, then you should consider this a serious risk).
  • Explicitly reveals to stakeholders that estimating is often more art than science.
  • Some stakeholders may be uncomfortable with the fact that you’re guessing.
  • Beware of estimates by people who are inexperienced with the platform or domain or who do not know the abilities of team.

 

There are several reasons why DAD’s goal-driven approach is important:

  1. It makes your choices explicit.  If your team wants to truly own your process then it first needs to know what choices are available to it.
  2. It makes it clear that practices are contextual in nature.  No practice is perfect for all situations, every single one has advantages and disadvantages.  Are you choosing the ones that are most appropriate for your situation?
  3. You can have more coherent discussions of the trade-offs that you’re making.  We have endless religious battles in the IT industry around process-related topics.  This often happens because people choose to focus on the benefits of their favorite practices and to downplay the disadvantages (or worse yet are oblivious to them).  To help your team move to more effective practices it’s important to recognize the trade-offs involved with each, to then discuss them rationally, and then decide to adopt the strategy that is most viable given your situation.  Note that this doesn’t necessarily mean that you’re going to adopt the best practice from the start, but that instead you’ll adopt the best one that you can right now.  Later on, perhaps as the result of a retrospective, you’ll decide to make improvements to your approach (in the case of process factors where the strategies are ranked by effectiveness, your team may choose to adopt a strategy higher in the list).
  4. Improves the effectiveness of retrospectives.  During a retrospective it is fairly straightforward to identify potential problems that you’re facing, what isn’t as easy is identifying potential solutions.  You can improve retrospectives by having these process goal diagrams available to you to suggest potential strategies that you should considering adopting.
  5. You can avoid reinventing existing practices.  Many very smart and very experienced people have found ways to deal with the same challenges that you’re facing today.  Furthermore, many of them have shared these strategies publicly.  If you don’t know that these strategies exist you are at risk of wasting time reinventing them, time that could be better spent adding real value to your organization.
  6. It enables scaling.  Teams in different situation will make different process decisions.  Although teams at scale, perhaps they are large teams or geographically distributed, will follow many of the same practices as small co-located teams they will also adopt a few strategies that make sense for them given their situation.   DAD’s process goals provide the insight that teams need to understand how they can address the challenges associated with the scaling factors that they face.

For a more detailed discussion about the challenges around “best practices”, you may find the article Questioning Best Practices to be an interesting read. 

Posted by Scott Ambler on: March 05, 2015 05:16 AM | Permalink | Comments (0)

Ranged Burndown Trend Charts

A few days ago I wrote about ranged burndown charts. Interestingly, if you track the ranges over time you end up with a chart such as the one below which corresponds to the estimating cone of uncertainty (depicted by the dashed lines).  It’s interesting to note that this example includes two common occurrences that you’ll see.  First, during iterations one and two the gross and net velocities were the same because no new functionality had been identified yet, resulting in an unranged estimate.  Second, iteration eight had a very small net velocity because the amount of new functionality was almost as much as the amount implemented, giving a huge estimation range due to the small net velocity.

Image

Posted by Scott Ambler on: December 22, 2011 12:46 PM | Permalink | Comments (0)

Ranged Burndown Charts

Previously I discussed the difference between gross velocity and net velocity and now I’d like to show why they’re important.  A ranged burndown chart, an extension to normal burndown charts which apply both the gross and net velocity, is shown below.  Where a burndown chart uses the (gross) velocity to predict a potential end date, and by extension gives a feel for the potential project cost, a ranged burndown gives a potential range of end dates/costs.  Giving a ranged estimate is a known best practice in the IT community.

Image

Because it’s possible that functionality can be dropped from a release part way through a project, perhaps because of a major shift in strategy or in an effort to hit a desired date, the net velocity will exceed the gross velocity that iteration.  In this case our advice is the use the change in requirements from the previous iteration to calculate the net velocity.

Note that this blog posting is excerpted from Chapter 10 of the book Disciplined Agile Delivery.

Posted by Scott Ambler on: December 14, 2011 12:57 PM | Permalink | Comments (0)

Two velocities: Gross vs Net.

A few years ago, in Dr. Dobb’s Journal I wrote about estimating on agile development projects.  In that article I discussed burndown charts and how to extend them to show an estimation range.  The basic observation is that there is really two velocities exhibited by a team, the gross velocity and the net velocity.  The gross velocity which is the amount of work they complete in an iteration, which is what a regular burndown chart shows.  The net velocity is the change in the amount of work still to do, which is the amount of work completed in an iteration less the added amount of functionality that iteration.

Image

So, as the diagram depicts if a team completes 20 points of work in an iteration but 5 extra points of work was added by the stakeholders, the gross velocity is 20 points whereas the net velocity is 15 points.  If there’s 230 points on the stack then the gross velocity implies that there are 12 iterations left and the net velocity 16 iterations, providing you with a ranged estimate.

Given that we now have two velocities to chart, not just one, this leads us to evolve burndown charts into what is called ranged burndown charts.

Posted by Scott Ambler on: December 07, 2011 11:24 AM | Permalink | Comments (0)
ADVERTISEMENTS