Archives for Chris

Improving estimate accuracy

targetDon’t we just get frustrated when our estimates or guesstimates on timescales or costs turn out to be different from what actually happens? So how do we improve the accuracy of our estimates?

What do we need estimates for?

This is a golden question – ask yourself this whenever you do an estimate. It’s a lean principle to remove waste (i.e. non-value adding activity). If the estimate information you are producing isn’t vital for making a decision, then take a good hard look as to whether you need it. Some of the teams I have worked with have stopped some kinds of estimates as these estimates were not changing the decision.

Why are estimates uncertain?

Estimates are uncertain because we lack information. We’ve never built this particular feature before. We don’t exactly know what we need to do. As we work further with the feature, we gain more information and our uncertainty about how much work is required reduces. This leads to the idea of the cone of uncertainty shown below which suggests that uncertainty decreases (and hence accuracy of estimate increases) throughout the life of a feature.



What helps improve estimating accuracy?

1. Break work down

If you only do one thing, break the work down into smaller pieces (this is a core lean principle!) It’s much easier to estimate smaller activities than larger ones. By simply breaking down large work items into smaller pieces, your estimating accuracy will improve.

2. Increase the rate at which the estimator gains experience

Ability to estimate comes from learning from past experience of estimating. So get more experience! The way you increase your learning rate is to shorten the cycle time i.e. the time it takes to produce something. Doubling the cycle time doubles the rate of learning! Of course, the experience gained needs to be effectively captured (retrospectives, low staff turnover, etc.).

3. Ensure estimators are the people who are doing the work

Seems simple but in a lot of cases, the people doing the estimating are far from the actual work (or, sometimes, estimates are adjusted by people far from the work!)

4. Reduce dependencies

Typically if a task requires 90% of one person and 10% of another, the 10% person will be the bottleneck because his focus is not on the task. This means that it’s difficult for him/her to be available precisely when needed. Eliminating this dependency will reduce variation in timelines. Feature teams help with this.

5. Get multiple inputs

Agile teams often use planning poker to harness the brainpower of the entire team to improve the estimate – it’s unlikely that one person has all the best information. This is a fun and easy thing to try.

6. Agree on which estimate we want

Many timeline estimates are simply the earliest possible time for which the probability of delivery is not zero. Did you want the most likely date (50% chance of being early, 50% chance of being late) or the date for which it is almost certain delivery will have happened by? Make sure everybody agrees which estimate we are talking about.


7. Understand the politics

There are also all sorts of human dynamics that can skew your estimate. For example:

  • If there are “punishments” for getting it wrong, folk tend to add buffers to their estimates.
  • If folk believe that the uncertainty associated with the estimate will not be communicated clearly (for example to senior management) then they tend to add buffers. A solution to this that a lot of agile teams use when they are doing an early guesstimate is to use “T-shirt” sizing whereby the estimate is classified as Small, Medium, Large or Extra Large. Communicating guesstimates like this makes it clear that they are not very accurate.
  • If there is already a target declared (“we want this to be under $100k” or, “we want to complete this by June”) then folk tend to be anchored by that and don’t like to say it’s not possible. We all like to please our stakeholders.
  • Many fascinating studies show that people have a natural subconscious tendency to be overconfident in their estimating skills. If the estimator(s) have little data on past performance to help correct this, then its likely they will underestimate tasks.


Setting expectations on estimate accuracy

It’s tempting to set a team a goal to improve estimate accuracy. The risk with this (which I have seen in some teams) is that the quickest and simplest way of improving estimating accuracy is either to add undeclared buffers or to invest more time and resource before making the estimate. The latter effectively moves estimate creation to later in the lifecycle which destroys the purpose of the estimate (which is to make decisions early on in the lifecycle).

A better way of improving estimating accuracy is to set the team goals on reducing cycle time and reducing the size of items flowing thro’ the pipeline (as per the first two points above). By focusing on these general lean-agile practices, we also get an improvement in estimating accuracy!

How to deal with “I want it earlier”

deadlineDo you recognise this dialog?


Senior Executive (SE): “In this plan you’re showing me, you say it will be ready by December?”

Project Manager (PM): “Well that’s the best estimate we have now based on what we know.”

SE: “I want it by end of June”

PM: “Er, OK. Er but the team don’t believe it can be done.”

SE: “Take your black hat off. It’s your job to make it happen.”

