Estimating and planning is in the heart of Agile software development

Evolving Agile

Back in 2001. a group of like minded bros coined the term Agile software development. It was a good name for marketing purposes and it must have helped methods such as Scrum and XP to catch on faster. And they did catch on, reaching the mainstream audience and large scale adoption.

Agile wanted to evolve. And yes — we did see some great innovations that came after 2001. New members of the Agile family were “The Kanban method”, “Continuous Delivery” and the “DevOps culture”, to name just a few. They are well thought off principles based on logic and best practices.

We have also seen some strongly marketed approaches that want to be branded as Agile, but (in my humble opinion) just don’t make sense. The Agile brand has become lucrative and brings in well payed jobs, so it is no wonder that newcomers want on board. My favorite nemesis from this lot is the so called “noestimates” approach. And I am not shy to say it.

Noestimates…

Planning is in the heart of Agile methods. Planning often and learning from experience. Failing and improving. This is what Agile is (almost) all about, continuous improvement through empirical control.

Planning requires metrics of some sort. Metrics are achieved by sizing objects of work. Since we do not have the option to see into the future, we estimate. While estimating, we achieve these lovely things:

• We size the object of work and can compare it with the budget and/or our available time
• We emerge the most efficient architecture, picking between options that are discussed during estimating, using lovely communication patterns we have at hand
• We get the most efficient people on the job, again — based on their personal estimate
• We exchange knowledge and engage the creative process, making sure that our junior team members learn along the way

The author of the “noestimate” “approach” is proposing that we don’t estimate. How then do we capacitate the Sprint if we do not size and compare to our available time? Well, and I’ve heard this from the author first hand, the answer is “chunk the work into objects of the same size”. Puzzled still? You probably should be.

Estimating is not a fun job and we like fun and dislike non-fun work. But we learn from it, it helps us emerge efficient code, our clients get the info they need at decision time, it helps us govern teams of appropriate size and reduce the risks of late delivery. There are tens of patterns to make the process more efficient and get the most out of it.

If a company culture is that of a “non-blame” — and it should be - estimates do not end up hurting a single person, but they make the team think twice about the best steps to get to the target.

Nobacklog, Nonsense, …

Lately, the same author has been busy marketing the new approach “nobacklog”. I am not going to go deep into the reasons why we have a backlog (and there are probably hundreds), but I would advise people to think twice before choosing an approach that begins with a negations. It is most likely a marketing stunt with no affirmative message to translate, used as a “click bait” for a new book or consulting gig. When you need a strong title, you most often do not have a strong message.