I have long been a skeptic of AgileTM. There is no doubt that team-based, flexible, and product/value-focused software development is the best way we’ve discovered so far to build great, useful software. That, I believe, is fairly established even in the most corporate of environments. What I remain skeptical of is “methodologies” and processes which claim to “govern” and “better manage” the agile software development team and process. In my career I’ve found most of these techniques to serve MBAs' and project managers' need to track and quantify rather than to serve the team or improve the craft or quality of software. On the contrary, many AgileTM methodologies I’ve experienced over the years have slowed the development process, hurt developer moral, and led to software that was behind schedule and didn’t provide the full value needed.
From the first time I experienced AgileTM, I struggled with the concept of estimation. In the early days of corporate AgileTM we estimated in hours. This, I thought, was silly. How exactly was I supposed to know how long something would take me? My small team worked on greenfield development and each and every story was literally the first time I had been asked to solve that particular problem. Like all good developers, we started estimating 5 to 8 hours for each story, hid tasks that exceeded the original estimates under stories that took less time, and overall used Jira as a tool to show project management what they wanted to see. Estimating stories by hours, I determined, was a huge waste of time and provided me and the project no value.
Fast forward a few years and I suddenly found myself at another corporation undergoing an AgileTM transformation under the guidance of an AgileTM consultant. The consultant told us hour estimates weren’t AgileTM. Instead we should be using story points and playing estimation poker. The focus should be on complexity, not hours. This would help us determine velocity, etc., etc., etc. nice chart for the project managers, etc. Again, hours were wasted coming to consensus on arbitrary points, that project managers immediately associated with time, that were still wrong. As developers we continued our Jira game so that everyone could see their cool charts. Estimation by points, I determined, was also a non-value-add.
I say all of this to help explain the excitement I felt when the director over my department at LifeWay asked me to read a book entitled No Estimates by Vasco Duarte. No Estimates is a quick read that gives the author’s interpretation of the #NoEstimates approach to software project management. In Duarte’s #NoEstimates approach, development teams switch their focus from weak attempts to correctly predict the future –story point estimation – towards a steady application of development craftsmanship whose metrics can build trend lines to give a better picture of what the future might be.
At face value, #NoEstimates might be seen as a naive attempt by developers to skip a meeting or avoid the hard work of estimation. This, however, is not the case. Following the #NoEstimates approach, developers can refocus their efforts on designing software, asking questions, and breaking down work as more knowledge is gained throughout the duration of the project. Developers no-longer have to stress about estimating the size of a story “correctly”, rather they can focus on asking the right questions, designing the right software, and, ultimately, delivering valuable, working software as quickly as possible.
For developers the core of #NoEstimates is taking a more disciplined and value-focused approach to breaking down development work into smaller units. Like any agile methodology #NoEstimates teams focus on generating backlog items that can quickly deliver value. A critical point of discipline in #NoEstimates, however, is that stories should follow the principle of INVEST; they should be independent, negotiable, valuable, essential, small, and testable. Ensuring that stories are correctly encapsulated is important to empower project management to do their job without impacting the team. The goal for the development team during backlog refinement is to break work down into INVEST stories that can be completed in about a day. Nothing more, nothing less. No silly estimating games. No pointing arguments. Just breaking work down into independent, day-ish chunks.
#NoEstimates isn’t just freeing for developers, it also lifts a heavy burden from project managers. Instead of relying on developers to do something well that they don’t exactly care about or – worse – taking the burden of correctly estimating technical work on oneself, project managers instead can focus on product management and leveraging real data to project future trends. #NoEstimates project managers don’t spend their time tracking progress – or, more likely, lack of progress – towards wild guesses from months past. Instead by tracking the number of running and tested INVEST stories – RTS – over time #NoEstimates project managers use real data to forecast the future. Project management is now about supporting the team in a consistent rate of progress rather than death marches to an arbitrary date. Because INVEST stories are all about the same size – about a day – and because the project manager knows how many RTS a team delivers on average, a project manager can easily forecast the time needed to complete any task that has been broken down into appropriately-sized INVEST stories. When tracking towards a date established by management or the customer, we can now show and forecast how close – or far – from the arbitrary date the team will deliver given current scope. As scope changes – things are added and removed – we can clearly show the impact that has towards an actual forecasted delivery date. No more guessing. No more politics. Just forecasts based off historical data and scope management conversations.
My guess is that most within IT have intuitively come to the same conclusions expressed in the #NoEstimates approach to software development project management. For me No Estimates gave form and structure to many ideas and feelings I’ve had over the last several years in IT management. I strongly recommend all in and around IT to read this book. Product owners, project managers, IT stakeholders, business partners, developers, etc. can all benefit from the #NoEstimates approach to software development.
