What if I can’t work with #NoEstimates?

Tweet about this on TwitterShare on FacebookShare on LinkedInShare on Google+Email this to someone

svTRANSPORT_wideweb__470x309,0Recently I’ve been helping out a friend with some questions about how he and his team can deliver value more quickly in his organisation, which works with a traditional SDLC.

He describes the process as “pretty much solid waterfall” and finds it hard to see how Agile methodologies would allow them to deliver benefit early. Most of their projects are, as he describes it, like an “iceberg”, with huge amounts of data integration and enrichment invisible below the surface before the internal customer finally sees the “tip” with a report or a dashboard/OLAP cube.

The requirements are fixed, and the customer is not interested in seeing partially finished solutions. They want it ALL, or it is not deemed valuable to them.

My friend envisages delivering multiple sprints with the customer getting decidedly impatient because they still can’t see anything useful. And then eventually in one of the later sprints the customer finally gets their dashboard. This doesn’t really solve their problem.

He is also interested in the #NoEstimates debate as the team seems to spend a lot of time estimating effort and, other than the estimates being used to raise a purchase order, the process doesn’t really make any sense to him. He wants to consider alternatives that can be used to give some scale to a project and enable the customer to raise the purchase order to get the work authorised. He wonders if this might be difficult to implement as the organisation is so cost (money) focused, but he at least wants to be able to float a few ideas.

He says there was a request from upper management for the delivery team to be more “agile” but, given the lack of desire for iterative/incremental delivery from anyone outside the team, this request seems to infer the old classic “we want our team to be agile” meaning “we want our team to deliver more quickly but don’t want to bother ourselves with sprint reviews every 2 weeks to give feedback on what they’re building“.

I explained to my friend that these kinds of cultural issues are not easily or quickly resolved. It sounds cliche but Agile transitions are a journey and require a buy-in across the organisation that things need to change, and a willingness to be open to do this. I told him that he will find himself in a frustrating bind if he tries to take a bottom-up approach to agility. Those that are failing to see the value in an early and iterative approach to the delivery of features are the ones that need to understand the benefits before any lasting improvements to effectiveness can be made.

This feeds into estimation too. If he can’t work iteratively, delivering in small chunks, he can’t really empirically measure progress toward the goal, leaving him with no choice but to be predictive and deterministic. If he can’t measure progress it’s difficult to judge if he’s “on track”, and will find himself continually estimating remaining work in order to update the project’s status.

So what can my friend do in this situation?

One thing he can do is to try and continuously deliver vertical slices regardless of whether the customer is interested or not. Put the system into a production-like demo environment. If the customer doesn’t want to look at it, no worries. It will at least allow the development team to iterate in their thinking over the design of the solution, and to measure their progress against a T-shirt sized backlog of work.

Something along the lines of:

  • Here’s the backlog of work that needs to be done (try to make this goal-based rather than solution-based; solution can be agreed Just-In-Time)
  • If absolutely required to approve the purchase order before the work starts, give an up-front estimate range based on how long other similar projects took and Maynard Keynes’ premise “it’s better to be roughly right than precisely wrong
  • Split “stories” into S, M, L and XL by comparing each to one another (relative sizing) rather than trying to determine how long something will take, i.e. “A seems bigger than B, C even bigger, D is about the same as C“, etc.
  • Build one story from each size bucket (while delivering vertical slices if possible) to start building empirical data about how long stories within each bucket might take; from this a predicted end date can be extrapolated
  • Put every new story that emerges into one of the size buckets by comparing it to a story that has not yet been built
    • The “not yet been built” bit is important so that estimators don’t get influenced by how long a particular story took
    • There will be natural variation around how long things will take, so to reap the benefits of relative sizing and empirical process control it is important not to judge the size of a task based on the result of a statistical outlier
    • I wrote a blog post about this recently
  • The more stories that are delivered the better the data will become – it will take several stories before a settled delivery rate and thinner cone of uncertainty is achieved
  • Be transparent; Update the data and the stakeholders regularly, and warn early if the data is showing a high risk of not delivering within the allocated budget so that the appropriate steps can be taken and there are no surprises late in the game

I’ve written previously about the “barriers to entry” for working with #NoEstimates, and my friend is certainly encountering some of these barriers. However, there are always steps we can take to improve the way we do things, and sometimes these improvements influence others in a positive way.

It’s easy to just accept the perception that “they don’t want to change“, but mindful action in baby steps toward better can make a huge difference.

Tweet about this on TwitterShare on FacebookShare on LinkedInShare on Google+Email this to someone

4 thoughts on “What if I can’t work with #NoEstimates?

  1. Neil, when you say “waterfall,” what does that look like for you.

    In many domains “water fall” is a phrase for “bad management.”

    When you encounter a customer where …”The requirements are fixed, and the customer is not interested in seeing partially finished solutions. They want it ALL, or it is not deemed valuable to them.” the project has failed before it has started — run away. Not method agile or not is going to help if the customer doesn’t understand capabilities have multiple paths to “done,” and requirements that implement those capabilities vary as a function of time.

    There are nearly endless examples of “bad management.” Finding good projects to work on should be a life goal. Forget those places that don’t get it, let natural selection take over.

    1. My favorite passage from the document is page 2 (or 329)

      I believe in this concept, but the implementation described above is risky and invites failure.

      The worlds worst page break, in my opinion. To my understanding Dr Winston W. Royce spent the better part of his career going around and say that the Waterfall model was just an example of a BAD way of doing things.

  2. Hi Neil,

    I was thinking while reading your post how your friend is slicing the project between deliveries, maybe that’s the problem.

    In my early days while adopting agile I quickly figured out that the interest of your client on partially finished product depends on how well you slice and prioritize your releases, you need to deliver value in all of your releases.

    This article written by Jeff Patton gives a good shoot on this issue

    Another problem that your friend may have is that his client is not really interested on the project. I have some experience working for big companies where they choose somebody to be ahead of a software project, but the project is not the top priority of this person. The result is an uninterested client that will do anything to avoid meetings with the project team, and also avoid to have to make decisions.

  3. Hi Neil,
    Hope your friend doesn’t work for one of big accounting company 😉 I was coaching there once and helped them to slice stories vertically in similar environment (dashboard/OLAP cube, Datawarehousing). We discussed the iceberg scenarios i.e. reporting and I suggested to drive everything through what do we need to see and build the backbone iteratively. Team managed to understood the vertically slicing but unfortunately management was “not part of team”. They were the driving force to drive the agile initiatives to a standstill (despite being the sponsor of “we need to be more agile”). So I completly agree, bottom up approach mostly leads towards frustration, anxity, heartburn and sometime heart attacks….

Leave a Reply

Your email address will not be published. Required fields are marked *