Are you in denial about value?

I’d like to talk to you about something, lean closer dear reader as I’m going to have to whisper this. The intricate ways you are accounting for value on your Agile projects is probably wrong.

Maybe you don’t believe me, maybe you’ve always had doubts, but a lot of the time I see teams who can confidently proclaim they are delivering value in their iterations. They can show me burndown charts, burnup charts, velocity and a whole raft of metrics. But the real question is: who did they deliver the value to?

This is in fact the key question when considering value. If you are delivering user stories just to say you’ve delivered them and to notch off another mark on the burn down chart, you are very much in denial. There is no value here because more often than not you’re not actually delivering to anyone (your Product Owner doesn’t count, nor does your client if you’re doing contract development).

Value is only realised when the code or solution is in production. That means it’s thrumming away on a live server somewhere, not sitting in your source code repository waiting for the “big” release at the end. Now it should be argued that you still don’t know that it has value. As more often than not there are no metrics gathered showing actual customers using and finding value in your new feature. However for the purposes of this and as a first step to thinking about value in a more realistic way we’ll imagine an ideal world where any feature developed has some value to your customers (no matter how rare that really is).

If value is not in delivering user stories or tasks, then where is it? Well, as you’ll probably already be thinking after reading the above, the value is in the release. Everything else is just work to get you to the release.

That prototype you built, it has no value, it’s just a step to release. Something to steer you towards a more valuable release. That feature you built that’s waiting in source control for deployment. Again it has no value.

This normally means that your Scrum board, task board or Kanban board is a lie. Take a look at it now. Does it represent the steps to realise value? Does it only have cards on it that are representation of units of value (things that can actually be released when they get to the end of the board)? There’s a good chance that they are not. They’re probably just tasks waiting to get batched into a release. Your board is probably just a fancy to do list. Useful but not really representative of the actual process. Also not terribly useful in tracking if value is being delivered in a timely and consistent fashion.

I’d suggest that you try and visualise your actual unit of value on a board. So in most cases this will be a project or a release. It might not feel as nice as having a lovely busy board but at least it will be truthful about the situation. A situation where huge chunks of work are being shoved through the system and blocking up the whole process (all whilst your previous board was showing a lovely stream of falsehoods). This will also go some way to address the feeling that you are working incrementally when in reality you have a micro-optimised development process that is thrashing through large projects. Finally puncturing the illusion that you are agile/incremental/iterative when really you are just blind to the whole value stream.

Don’t worry you can keep your old board, but now it will be a representation of reality – in that it’s just a way to help you organise the work within the large batch of value that you’re trying to deliver.

Once you can actually see the problem then you can start to address it. Slim down your projects, do smaller releases. Work towards single piece flow. But that process can’t start whilst you’re still in denial about the value that you are delivering.

Photo Credit:  ShnapThat!  –

Managing your input queue will seriously increase the chances of agile success

The smoking ruins of failed agile seem to be wherever I look these days, with people bemoaning how it doesn’t work and has if anything made things worse. There can be a multitude of reasons for agile to fail (frankly it’s not just agile that fails but the hype sometimes does agile a disservice), however a common reason is the lack of proper prioritisation of work, particularly when teams service more than one product or project.


At this point some people will be smugly looking at their neat prioritised backlogs and feeling distinctly superior. However a neat backlog alone is not the solution to the problem. For instance is your backlog iterative? Do you have stories that build on earlier stories? Have you just got a list of things to do where the business value is delivered after a whole batch of user stories are delivered? Is your backlog prioritised infrequently or only once? And finally, is your backlog a mess of chaotic user stories in some random order that you dump on the team from time to time in order for them to try to pick their way through. (Isn’t that what self organising means?)

If you recognise any of the questions above it’s normally because the queue of work to be done is badly managed. In Scrum that might be that the product backlog is too granular and disorganised. In Kanban it might be that managers are just slapping stories into the input queue with little regard for what needs to be done next – then re-ordering minute by minute for no clear reason (Isn’t that why you ditched scrum and did Kanban instead?)

By helping to prioritise the backlog or the queue of work, instead of a great morass of work being thrown at the team for them to work out the priorities, the team is empowered to pull the next item in the list without having to pick through a messy backlog.