PM: “Er…”


I was thinking about how to apply a lean-agile mindset to this imaginary situation. How about something like this:


Senior Executive (SE): “In this plan you’re showing me, you say it will be ready by December?”

Project Manager (PM): “Well that’s the best estimate we have now based on what we know.”

SE: “I want it by end of June”

PM: “Why do you want it by end of June?”

SE: “I consider it important that we get this done quickly and I’m sure you are capable of doing it. It’s top priority!”

PM: “Why is it important to be done quickly?”

SE: “Well, this project affects bottom line. It significantly improves our revenues and decreases our cost.”

PM: “So there is nothing which happens at midnight on 30th June which means that if we deliver a minute later then this really matters. It is more like you’d like this to happen earlier than later?”

SE: “Yes, that’s right.”

PM: “I understand that it’s top priority. It will help if we can characterising what top priority means since there are always other projects who are claiming to be top priority. The business case says that this change will have a benefit of $52m per year which is the same as $1m per week. Does that mean that for every week we are able to get this project done early, the company would realise an extra $1m?”

SE: “Yes, that’s true in this case.”

PM: “Does that mean we’d be willing to spend up to $1m to get the project a week earlier?”

SE: “I never thought of it like that but, yes.”

PM: “Great. Now we can make our case about being top priority. Every time we have to wait in a queue for some bottlenecked resource that is on our critical path, we take the amount we have to wait (in weeks) and multiply by $1m and this is the opportunity cost to the organisation of us not going first!”

SE: “I like the sound of that!”

PM: “Of course, the other projects will calculate the opportunity cost they incur if we go first. We will compare opportunity costs and the biggest will win.”

SE: “Em. I suppost that makes sense. Although I don’t like the idea of waiting.”

PM: “That I can understand. We are trying to to what’s right for the company overall. This calculation (called CD3 = cost-of-delay divided by duration or weighted shortest job first) ensures this.”

SE: “Yes. You’re right.”

PM: “Going back to the $1m per week. If we agree on this figure, and the team identify something they can do to bring the delivery forward by a week that costs less than $1m, do we have the authority to spend the money to make this happen?”

SE: “I’m not sure. They can always escalate to me if necessary.”

PM: “So you agree to make yourself available quickly if we have something we need to escalate.”

SE: “Well I am very busy and important.”

PM: “Yes. If you are unable to make the time and unwilling to delegate then the cost to the company will be $1m per week.”

SE: “Yes. You are right. I will be available.”

PM: “With regards to the delivery dates. Our estimated date was arrived at by harnessing the brainpower of the whole team – the people who are closest to the work. This is the best estimate we can get with the information we have today – there is no better way.

At $1m per week, I understand the urgency of realising value as soon as possible, so we will set up our delivery pipeline in order to break work down into small chunks of value and then realise that value, starting with the most valuable chunks. Using this approach, you will see that the team is delivering value before end of June and you will also have ongoing opportunities to change the priorities as we go and we learn more.

This also allows us to check assumptions about the value of the solution and how to build it.”

SE: “I don’t understand. Can’t you just double the team size and deliver earlier?”

PM: “Both IT industry experience and our own previous project experience suggest that this doesn’t help. Larger teams tend to deliver less.”

SE: “That doesn’t sounds right?”

PM: “In any process, it only makes sense to add resource at the process bottleneck. Adding resource anywhere else will slow the team down. IT development is a complex human intensive process. If there are 10 people on the team and we add one more, then there is an overhead on the original 10 in bringing the 11th up to speed, maintaining communication and alignment etc. This is particularly true when the team processes are new. Until there is a running process that is demonstrably creating value then it doesn’t make sense to scale the process and add lots more people.”

SE: “Can’t we just start a lot of work in parallel and have a lot of different teams?”

PM: “Yes this would be possible if the nature of the work was such that there were no dependencies between the teams but the dependencies we have will create bottlenecks. In any case, the most scarce resource in any organisation is usually management attention. Its better to do a smaller number of activities and work on doing them fast than a large number at once and do them all slow.”

SE: “You said that you want a running process that is demonstrably delivering value. When will that be?”

PM: “We aim to begin realising business value within 30 to 90 days.”

SE: “We’ll that is sooner than I expected and I guess I’ll see whether the approach you propose is working by then. I’m looking forward to that.”

