No Estimates! Well, Maybe…

A passionate debate about the value of estimates has erupted in the Agile community. Running under the hashtag #noestimates, advocates of ditching estimates and estimating on Agile teams argue that the estimates serve no discernible purpose other than to add overhead to the work of developing product. Even worse, they argue that estimates are overtly damaging to teams, teamwork, performance, and value delivery. Estimates become a weapon in the hands of management, which demands that teams adhere strictly to their estimates regardless of changing circumstances, new knowledge, etc.

I get it. I really do. However, I am still an advocate of estimates and estimating at the team level. Why, you might ask? (Please do!) Well, here’s the thing. Any tool – and make no mistake, estimates are simply a tool – can be misused, abused, or weaponized, but that doesn’t necessarily mean we simply stop using any and all such tools out of fear of their being abused. If that were the case, we wouldn’t have money, credit cards, the Internet, cars, electricity – you get the idea.

So back to #noestimates. I find that, with proper guidance, teams and organizations make excellent use of estimates as a planning tool. Release Planning, Sprint Planning, daily planning, and even portfolio planning all tend to work much better, be more understandable and transparent, when there are team-based estimates backing them up. It is also very clearly the case – in my experience – that teams gain a great deal from the exercise of estimating using a whole-team, consensus-based estimating technique such as affinity estimating or Planning Poker® (a registered trademark of Mountain Goat Software, LLC). And yes, I even like the traditional modified Fibonacci sequence (1,2,3,5,8,13…).

PitchforkManSo when do I come down on the side of #noestimates? The instant the organization, management, or any other force uses the estimates as a stick to beat the team, I am done with estimates. And yes, I have recommended that teams drop the assignment of numeric estimates or any other sizing in that case. I still want the teams to engage in estimating-like discussions of work items for the learning that takes place, but the estimates can go away.

And yes, I have taken my case to management when estimates have become a stick used to beat the teams. And yes, I have been successful in helping management understand that abuse of estimates is a Very Bad Thing and have facilitated a change in behavior. I have also been invited to leave coaching engagements as a result of insisting on the appropriate use of estimates. I thought that was an appropriate instance of applying a Scrum value: Courage.

What is your experience with Agile estimating techniques and the resulting estimates? I’d love to hear from you!

All for now….

…-.-

A Higher Purpose

When agilists talk about the reasons to adopt an Agile approach, whether Scrum, XP, Kanban, or any of several others, we typically focus on benefits to products, customers, and the bottom line. We also talk a lot about the benefits of working at a sustainable pace, working in self-organizing, collaborative teams, and building a culture of change and improvement. Sometimes we talk about creating a work environment that builds and maintains high morale and, to the extent that such a thing exists in the 21st century, bilateral loyalty between individuals and the organization.

These are all important considerations. Most of them contribute directly or indirectly to improving the working lives of everyone in the organization, which is one of the primary reasons that I am such a strong advocate of Agile. But I think there is a higher purpose  Agile fulfills that we, as agilists need to recognize and promote.

It’s neither trendy nor popular to talk about what used to be widely known as the “social contract”* in a capitalist economy. The idea was that there existed a mutual commitment between corporations and society at large. Society made the commitment to support and encourage corporate success by a) supplying the brain power and labor that corporations used to build products, and b) constructing a regulatory environment (in democratic societies at least) that did not unduly constrain the corporations’ ability to innovate and make a profit. The corporate commitment was to enhance society by providing stable employment at a rate of compensation that would allow the entire economy and society at large to thrive. This is Adam Smith’s “invisible hand.” Henry Ford, for all his other glaring faults, understood this concept instinctively. He recognized that stable employment and good pay for his workers was good for business.

Yes, I know this is a huge simplification of the concept and reality of the social contract, but for me this is its essence.

So what does the social contract have to do with Agile? That’s where the higher purpose comes into play. A long time ago, W. Edwards Deming formulated what came to be called the Deming Chain Reaction. Basically, the Deming Chain Reaction states that as a company increases the quality of its products, costs drop and productivity increases due to reduced rework, market share increases, the company stays in business, and – here’s the key – provides more jobs to produce yet more high-quality product in a never-ending cycle.

The Deming Chain Reaction is a manufacturing model, but it works equally well, with a few tweaks, for Agile software development.

DemingAgileChainReaction

The point is that as organizations apply Agile frameworks, practices, and techniques to improve quality, to implement continuous improvement within the organization, the Deming Chain Reaction comes into play. Companies that adopt Agile conscientiously, comprehensively, from end-to-end of the value stream, do far more than simply stay in business – they thrive. And in thriving, they help the communities in which they operate to thrive as well – or at least that’s the Deming Chain Reaction model. Making a profit is simply not the point. Profitability is necessary, but it’s a means to an end, not the end in itself anymore than agility is an end in itself.

Agile offers the path to success for companies large and small. The higher purpose of that success – and by extension of Agile itself – is for organizations to create employment that is challenging, interesting, dignified, fairly compensated, and widespread, and in so doing to reflect back on their communities and society as a whole the values and principles that produced that success in the first place. To my mind, that is the higher purpose of Agile.

*Note that this is an economic social contract, not the political Social Contract of Locke or Rousseau.

All for now….

…_._