This is often where managers can begin to resist agile practice, normally with excuses about not being able to prioritise because everything needs to be done. Really what they are saying is “I don’t want to be responsible for prioritising”. In that way they push the decision-making to the team without the required empowerment and therefore the blame of things go wrong. Or worse they try to take further control away from the team and tell them which user stories must be done in minute detail, accounting for every minute of a developer’s time.

However there is a way to wrest back control. Have a firm queue limit (in scrum your sprint backlog, in Kanban a WIP limit on the input queue) with a defined policy for how work can get into the backlog and be removed from the backlog. The manager or more commonly the managers then must talk to each other to ensure that the highest value work is being done in relation to other projects and other parts of the business. Also it may encourage more communication within the team during prioritisation. Scrum prescribes this sort of behaviour, Kanban allows this behaviour to emerge.

This simple area is often where agile begins to fall apart as it is commonly grown from within a development team. The team is then often unable to do anything about the input queues of their own work. This usually means agile adoption ends in work being done to the “whoever shouts loudest” model of management. This bakes in existing bad behaviour, or worse allows it to emerge!

The key is to ensure the person(s) who own the queue take responsibility for it. In Scrum that’s the  team, including the product owner (most scrum implementations I’ve seen seem to neglect this vital role). In Kanban that’s limiting WIP with clear policies for how the queue is stocked and how work is pulled from the queue.

The reason this is so vital to agile success is that it acknowledges that agile practice does not exist in a development vacuum. It is part of the wider aims of the organisation and it requires us to look at the entire value stream and manage the flow of value/work in relation to the overall organisational objectives and priorities.

Photo Credit:

Go/No Go? Simple question powerful results?

I was thinking about the process of building a solution and it occurred to me that in many ways, each stage of developing a product or project is a simple Go/No Go question.

It doesn’t matter how complex or simple it is to reach the Go/No Go question, the fact still remains that all we want to know is if we should stop or continue. Let’s look at an example.

Imagine I have an idea for a fantastic new website that tells you how many weeks it’s been since your last run and prods you to go running. (I didn’t say it was a good example!)

At first it’s just an idea, but already I’m at my first Go/No Go gate. Is the idea worth spending some time on? At this stage I might just mull it over for a bit. But in the end I’ll either decide it’s worth looking into further or it’s a rubbish idea.

Assuming I said it was a Go. The next phase might be to do a quick hack to see if it’s interesting or so I can share it with some people. Once I’ve done this I’m again faced with the same question. Go/No Go.

Now we have an idea that’s made it though at least two gates perhaps I’d like to think about how it might become a proper product. So my next move might be to do a Lean Canvas, where I outline the business model. Again the purpose of this is to get to a Go/No Go gate.

Eventually I’ll start doing development on the product. I might even identify a MVP (minimum viable product), but again I just want to get it up online so I can get to another Go/No Go gate.

Finally, making one last leap of assumption, my product is successful and I want to build some new features. Again for each feature we can use the Go/No Go cycle.

This can go on indefinitely but the point is by using on the Go/No Go question I’m focusing on what I need to know to make that decision. Also, as it’s a choice that means I could throw away what I have done so far, it makes sense to work in smaller chunks. So there is less waste if I do hit a No Go.

What happens if we do hit a No Go? Well if it’s a product/project in development then it means just that. We’ve hit a point where there is no value in continuing. Do we want to launch something that has no or negative value? If the product/project launched and is delivering value then the No Go is only for the feature(s) about to be added. Again do we want to launch features without value?

What might happen if we can’t make such a binary decision? I’d suggest in that instance we need more data. Perhaps conduct an experiment or experiments to test the hypothesis. Whatever happens, in the end we’ll get to a Go/No Go choice.

The key to the Go/No Go approach is to ensure we eliminate the waste in getting to the Go/No Go gate. Take only the steps that allow us to make that decision, whether that be some thinking time, a napkin sketch or an iteration of development. Also that if we deliver value as early as possible in the process we minimise the risk of major waste.

Do you use a digital agency, it might be time to re-think your options?

Coming from a background in digital agencies I’ve often asked why a client wanted to hire an agency. However clients rarely understand why they need to hire an agency and in a lot of cases it’s not actually what they need at all, well not a traditional agency relationship anyway.

Traditional agencies work on the basis of project work. They are hired to do a project for the client (build a new website, re-design an existing website to make it better etc). There are only two reasons a client hires an agency in this context.

  1. They have the skills but not the time/resource to do the work themselves
  2. They lack the skills to do the work themselves

