Project Management

Disciplined Agile

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

About this Blog

RSS

Recent Posts

The Art of Guesstimation: Why Shouldn’t We Estimate?

The Art of Guesstimation: Why Should We Estimate?

The Art of Guesstimation: Estimation on Software Projects

Planning: The Efficiency Zone

Planning: When Have We Done Enough?

The Art of Guesstimation: Why Shouldn’t We Estimate?

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.

 

Posted on: January 17, 2020 12:00 AM | Permalink | Comments (5)

The Art of Guesstimation: Why Should We Estimate?

In the previous blog in this series, The Art of Guesstimation: Estimation on Software Projects, we explored the differences between guesstimates and estimates, and in this blog I will use the term estimate to refer to both.  Because estimation isn’t limited to projects I will use the term endeavor to refer to efforts that are organized either as a project or as a non-project. As Simon Sinek suggests in Start With Why: How Great Leaders Inspire Everyone to Take Action we should start by explaining why something is important.  From that point of view, it makes sense to ask why should invest the effort to estimate the time or cost of an endeavor? 

Estimates are often required for several reasons:

  1. We want to allocate funding for an endeavor.  We are often asked to estimate the cost of the next stage of an endeavor, be that the work required to build the next release of a system or the work for the next stage of a project. Cost estimates are often required as input into the decision process around fund allocation within your organization’s portfolio management efforts.
  2. We want to financially govern our endeavors.  Allocating funds to endeavors is an important initial step but we should also monitor how those funds are spent over time.  Organizations that are new to financial governance will often choose to track actual expenses against estimated costs, perhaps calculating the cost performance index (CPI) from Earned Value Management (EVM).  EVM is a common strategy for teams taking a traditional/serial approach, sometimes called a “predictive” approach, and some organizations will apply EVM to agile teams as well. As organizations mature and adopt more effective ways of working, such as those captured in the Disciplined Agile (DA) toolkit, they learn it is better to focus on tracking value delivery rather than cost.  Instead of asking “Will we be on budget?” they instead ask “Are we investing our money wisely?”  These are two very different questions, the latter producing better outcomes through greater discipline.  
  3. We need to coordinate our efforts with others. Other teams will have dependencies on what our team delivers, and as a result we will need to estimate the time required to produce what they require and when we expect to make it available to them.  This is particularly common when our customers need to do their own planning around our delivery dates.  For example, if we’re a construction company building a new home for someone our customers will want to know when it will be ready to be moved into.  Or perhaps our team is building a system where some of the software components will be reused by other teams.  In this case these teams may want to know when the interface for the component will be defined, when the test harness for that component is in place, and when the team intends to deploy the working component into production.  
  4. We want to govern our timelines. Just like we want to govern our financials we also need to govern our timelines. EVM’s Schedule Performance Index (SPI) calculation can be applied to determine a team’s variance from their estimated timeline.  This can be particularly important when our team has a hard date to hit, perhaps due to regulatory compliance or a contractually promised delivery date.  Unfortunately SPI can give a false sense of security to teams following a traditional/serial strategy, particularly traditional software teams because they tend to push a lot of their risks to the end of the lifecycle.  On traditional software projects CPI and SPI indicators can be tracking well until you get to system integration testing (SIT) or user acceptance testing (UAT) where (surprise!) your project runs aground because when you finally detect serious quality problems that prevent you from shipping. Disciplined organizations have instead shifted from the question “Are we on schedule?” to instead focus on answering “Are we deliver value to our customers when they actually need it?”  The latter question motivates better behavior by the team because it reflects that fact that the needs of our customers will evolve as their situation changes over time.  In other words, delivering something on schedule that people no longer want should hardly be considered a success.

To summarize, there are several reasons why we should consider investing the time and money required to produce estimates.  In the next blog in this series I will explore reasons for why you don’t want to invest effort in estimating.

Posted on: January 15, 2020 08:45 AM | Permalink | Comments (8)

The Art of Guesstimation: Estimation on Software Projects

This is the first of several blog postings that I'm going to write on the Art of Guesstimation.  I guesstimate that I'll be writing 7 +/- 2 postings on this subject, depending on how our conversation progresses and how I decide to divide the overall topic into blog postings (I currently have a plan but I suspect it will evolve based on feedback).  My eventual goal is a detailed article on the subject, likely sometime in February 2020.

 

Guesstimation?  

You've liked noticed that I have been using the term guesstimate rather than estimate.  This isn't a typo.

In early December I was in Las Vegas at SeminarsWorld co-teaching the inaugural Disciplined Agile Lean Scrum Master (DALSM) workshop with Al Shalloway.  One of the topics that we covered was Agile Estimation where I brought up the fact that estimates are often guesses, particularly in the IT space.  This was a bit of a shock for some students as it went against their project management belief system.  Interestingly one student had a story about they had recently had a conversation about this very issue with some of her stakeholders when they weren't given the "exact answer" as to the potential cost and schedule of an IT project they were about to embark upon. 

