Agile & Lean Product Development

A Practical Approach to Agility and Product Management

Tag: estimation

Reducing Variability and the Airport Omelette

March 5, 2018 / / 0 Comments

Like many times before, I was sitting in my favorite airport restaurant before my first flight and enjoyed my typical egg white omelette. Then I questioned myself: why don’t I eat breakfast at home instead and leave later for the airport? That didn’t feel right (apart from the fact that my home cooked omelettes don’t taste as good), until I realized there was a deeper reason for it: Eating at home meant leaving later, which would increase the likelihood of hitting traffic on the road and longer lines in the airport. Leaving later would also reduce the safety buffer I can rely on if something unforeseen happens. If worst came to worst, I could skip my airport breakfast and chow down a bar instead and still make my flight. If I ate at ours have that safety buffer.

Taking a step back, making a flight as well as completing work projects on time is about increasing predictability. One way to do that is to reduce schedule and other risks by eliminating variability early on in the process. So if a project consists of multiple sequential steps, it makes sense to eliminate variables as early as possible and take on those tasks that have the highest possible variability first (assuming the tasks can be resequenced accordingly).

This is very much in line with Agile’s recommendation to take on those stories and features with the highest level of technical risk first. It’s all about reducing risk and increasing predictability.

Wait, you might say, doesn’t SAFe propose to preserve options and defer decisions till the last responsible moment? Yes. If these options bear the same amount of risk and variability, doing so may not necessarily increase project duration and risk, but it certainly doesn’t remove variability early on. The goal here is to stay responsive to changes in market and business demands and not place technical bets until necessary.

In practice, one will need to find the right sweet spot between reducing variability and preserving options as those two approaching are some what opposites sides of the same continuum. SAFe practitioners are, at the end of the day, also incentivized to be predictable and meet PI commitments, if possible.

Now that I understand why my usual airport omelette actually helps me make my early flight, I will certainly keep my eyes open for other opportunities in my life to reduce variability and increase predictability where it matters.

Predictability in Agile Delivery

March 4, 2016 / / 0 Comments

It comes at no surprise that predictability of Agile delivery is a big deal. I would define it as the team’s ability to predict with reasonable accuracy which backlog items they will be able to complete either by the end of a sprint or within a certain timeframe (in case of Kanban teams). And predictability scales up: multiple predictable teams may make a shared program they’re a part of predictable and multiple predictable programs combine to a predictable portfolio. Organizational leaders look for predictable delivery in order to be able to make business commitments.

 

Nonetheless, I’ve always been quick to point out that predictability may not always be what one wants to optimize for. A key factor affecting the importance of predictability is where a product is in its life cycle. A very young product at the beginning of its life  will not require predictability. For such a product, especially if the organization follows approaches promoted by the Lean Startup, focus will be on defining an MVP and releasing it to the market as soon as possible, after which point the team will attempt to validate learnings as quickly as possible and pivot where necessary. Under these circumstances, iterating on the product quickly will be imperative. Therefore, I concluded, predictability is not important under these circumstances but something only more mature products (or larger, traditional organizations) require, right?

Recently, I realized that this it is the wrong question to ask whether a product requires its team(s) to be for what timeframe a development team needs to be predictable. If I’m iterating on my startup’s MVP, I need to be predictable, but maybe my planning horizon is only a week or two. If I’m maintaining a mature product, I may require high predictability in order to forecast 3 to 12 months out. Another factor necessitating high predictability is a market requiring long-term commitments from the companies serving it. Since the need for predictability is a function of the product needs, it’s quite possible that a well diversified company may have multiple products where the answers are different.

 

One caveat is that for the same product, one usually has to decide and pick one or the other: do I want to be highly predictable or highly responsive and able to turn on a dime? In most cases I can’t have my cake and eat it too.

 

My takeaway from this is: predictable delivery is always required, but it’s important to determine for what time horizon teams need to be able to make commitments and why.

The Art and Waste of Estimation and Structure

January 28, 2015 / / 3 Comments

There has been a fair amount of noise and chatter around “estimation” in the Agile community lately and some of this debate is turning heated and sometimes almost religious. I certainly don’t want to get dragged into that, but at the same time this discussion has helped me see a few things clearer that I wanted to share.

I’m going to widen the term from “estimation” a little bit and call it “structure”. Structure can mean a number of things, all of which are somewhat elective in Agile:

  • Story estimates (in story points, ideal days, t-shirt sizes, etc.)
  • Story decomposition into tasks
  • Task level estimates (most often in hours)
  • Capturing of actual hours at the task level

Sometimes the structure is extended to include things like

  • Iterations themselves
  • Sprint burndown charts
  • Planning conversations and exercises

Some of the voices in this debate quickly judge the above structural elements as waste or in Japanese “muda” (although – as Scott Ambler pointed out – using a Japanese term for something we have a perfectly good term in English for is waste in itself; why waste brain power on translation? But I digress…).

A number of these structural elements are mechanisms to help create team predictability. Predictability in itself has taken a hit in the community and some argue it’s pushing us back to waterfall. I’ll make the argument that despite business model at a minimum an Agile team should have some level of short-term predictability, i.e. the ability to make a commitment / forecast for the next 1-2 weeks and be consistent in meeting it (I’m not talking about defect/break-fix teams here).

At the end of the day, a high-performing, stable Agile team is characterized by being able to produce a significant amount of high-quality output (working, deployable software) in a consistent manner. Despite what Agile maturity model you subscribe to, this always seems to be a big part of it.

I postulate that the less mature a team is, the more structure and with that “data” and visibility into what’s going on it needs.

Having iterations, tasks, task-level estimates, a burndown and the ability to compare estimates and actuals will help a team get better and become more predictable and ultimately high-performing. These structural elements are like training wheels to help the team mature and build some important disciplines.

Once the team approaches high performance, one might consider selectively removing some of these structural elements, assuming the team is mature enough to where those don’t add any value and aren’t required for other reasons. But one shouldn’t have to get rid of any elements, especially if removing them actually negatively affected team performance (which could happen if critical or too many elements are taken away).

On the flip side, doing away with all or most these practices and artefacts right away or never implementing them in the first place (because they’re perceived as wasteful), before a team is high performing, is dangerous and will prevent them from reaching their full potential.

Interestingly, I’ve recently had the chance to see teams that never used to have these structural elements and when they were introduced for the first time, they served as quite an eye opener for them and the additional visibility seems to help them greatly in fine-tuning themselves and reaching higher levels of predictability and performance.

In certain situation data captured by the team may not always directly benefit the team, but serve a purpose outside the team in other parts of the organization. The team may not care about story points, but maybe the Product organization finds them beneficial in understanding relative size of and progress against various epics that – without story points – wouldn’t have a tangible size. Capitalization rules may requires actual effort spent on a project to be captured. In those cases the team should probably not remove those structural elements.

In summary, instead of calling structure wasteful right off the bat and quickly judging it as bad, I think a more deliberate approach might be in order. Maybe the conversation should shift away from “if” and focus more on “when”. It’s not all good or bad; it’s about what things make sense and adds value under what circumstances, during which part of a team’s maturity curve. New and immature teams will require more guidance, data and visibility. Mature, high performing teams will require much less structure.

© 2024 Agile & Lean Product Development

Theme by Anders Noren — Up ↑