Project Management

Disciplined Agile Applied

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

About this Blog

RSS

Recent Posts

#NoFrameworks at Agile Middle East 2020

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

#NoFrameworks at Agile Middle East 2020

Categories: Disciplined Agile

I'm proud to say that I will be giving the opening keynote speech at Agile Middle East (ME) 2020 on March 11th in Dubai. My title of my keynote is #NoFrameworks: How We Can Take Agile Back! which is a reprise of my keynote from the XP 2019 conference last May in Montreal. 

A fundamental philosophy from the early days of Agile is that teams should own their process. Today we would say that they should be allowed, and better yet, enabled, to choose their own way of working (WoW).

This was a powerful vision, but it was quickly abandoned to make way for the Agile certification gold rush. Why do the hard work of learning your craft, of improving your WoW via experimentation and learning, when you can instead become a certified master of an agile method in two days or a program consultant of a scaling framework in four? It sounds great, and certainly is great for anyone collecting the money, but 19 years after the signing of the Agile Manifesto as an industry we’re nowhere near reaching Agile’s promise. Nowhere near it.

Agile had it right in the very beginning, and the lean community had it right all along – teams need to own their process, they must be enabled to choose their WoW. To do this we need to stop looking for easy answers, we must reject the simplistic solutions that the agile industrial complex wants to sell us, and most importantly recognize that we need #NoFrameworks.

As you can see from the conference schedule there is a great line up of speakers. To help support the conference Project Management Institute (PMI) has gotten the organizers to agree to a 20% discount when you use the code "PMI" in all caps when you register. I'm looking forward to the event and if you're in the area I hope you will choose to attend the conference.

Posted on: January 31, 2020 05:21 AM | Permalink | Comments (8)

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)
ADVERTISEMENTS

I hope, when they die, cartoon characters have to answer for their sins.

- Jack Handey

ADVERTISEMENT

Sponsors