Maybe I’m a dreamer but if only all these conversations went like this…

Always busy?

Which is most important? To ensure our teams are fully busy or to maximise the value delivered by the development pipeline? I’m hoping to have you consider that there may be times in when it is in the company’s interest to pay people to “look out of the window” for periods of time.

Throughput decreases as capacity utilisation approaches 100%

Think about a highway – cars flow fine when there is little traffic. When the volume of traffic goes above 80%, we start to get traffic jams. As the loading on the highway approaches 100% then we end up almost no flow at all. The overall value delivered (i.e. people getting to where they want to go) is less. Models have been developed which give the underlying maths of why this is. Highway designers have actually taken these model’s to heart and there are now places were cars are held by traffic lights on the sliproad at peak times in order to maintain a smooth flow on the main highway. The funny thing is this improves everybody’s end-2-end journey time including the cars which were held on the sliproad for a period. Its counter-intuitive, as it probably doesn’t feel like that when you are sitting on the sliproad not going anywhere.

A development pipeline has similar characteristics to a highway. The inherent variation in both demand and supply means that throughput is maximised when the pipeline is run on average below full capacity.

An example

One of the teams I coach is effectively doing a whole release which is dominated by a technical upgrade. To simplify the situation, what that means is that it requires the developers and testers but not the analysts. What should the analysts do whilst the developers/testers are busy with this release?

Options are:

  • Worst option: Do more analysis. Since the bottleneck is not analysis work, all this will do is pile up a lot of work for the developers/testers to work on. This pile will probably never disappear because as soon as the developers remove something from it, the analysts will continue adding a new item. We haven’t increased the value generated by the pipeline but we’ve increased the cycle time and hence decreased agility and speed of feedback/learning. Think of all the management and communication that with be required to look after this pile of half finished work? The overall value generated is almost certainly negative.
  • Better option: Analysts look out the window for a while. This has no negative effects on the value delivered. Of course, if this is a permanent thing (which in this case it isn’t) we should look into reducing the number of analysts.
  • Best option: Analysts learn over time how to help with development and test. They may not be the most efficient at these tasks. T-shaped individuals can move to the bottleneck and increase it’s capacity. This would enable the technical release to be ready earlier and hence increases the value delivered by the pipeline.

It’s counter-intuitive for us to accept that there are situations where the most value people can generate in the short-term is to do nothing. We all like to be busy. It’s not about the productivity of the individual but the productivity of the pipeline as a whole.  What do you think?


A pipeline near you?


Are you T-shaped?

t-shapedA common problem in increasing the flow of work through a development pipeline is over-specialisation. The bottleneck might be in getting the analysis done, yet we have plenty of developers who have nothing to do since they have no analysis skills. Then the bottleneck moves to the front-end development yet we discover we have plenty of back-end developers but none who know how to code the front-end. And so on. Enter the T-shaped individual which is a common lean-agile practice applied to address this issue and increase throughput through the development pipeline.

What is a T-Shaped Individual?

A T-shaped individual is not the same as a generalist. He or she has deep expertise in one area but is able and willing to turn his/her hand to other things.

How can I promote this approach?

Teams I have worked with that have been committed to this practice have found the following helpful:

  1. Hire people who want to develop outside their specialism An expert in, say, workflow, is not going to get an opportunity to learn just about workflow. In developing T-shaped individuals, the learning opportunities might be in rules or service bus, business analysis, performance testing etc. New hires have to want this.
  2. Organise around the flow of value If the team are not organised around the flow of value but instead around developing components which are only part of the whole, then there will be little opportunity to develop skills outside one’s own specialism.
  3. Actively manage the skill map One way of doing this is to identify all the different skill areas required to produce value. Then the entire team score themselves against this in one of 4 ways. This skill map is then used helping the team decide who does what and for managing skill development. This also enables team members to learn and develop in the areas that interest them and helps with minimising dependencies on key individuals.


I can teach others
I can do the job with help from others
I can do the job alone
I am eager to learn


Fig. 1. A simple rating of skill level


Would T-shaped individuals help improve the throughput of your delivery pipeline? Are you willing to make any necessary changes to your hiring practice and organisation?

Read more about T-shaped individuals…

Retrospectives: Looking back to move forward

Retrospectives are a practice used by a lot of software teams – particularly popular with those using SCRUM, since the “sprint retrospective” is part of the SCRUM methodology. They are a effective and simple framework for continuous improvement (Kaizen) for any team – not just those delivering software.

