3223

Guest post by Raymond Hearrell

Recent traction around the #NoEstimates debate suggests the development community is looking to break free from traditional agile techniques like relative and t-shirt sizing. This lust for more freedom is not unwarranted. Many developers do their best work when constraints like timelines and documentation are removed. So, should you explore the benefits of #NoEstimates? In the complex world of enterprise software development, we say no.

While estimation may feel like a tedious task with no value, quite the opposite was proven true in a real life example at a recent client. The company was undertaking a highly coordinated strategic release impacting every aspect of their business, including new advertising and media channels. The overall program execution was critical to reestablish them in the marketplace. Unfortunately, the ability to successfully evaluate progress, switch direction and move with agility was hindered by a lack of data inherent in the #NoEstimates approach. Imagine spinning around in circles, then having to throw a bullseye without any measures to orient oneself.

Following is a blow by blow of what transpired when the #NoEstimates method was used:

Situation: The overall development effort for this campaign encompassed new products, a website redesign, a new mobile site and application. The development team would not provide estimates due to the short timeline to production: six weeks.

Results:

Sprint 1 Completes: No story acceptance but development leads assured the business that all stories were green. No contingency plans were created based on good faith.

Sprint 2 Completes: Team finished Sprint 2 with no visible progress, but ensured the business they were still on track.

Sprint 3 Completes: Mid-sprint, development team alerted business customers that they were behind, but provided no quantitative metrics to support progress or work remaining. Minimal Viable Product (MVP) was reestablished due to the development team’s inability to deliver, and dependencies were adjusted while the business team planned for a new release date.

Sprint 4 Completes: Unplanned sprint, but required to accomplish a reduced MVP. Team suffered burnout finishing the project and cut the scope to meet the deadline. Project was released behind schedule with reduced scope and delayed ROI.

Without estimation in enterprise software development, we have no data points other than intangible feelings to make critical business decisions. With data, additional resources could have been pulled into the project early, scope reprioritized, and the deadline changed. There were options.

In the end, it was an immense effort from the entire development team over weekends and late nights to provide the promised value to the client. The client was frustrated due to unplanned scaled down scope, a three-week delay, and a burned out and agitated development team. Then consider the client’s business constituents, the scramble to push back all media and social campaigns and the irritation at media launch dates being moved.

Ultimately, the unpredictable technology teams caused these delays, furthering the gap that already existed between business and technology teams. Think about the time wasted, the burnout, the mistrust created, all because there was no data to plan, to regroup, or to strategize. Think about the future projects with no benchmarks. If we were to ask the client, the development team or ourselves if the time saved in not providing estimates was worth it, we’d all say absolutely not.

The #NoEstimates movement is all about development freedom and it’s not without merit. Software developers crave the opportunity to explore a solution without the guided “red tape” of sprint timelines, estimation sessions, and user story updates. There is a place for #NoEstimates, but not in the arena of complex enterprise software development. Challenge yourself to find useful applications of the movement in other areas. For example, perhaps you can fund a small team to explore new prototypes, granting development freedom without putting the strategic roadmap at risk.

In environments where business demand drives development and deadlines are a fact of life, planning, capacity, and traceability are valued at a premium. In these cases, estimates are still necessary to achieve success. Would you train for a race in which you didn’t know the mileage? If not, then why would you develop software without knowing what it takes to achieve your end goal?

Image shared by zolakoma

3223