These two reasons, when coupled with project thinking (thinking where you give a brief, the work is done and then handed over to the customer at the end) lead most companies to look at an agency model to get the work done. You agree a fee with the agency, they do the work and the risk is all theirs. Sounds lovely in theory, but unfortunately the business of the web doesn’t fit neatly into the project model. It’s a good model for when you’re building a house or something tangible but falls apart with software.

The reason it falls apart is that a website or piece of software is not a finite project. There is no end state, just a constant state of improvement and development. You launch your site and customers want new features, or the market changes. You then need to go back and make changes to the “finished project”.

So now you have a choice, if you haven’t planned for this already, you either go back to the agency and do another project to add improvements or you do the improvements yourself (depends if your underlying reason was 1 or 2 above). So really you didn’t solve your underlying problem, lack of skills or resource, you just delayed when it became an issue. Add to this that the pace of change is getting quicker in the marketplace and you can see that old project based thinking is not the solution.

So what are the options you do have?

  1. If you have a lack of skills then get those skills on board.
  2. If you have a lack of resource then get those resources on board.
  3. Use a digital agency that thinks beyond projects.

Option 1 and 2 are really the only viable and sensible solution if your digital product is at the heart of your business. In fact think about the message you send out to your existing team(s) if you get in a digital agency. You could be sending out a message that you don’t want to invest in their skills and would rather pay someone else than help them get better.

Option 3 means looking more closely at your agency of choice and understanding that you will need to be with them for the long haul. This means thinking beyond projects. You’ll need an agency that values transparency with you and wants to work collaboratively with you and your team. The agency will need to gel with your organisation seamlessly and become like another ready built department. The agency will need to be brave enough to share knowledge and skills with your teams and sometimes work co-located with your company. You’ll need to look at a billing model that is collaborative and cost effective over time.

Does that sound like your existing agency or any agency you’ve worked with before? Chances are it doesn’t and that’s because most agencies are stuck in old ways of project centric thinking because clients expect/demand it. However it is incumbent on both the agency and the customer to reject this old mode of thinking to ensure that agencies and the solutions they provide are fit for the future.

Traditional vs collaborative agency model
Traditional vs collaborative agency model


The value of values

I read with interest Alexander Kjerulf’s blog post on 10 things companies should stop doing now. Obviously any article in a top 10 format is going to talk in very general terms but I was surprised to see number four on the list… Corporate values.

I think that rather than simply casting aside values there is a greater need to define what we mean by values and where they fit into an organisation. To simply stop considering them is very much in danger of throwing the baby out with the bathwater.

Values do not exist in isolation. This is where I think Alexander’s problem is with values;  corporates coming up with vague nebulous values and simply imposing them on the company. Or values are simply stored on a piece of paper gathering dust, rather than acting as a unifying set of goals and principles.

Values exist in an onion shape, in that there are multiple layers of values. Corporate values are just one of these layers.

At their most basic, values can be thought of as existing at these three levels:

  • Personal
  • Team
  • Organisation

Dr Steve Peters in his book The Chimp Paradox talks about the stone of life, where we store our personal values. Organisational values are critical to the Toyota way (lean) as mentioned in the book This is Lean by Niklas Modig. Team values are important in Agile and there are well defined techniques for helping teams develop shared values (see Coaching Agile Teams by Lyssa Adkins).

These three value layers feed into each other. If we have team or organisational values which conflict with our personal values then we will likely experience cognitive dissonance, causing us stress.

This means that in most instances values at the team and organisational level should be negotiated and agreed. Only our personal values are non-negotiable. Although like anything our personal values can change with experience.

Values are living and breathing entities, like plants they need light and water to grow. We need to ensure that when the seeds of values are sown they take root and we attend to them regularly.  Also that unrealistic or unhelpful values are pruned back as we, our team or organisation grows.

Values far from being a static burden are a living embodiment of who we are and what we believe and as such they are at the heart of any organisation. Use dusty old values as a catalyst for change and don’t simply toss them away without at least first trying to fix them.

Persistence hunting and the art of agile

Thousands of years ago on the grassy plains of Africa before the bow and arrow, early hominids used to literally run their prey to death. Their prey was fast and cunning. But crucially it could only run short distances and if the hominids persisted they could eventually catch their prey by wearing it down.