How retrospectives work

The team meets to look at what they have been doing and what they can do differently going forward. Mindset is important – in order for team learning to be effective, there is no room for finger-pointing. The retrospective prime directive captures this:

“Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”

Frequency of retrospectives

Many teams organise a “lessons learnt” session after the project is done (or after a major release). This is too late! It’s too late to change anything, some events have been forgotten and energy levels are low. Retrospectives need to be scheduled at least monthly.

How retrospectives work in our coaching team?

We “eat our own dog food” so we have always had monthly retrospectives in the coaches team. For reasons that are lost in the mists of time (creating a relaxed environment maybe?) we always hold our retrospectives in a bar. The facilitator of the session is not our team leader (me) but is the same as the person who is facilitating our team kanban board (a role which rotates so that all team members get to do it sooner or later).



As a warm up, we create a timeline of the key events which have happened since the last retrospective – handy to bring what’s been going on to the front of our minds:


We then answer the 4 key questions – there are other possible sets of questions out there which we have experimented with (e.g. the retrospective starfish) but these four seem to work best for us:

  • What did we do well, that if we don’t discuss we might forget?
  • What did we learn?
  • What should we do differently next time?
  • What still puzzles us?

We are very low tech – we have one sheet of A3, divided into four areas, which we all write on at the same time.



When we are all finished writing, we go fairly slowly through everything everybody has written and agree any actions which we transfer to our team kanban board. The whole thing normally takes us about 2 hours – we’ve tried to do it in less but it just hasn’t worked out for us.

So, lets cut to the chase. What have we got of value out this? I’d say two things. Firstly the concrete actions we take as a result of the retrospective have improved the way we work. This has been in many, many small ways. Also, by including the whole team, we have perhaps identified earlier than we otherwise things that are about to become large problems but right now are just small irritations.  Secondly, it has helped instil a mindset in which the whole team is responsible for improving the way we work and given us a sense of common ownership for our team process. It is taking us closer to that ever elusive goal: the self-managed team.


So does your team have a structure for regularly taking time together to look backwards to work out how best to go forwards? Do you like the idea of continuously improving the way the team is working but you don’t know how to approach this? Why not try running retrospectives with your team?

More about retrospectives at and Seapine.

How do we prioritise technical debt?

Technical debt is one of the great “inventions” in software engineering of the 1990s. The idea, if you are not familiar with it, is that every time you cut a corner in the interest of delivering value now i.e. delivering on the immediate needs of the project, you record it as a debt. The reason it is a debt, is that if you don’t pay it back then it will impede your ability to deliver value in the future. Examples of technical debt include:

  • Lack of adequate documentation
  • Code that is unused; untested; uncommented; hard to understand
  • Non-compliance with Non Functional Requirements or Principles, Standards & Guidelines

Incurring technical debt can be the right thing to do, providing its incurred in a prudent and deliberate manner.

A fascinating reason for taking debt repayments seriously is the broken window theory. The theory has it’s roots in experiments made in the 80’s. Experiments showed that disorder and crime are linked – if a windows in a building is broken and left unrepaired, all the rest will soon be broken. People seemingly get the message that nobody cares. The insanely complex nature of software systems means that similar behaviour is observed – nothing accelerates the speed of the descent into un-maintainability than allowing technical debt to build up.

Process-wise, what is required is:

  • A process for recording technical debt and making it visible to stakeholders
  • A process for deciding when to paying it back

The first bit is easy. The second is tricky. The solution for the second bit that some teams I have worked with hasve settled on allocating 50% of the development effort to paying down technical debt. Why 50%? Why not 40% or 60%. I’m guessing that 50% was the maximum the team felt they could ask for without having an unacceptable impact on the delivery of value now.

A better approach would be to use an economics-based prioritisation algorithm (like cost-of-delay divided by duration). Its not easy, since we would need to estimate the benefits/savings from paying down each element of the debt, but it’s worth it. An effective technical debt process avoids creating solutions that, just a few years after they were first created, we can no longer effectively change because the cost and risk is too high.

For the curious, see for more about technical debt.

The usefulness of cost-of-delay: a real-life story

Here’s a interesting real-life story of a requirement from one of the delivery teams that I have worked with which emphasises how a focus on cost-of-delay helps.

