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.
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:
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.
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:
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.
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.
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:
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:
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 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.