So let's move away from a belief-based discussion in favour of a fact-based discussion by seeing what the dictionary has to say on the subject.  Merriam Webster defines estimate as:

  1. The act of appraising or valuing 
  2. An opinion or judgement of the nature, character, or quality of a person or thing
  3. A rough or approximate calculation

So, particularly given 2 and 3, there is a bit of wiggle room in our estimates.  Now let's consider the definition of guesstimate, which has been a "real word" since 1923.  According to Merriam Webster, a guesstimate is an estimate usually made without adequate information.  Hmmm.... sounds a lot like the situation faced by most teams in the software space, doesn't it?

The traditional response to the problem of inadequate information is to perform detailed analysis and design early in a project.  In theory this should work, but it flies in the face of several unfortunate challenges faced by software teams:

  • Stakeholders are not very good at defining what they want when it comes to intangible things such as software, usually because they just don't know what they (don't) want until they see it (so work incrementally)
  • People change their minds when they do see it (so work collaboratively)
  • Their actual needs change over time, often due to changing conditions in their marketplace (so deliver quickly and often)
  • The solution space changes constantly, with new technologies and platforms emerging on a regular basis (so be technically adept)

None of these challenges are addressed well by detailed, up-front modelling and planning.  The unfortunate reality is that at the beginning of a software project, and I suspect for any project similarly focused on intangible things, the information that we will base our initial estimates on will be vague at best.  This tells us that in the early days of a software project we are clearly guesstimating.  As the project progresses our stakeholders have a better understanding of what they actually need and the team has a better understanding of how they're going to meet those needs.  The implication is that over time we can tighten up our guesstimates until we eventually find ourselves in a situation where the term "estimate" begins to become viable. 

 

Future Postings

Future postings in this series will focus on how estimates are really probability distributions, what we're really saying when we say "on time" or "on budget", why we should provide ranged guesstimates even though many people still want to hear "exact" estimates, truisms about guesstimation, and how Disciplined Agile (DA) improves upon Agile's classic burn down and burn up charts to provide ranged estimates.

 

 

Posted on: December 14, 2019 07:50 AM | Permalink | Comments (18)

Planning: The Efficiency Zone

Categories: Planning

Yogi Berra was fond of saying “If you don’t know where you are going, you’ll end up someplace else.”  What Yogi was getting at was that it’s a good idea to do a bit of thinking, a bit of planning, before you get started.  In the previous blog, Planning: When Have you Done Enough? we explored the factors that affect how much planning we should do.  The challenge is that the factors are qualitative in nature, requiring us to make a decision that is based on intuition.  

In this blog we explore how to increase the chance that we get as close as we can to achieving the maximum value from our planning efforts.  The following figure is organized into four planning quadrants, each one of which represents a target area for our planning efforts.  

Figure – The four quadrants of planning efficiency.

Planning quadrants

Let’s explore each quadrant.  In order from most desirable, to least desirable, they are:

  1. Q1: Efficient. The most efficient approach is to do a bit less planning than is sufficient, to undershoot the mark.  The idea is that you want to get close to sufficient and be prepared to explore the aspects of your plan later in the lifecycle when you discover that it’s insufficient.  This strategy assumes you have easy access to the subject matter experts (SMEs) and decision makers, thereby enabling you to quickly adjust and evolve your plan as needed.
  2. Q2: Comfortable. Some people will aim for this quadrant out of the believe that they need to think everything through right now, that they won’t be allowed to update the plan easily later on in the lifecycle.  Although this is comfortable for people who are new to Disciplined Agile (DA) ways of working (WoW) it is also wasteful because they’ve invested too much on the planning effort.
  3. Q3: Insufficient. This is where a lot of agile purists, or non-managers who are new to agile, end up. When planning is grossly insufficient like this your team tends to work in an undirected manner that results in a lot of rework later.
  4. Q4: Wasteful. This is where a lot of traditional managers who are new to agile WoW land. This strategy is particularly problematic in areas where there is great uncertainty, in particular software development where requirements and underlying technologies change rapidly.  Planning efforts that land in quadrant 4 are often caused by impedance mismatch between the expectations of the people doing the planning, or the expectations of the people who require a detailed plan before the rest of the work commences, and the reality of the situation on the ground.  Very often the environment has changed but the planning methodology hasn’t, so lighten up.