When we are managing projects we need to take a similar approach. If we plan the hunt in great detail the prey will slip away almost immediately, easily able to sprint off whilst we remain static trying to second guess what will happen.

However if we get started quickly and persist, allow ourselves to focus on the objective of running the prey down, change direction as we need to, not panic if the prey gets ahead of us (as long as we can still see it). Then in time the project will slowly tire and we will get close enough to finish it. This model reflects how projects will start off volatile (full of energy and change) but as we progress and deliver, slowly become more manageable.

It is part of our evolutionary history and makeup to think like this. It seems absurd that we find this an alien way of thinking and must invent process to try to engage in a hunt. Instead all we need is to lean back on what made us successful in evolutionary terms.Then we will find that we have all the mental tools needed to work in this way.

Tools such as working as a team in relentless pursuit of our prey. Not knowing how long a hunt will last but remaining clearly focused on the objective. Changing and adapting to the conditions as we find them. Communicating across the team to effectively bring our collective resources to bear on the object of the hunt. Also and most importantly progressing at a sustainable pace, as that is the very nature of persistence hunting.

There can even be roles for specialists on the hunting team. Trackers who are adept in reading the prey’s mood and whims so we always stay with them. Sprinters who quickly catch up with the prey and fall back at other times. The management and leadership of the team is rotated and seamlessly switches from person to person as the hunt progresses.

So get Palaeolithic on your next project and remember that through agile techniques we are simply attempting to reconnect with our innate ability to work in this way.

More about persistence hunting:

Are you doing or being Agile?

It’s amazing how many times I’ve seen companies saying they are doing Agile, when in fact what they have is a ritualised version of Scrum without the good bits.

The very term “doing” Agile should always ring alarm bells. You can’t do Agile at all. By adopting this mind-set you invariably fixate on the tools and rituals of (usually) Scrum, without ever-moving to the understanding stage.

In fact I’d say that it doesn’t really matter what framework you tell yourself you are adopting the main part of becoming more Agile is a shift of mindset. This shift of mindset can be hard to achieve, in fact you could say being Agile is like being happy.

It’s something we all want but often don’t know how to go about. This again is often because we focus on the method or the tool of being happy. If I lose a few ponds I will be happy. If I could just run a marathon I’d be happy. Again this is focusing on the mechanism not on the mindset.

This is why I am beginning to see all sorts of ranty blog posts about how Agile sucks and it isn’t all it’s sold to be. This is normally because what people have experienced is what I call mechanised Agile. A process imposed from on high to a problem that is cultural.

So take time to think about your current Agile practice, are you being or doing? If you are simply doing then take a moment to reflect on one thing you could change that would help you or your team be Agile.

Perhaps you could start with the standup and do away with the interminable three questions ritual which often becomes an anti-pattern. Or perhaps just introduce the elephant in the room; that rather than being Agile you are merely doing.

When did you last help your boss?

Put your hand up if you have ever moaned about your boss (ok, don’t actually put your hand up the boss might be watching). I suspect it made you feel better but didn’t solve the problem.

Next time instead of venting to someone else, try and recognise the human in the bosses suit. They have needs, desires, fears and insecurities like the rest of us. Perhaps try and see things from their point of view.

Why not even try and help them? Try and work with them to help them understand what you need from them and what they need from you.

Obviously there are some alpha wolf types who can’t be helped but often your boss is just someone trying to get their work done the same as you.

We all have values and needs and we need to recognise this  in everyone that we work with. But someone has to make the first move. Will it be you who starts making the work environment a better place or are you waiting for someone to do it for you?

Become the beachcomber

I was walking along the seashore in Norfolk recently, watching a group of people trudging up the beach picking up the valuable pieces of driftwood and objects that had been washed up during the night. They were busy in their work and were extremely discerning. Rejecting out of hand clumps of greasy seaweed but carefully inspecting anything that looked interesting. But even then only a very few items would actually make it into the string bags hooked to their belts.

Since then I have resolved to become the beachcomber, picking up the items of value washed up by the tides of agile methodologies. Waiting for the tide of popularity to recede a little before inspecting what it has left behind in the way of useful detritus.

It is easy to be beguiled into thinking that the latest agile tide will be the last, but it won’t be long before that tide recedes and another follows. By keeping to the tide line, we can observe the cycles of popularity and pick only that which is of value. Leaving the rank piles of seaweed to slowly rot away.