The story concerns requirement RQ-0672 which took 46 weeks to go from being captured as a idea to being live in production.  We have a fair idea of which weeks there were activities happening (green) and which weeks nothing happened (red); shown in the value stream map below (See here to learn more about value stream mapping techniques):



Observation 1: It’s pretty clear there was a lot of “waiting waste”. Most weeks, nothing happened!

We introduced the concept of cost-of-delay to this team – i.e. measuring the opportunity cost to the company for every week this requirement was not implemented. This turned out to be $214,000 per week. Cost-of-delay figures often have high levels of uncertainty (particularly if the benefits of the requirements are around increasing revenue as in this case) but in this case, this number is fairly certain.

This particular delivery stream is capable of delivering a requirement like this within 13 weeks. Had this been delivered within 13 weeks instead of 46 i.e. 33 weeks earlier, this would have improved the company’s revenue by:

$214,000 x 33 = $7,062,000

Wow. Big number, particularly in the content the actual cost of making the change was around $4,200.

Obseveration 2: There can be significant value in reducing cycle time.

So why didn’t we make it happen earlier? The pipeline was setup without a focus on cost-of-delay which means there is no sense of the urgency associated with each requirement – they are all treated the same. Once we know the urgency, then we know what trade-offs to make.

In this case, you could say that it makes sense for the company overall to spend up to $214,000 for every week we could bring forward the go-live date for this requirement. You can also see from the value stream mapping that there was a proof-of-concept done for this requirement. This proof-of-concept took a week to execute – plus some mobilisation time – probably several weeks – hard to know exactly. Lets say 2 weeks mobilisation for the sake of argument. The cost of delaying the go-live by 3 weeks to do the proof-of-concept was:

3 x $214,000 = $642,000

The purpose of this proof-of-concept was to be able to accurately estimate the cost of the change. Remember, this change actually came in at a cost of $4,200. Given the enormous benefits, it would still have made sense for the company to implement this change if the cost had come in at $4,200,000. Perhaps we should have skipped the proof-of-concept stage for this requirement!

Observation 3: Not all estimating activity is truly value-adding

I have selected an extreme example of course. Even so, its real. It happened. It serves to emphasis that some requirements have high cost-of-delay which needs to be managed. A good innovation process design should  expedite these types of requirements by:

  • Prioritising quickly based on cost-of-delay (ideally within a week)
  • A frequent “pull” of the top requirement from the top of the dynamic prioritised list of requirement
  • Fast cycle time from the time of “pull” to go-live through a pipeline which is not clogged up with too many other requirements

Lean-agile risk management. Is there such a thing?

An interesting area of discussion is to whether a lean-agile approach contributes anything to effective risk management. Do lean-agile practices effectively mitigate risk? Some say yes and some say no.


There are, I believe, currently no lean-agile practices which are designed to identify the most important risks and then focus on mitigating and tracking them. Other (traditional) project management approaches have tools and practices for this – for example by the creation and ongoing review of a risk log. Yet this is missing in the lean-agile toolkit. Lean-agile practices need supplementing by a traditional risk management practice.


The traditional risk log approach is of limited effectiveness. If you ask a team what the top three risks the team faces are (go on, try it), it’s rare that the team comes with a consistent answer. Even when a risk log helps identify risks, analysing the true root cause of a risk in any particular case can be difficult.

By implementing lean-agile practices, teams get access to ways of mitigating the highest risks that an IT development project faces as evaluated by broad industry experience.

Take the Agile Manifesto. It was created by a group of experienced people. Apparently, it was tough to find things they agreed on (even though they were experienced, the number of projects they have worked on is still small so the number of data points they have is also small). They did manage to agree on the agile principles behind the manifesto. Each principle addresses one or more key underlying risk facing an IT development project. I’ve had a go at identifying the implied risk below. Would you think of these when you start a IT development project? Would you agree that these are the key risks?