Eisenhower said “Plans are worthless, but planning is everything.” There can be significant value in planning, but it is possible to go too far, to plan too much.  Although more research is needed in this space, it appears that the value of planning follows the law of diminishing returns – there is significant value in doing some planning, but that value quickly reaches a maximum point. Determining that maximum point is a qualitative, “gut feel” decision based on a collection of factors such as the complexity and risk of the situation, the skills and experience of the people involved, and the uncertainty that you face.  Surprisingly, the most efficient approach to planning is to aim for your plans to be slightly insufficient, to be close but in need of a bit more work when you discover that you need to work through a few more details.  I hope this blog series has been food for thought.
 

Posted on: November 19, 2019 06:39 AM | Permalink | Comments (14)

Planning: When Have We Done Enough?

Categories: Planning

In the previous blog we examined what the value of planning is, so that we can then determine how much planning we need to do.  The answer to this question was “it depends,” and the implication was that we need to do just enough planning for the situation that we face and no more.  In this blog we go deeper to explore what this depends on in practice.

We learned in the previous blog that our planning efforts should be sufficient, what we referred to as just barely good enough (JBGE) in Agile Modeling, for the situation that we face.  The following figure depicts the contextual factors that we should consider, with the factors motivating us to do more planning on the left-hand side under the red arrow and the factors enabling us to do less planning on the right-hand side under the green arrow.  These factors are mostly qualitative in nature, implying that it requires a judgement call on the part of the people involved with the planning effort to determine whether they’ve planned sufficiently. Let’s explore each of these factors in more detail.

Figure. The factors to determine whether you’ve planned sufficiently.

There are four factors that motivate us to increase the amount of planning we do:

  1. Risk. The greater the risk that we face the more we will want to think before we act.  For example, transporting perishable medical supplies from Toronto to Timbuktu requires more logistical planning than transporting a box of Choose Your WoW! books from Toronto to Philadelphia.
  2. Domain complexity.  The more complex the problem that we’re trying to solve, the more we want to invest in exploring the domain and then thinking through how we will address the complexity.  For example, building a bridge across a river is more complex than building a dog house, so we will invest more time thinking through the building of the bridge.
  3. Solution complexity. The greater the complexity of the solution that we are building, or configuring in some cases, the more thinking we will need to do.  For example, installing an ERP system into an existing organization to replace dozens of legacy systems requires more planning than installing a new app on your phone.
  4. Desire for “predictability.” This can be a common cultural challenge within organizations, in particular the desire to be told up front how much a project will cost or how long a project will take.  These are fairly reasonable requests when the endeavor is something our team has experience in doing, such as a house builder being asked to build a new house. They are unreasonable requests when the team is being tasked with doing something that is ill-defined or whose scope will change throughout the endeavor, the situation typically faced by software development teams.  Far too many times I’ve seen teams run aground due to an unrealistic request for predictability – the teams will overly invest in up-front modeling and planning, will then make promises regarding cost and schedule that either they’re unable to keep or can only keep by cutting scope or quality of the delivered solution.

There are six factors that enable us to reduce the amount of planning that we need to do:

  1. Skill.  The greater the skill of the people doing the work, the less planning will be required for that work. 
  2. Experience.  The greater the experience of the people doing the work, the less planning will be required for that work.
  3. Ease of change. The easier it is to change the work products being produced, including the solution itself, the less planning is required.  For example, we are developing a website it is relatively easy to update and then redeploy web pages if we discover that they need to evolve.  So we can get away with minimal planning.  Conversely, if we are building a bridge spanning a river it is relatively difficult and expensive to rebuild a supporting pillar in the middle of the river if we discover that it was placed in the wrong spot. In this case we face greater deployment risk so we need to invest in greater planning to increase the chance of getting things right.
  4. Access to stakeholders.  The easier it is to access stakeholders, in particular decision makers who can provide direction and feedback to us, in general the less initial planning we need to do.  Being able to work closely with stakeholders enables us to think through the details when it’s most appropriate during a project, not just up front.
  5. Communication and collaboration. The greater the communication and collaboration within a team, perhaps because we’re co-located in a single room or because we are using sophisticated communication software, the less planning is required due to the increased opportunities for streamlined coordination. 
  6. Uncertainty. The more likely that something will change the less planning you should do because when it does change your planning efforts around it will have been for naught. 

To summarize, the answer to “when have we planned sufficiently?” is “it depends.”  In this blog we explored several factors that motivate you to increase the amount of planning we need to do and several factors that enable us to reduce the amount of planning.  In effect we went beyond the typical consultant answer of “it depends” to the more robust answer of “it depends on this.”  

In the next blog in this 3-part series we explore how to be efficient in our planning efforts. I suspect the answer it won’t be what you’re expecting.

Posted on: November 04, 2019 09:42 AM | Permalink | Comments (12)
ADVERTISEMENTS

When someone is lying, is it true that their pants are actually on fire?

- Jerry Seinfeld

ADVERTISEMENT

Sponsors