Principle Implied risk
Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.
Solution deliver generates no or little value. Unused features.
Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.
Solution could not be built as intended. Solution delivers no value. Things external to the project change.
Business people and developers must work
together daily throughout the project.
Business people and developers do not communicate quickly & effectively.
Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done
Environments and support not available.
Teams not empowered.
The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.
Geographical distribution of teams and over-reliance on electronic communication leads to ineffective communication.
Working software is the primary measure of progress. Focus on internal goals instead of meaningful ones (delivery of working software)
Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.
Unsustainable development (pace, architecture, …)
Continuous attention to technical excellence
and good design enhances agility.
Lack of focus on technical excellence.
Simplicity–the art of maximizing the amount
of work not done–is essential.
Complex code. Doing work that doesn’t need to be done.
The best architectures, requirements, and designs
emerge from self-organizing teams.
Ineffective teams due to poor team structure/task management and the team not being empowered to change this.

What do you think?

8 tips on managing requirements

requirements-boxI have been looking recently at managing requirements for new projects. I thought it would be interesting to share our top lean-agile tips/encouragements for for managers of requirements (i.e. the product owner role in agile terminology):

Tip #1: Do only enough requirements work up front to enable you to build the first (small) feature. Then learn and adjust!

How much do we need to work out up front and how much can evolve as we build the solution? Defining all the requirements work up front (Big Requirements Up Front) seems attractive. It means that there can be a contractual style relationship between business folk and solution builders. Commitments can be made and, if an external vendor is involved, fixed price deals can be made. If dates, budgets etc. are not met then punishment can be handed out etc.

Yet this is not the way the IT industry is going. The biggest risk in IT development is that the solution delivers little or no value (unused features). The whole agile movement has this in focus. The IT industry has learnt that Big Requirements Up Front actually increase this risk because the delay the point when we are going to get feedback on our requirements. There are always large uncertainties in what the customer needs and how to build it. Its never been done before! A lean-agile approach emphasises learning – build a bit and get a response so we don’t have to get it right first time.

Wait, I hear you say. Doesn’t this mean that you might not take all business requirements into account from the start and have to refactor/reimplement certain features later? Yep, it probably does mean this. IT industry experience suggests that these refactoring costs are typically much smaller than the costs required to get it right first time. (See here for more details).

Tip #2: See requirements as a placeholder for a conversation, not the conversation itself.

Consider requirements as a placeholder for a conversation between the people who have a business need and the developer writing the code. They are not the conversation itself.

To align everybody around the direction we want to head in, a short up-to-date document describing the project vision (better a short document which everybody has read than a longer one that hasn’t been read at all). Beyond this, user stories are usually the best format to capture requirements since they capture the intention of the requirement (“in order to”) and who wants this requirement (“as a”). Otherwise, these things are often lost. e.g.

AS A: Flickr member
I WANT TO: be able to assign different privacy levels to my photos
IN ORDER TO: control who I share which photos with

Tip #3: Break requirements down

User stories can be arranged into hierarchies with top level stories which are broken down into smaller stories. Keep breaking the work down until you get to a feature that can’t be broken any further and still retain some business value (a minimal marketable feature in the jargon).

Tip #4: Define acceptance criteria up front

How will we know when a requirement has been delivered? Ensure user stories have acceptance criteria so we know when we are done.

AS A: Flickr member
I WANT TO: be able to assign different privacy levels to my photos
IN ORDER TO: control who I share which photos with

A user cannot submit a form without completing all the mandatory fields
– Information from the form is stored in the registrations database
– Protection against spam is working
– Payment can be made via credit card
– An acknowledgment email is sent to the user after submitting the form.

Tip #5: Collaborate like crazy, preferably face-2-face

Two of the the principles behind the agile manifesto are: “the most efficient and effective method of conveying information to and within a development team is face-to-face conversation.” and “Business people and developers must work together daily throughout the project” Geographic constraints may hinder this but try and get as close to this ideal as you can. Be available throughout development/testing/ etc. for questions (e.g. attend the daily stand-up). If you don’t do this, the fast feedback model won’t work.

Tip #6: Use CD3 for prioritising and be prepared to stop early

Use the economic model cost-of-delay divided by duration as the basis for prioritising requirements. This also means that we have the option to stop early when we have delivered the most valuable requirements.

Tip #7: Smooth the end2end requirements flow

Requirements need to flow into a development team. There is no point developing requirements too early (requirements go stale very quickly). Equally, there is no point having a development team standing idle. Ensure the people who are actually going to build the solution (i.e. coders, not managers) participate the the refining of the user stories. It these people are not available now, wait until they are. It’s counterproductive to create a large queue of requirements that are waiting to be implemented.


Tip #8: Explain to business stakeholders how they need to behave

It’s helpful to explain to business stakeholders what kind of behaviour from them would support a successful outcome:

  • Charter the team to deliver the best possible value in a fixed time scale. Be cautious about asking for a fixed scope by a fixed date. The team will probably have to do Big-Requirements-Up-Front (BRUF) in order to have enough information to commit which significantly raises the risk of failure. It may also mean that invisible factors, like quality, are compromised.
  • Provide $ cost-of-delay/week and trust the team to make the right trade offs. Saying that “this is top priority” or “the board wants this” etc., gives the team no guidance about how to trade off against other high priority items.
  • Trust the team.
  • Make sure business people are available to quickly give feedback.
  • Insist on getting to see something of business value working in production quickly (30-90 days from project start) .
  • Insist on a weekly demonstration of progress.
  • Insist on regularly attending the team stand-up.
  • Insist that the team commit to dates on near-term work items (typically for the next 2-4 weeks).
  • Insist on an up-to-date roadmap covering a longer period. Don’t expect a lot of detail on this.
  • Stop/abandon the project early if you feel you’ve got enough value.

Culture eats strategy for breakfast

culture-eats-strat (1)Feeling a bit bolshie today so I first thought to write exhorting folk to deliver even more value in even smaller chunks in even faster cycle times. Well you should. Once you understand the magic of focusing on overall value (and not cost or some other sub-optimising dimension), the incredible benefits from reducing batch sizes and the almost silver bullet like properties of fast cycle times, it’s obvious.

These are the processes and tools of lean-agile thinking. What it’s really all about is mindset, attitude, culture. The agile manifesto captures this where it says that there is more value in “people and interactions over processes and tools.”

I’ve been getting it at a deeper and deeper level as time goes on. Linda Rising talks of two mindsets “fixed” vs. “agile”:


Fixed mindset Agile mindset
Ability – static, like height Ability – can grow, like muscle
Goal – look good Goal – to learn
Challenge – avoid Challenge – embrace
Failure – defines your identity Failure – provides information
Effort – for those with no talent Effort – path to mastery
Reaction to challenge – helplessness Reaction to challenge – resilience

We all spend time in both places. I offer it for your consideration that you have more fun, are happier and have a greater impact on the world if you spend more time in the agile mindset. If you suddenly wake up to find yourself in the fixed mindset, then there is nothing wrong. Pick yourself up and move over to the agile mindset. The trick is to practice this movement – aim for mastery.

In the agile mindset, we are all a work in progress. The development process isn’t fixed but will continue to improve as it ages. We all try to emphasize continuous improvement but we are woefully short of getting the hang of this.  We boil down lean-agile thinking to kanban boards, CD3 prioritisation and fast cycle times. Yet we are missing the key point. In the book Toyota Kata, Mike Rother looks into what Toyota’s success is really about. The have a behavioural pattern or culture (“kata” in japanese) they have managed to institutionalise where they:

  1. Identify one action that could be taken towards moving towards a vision
  2. Take it.
  3. See whether it did move things in the right direction.
  4. Rinse and repeat forever and make these learning loops as fast as possible.

They do this for everything from the company strategy down to the tiniest thing. What that enables them to do is to out-learn the competition. They understand that learning happens at every level.

“Yea, yea we know all this. I’m always looking for opportunities to improve.” I offer it for your consideration that you are playing this game small and you can play it at a whole new level. You rarely focus on improving just one thing, preferring long action lists and “projects” instead. You rarely understand what the required direction is (what is the vision for how your team communicates? for example. Do you have one?). You assume that you are not empowered to make the necessary changes. You are not ruthless in adjusting and learning quickly, you prefer to schedule meetings for the week after next instead. What both you and the company needs is to maximise the rate of learning. Your mission, if you choose to accept, is to find out how. Adopting the behavioural pattern above is a good starting point.

So here is a call to action. By reading this blog, you are prioritising taking time to learn. To get results, add some courage and steadiness to apply what you are learning. Wherever you sit in your organisation, put on your agile mindset and offer some leadership in adopting the continuous improvement behavioural pattern described above. Have the ambition to apply this pattern to everything. Find out what it takes to make this happen. Experiment!

Research shows that we are encouraged and influenced by other’s behaviour – your colleagues will be influenced by yours. When you start playing the game at a new level, you’ll probably find you won’t recognise yourself and, ultimately, your organisation won’t recognise itself.