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!  –

Agile is not a methodology, it’s an Albatross…

One of the hardest things to understand when starting out on the Agile journey, is that although most often sold as a methodology, this is looking at it at the wrong way. Scrum is a methodology, as is Kanban or DSDM or XP. But none of these are Agile itself.

The problem is that often the first experience of anything termed Agile are the methods and tools of a particular methodology. It’s how I was first introduced to it. The methods and tools however are of no benefit in and of themselves. Yes, they can help uncover issues in your current process, Yes they may have some use in helping frame agile in your mind. But this is really of limited value, as a new set of tools is not the answer to a dysfunctional organisation or industry. Frankly that’s fiddling whilst Rome burns. A methodology is not meaningful unless accompanied by a change in mindset, without that you’re just going through the motions.

The problem with Agile today is the word Agile has baggage. So much so that it is pretty much meaningless. If I asked a room full of people, who thought they knew what Agile was, what the term Agile meant, a large portion would describe a methodology (which it isn’t) and the others would probably all give me conflicting answers.

If Agile is not a methodology and it’s not really got a definition – what use is it as term?

The language and the terms we use, help define and bind us as a group. Shared terms, shared understanding, shared beliefs.

So the real meaning of Agile (if we can reclaim the term from the methodologists) is that it is the expression of a collective mindset. A shared set of values if you will. Are those values the ones defined in the Agile manifesto? I don’t think so. I think the mindset and values are evolving and we’re yet to see anything close to a definitive set of values. That’s why we need a collective term to represent and be the vessel for the inchoate and evolving values.

The language we use and the definitions that they collectively hold are important. Shared language is what defines the groups that we belong to. That the word Agile is now so laden with baggage that it has lost its meaning is perhaps a symptom of a deeper underlying issue. An expression of a community that no longer has a shared vision or language.

A community that is becoming so myopic and fixated on the methodology and tools that it is losing its collective vision. In its place a morass of commercial vendors competing to reduce Agile to a packaged and marketable commodity.

Like the term Free software morphing to open source isn’t it time to define a new shared language and reclaim the essence of Agile without the methodology?

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:

Trying to make sense of Rightshifting

I’ve been learning about Rightshifting of late and am finding the mental models used difficult to imagine. This led me to think about how I could redefine them so they made more sense to me.

However first up let me briefly surmise what Rightshifting is.

If you haven’t got time to look at these links now, skip forward, but they do a much better job than I will of explaining!

Rightshifting is a word coined by Bob Marshall, here’s his post explaining it.

In addition there is also the Marshall model, here is the explanation:

Basically Rightshifting is based on the premise that an effective knowledge work organisation is a function of the mindeset of the organisation.

There are 4 basic mindsets in terms of organisational effectiveness:

  1. Adhoc
  2. Mechanistic/Analytic (these terms seem to be used interchangeably in the Rightshifting community)
  3. Synergistic
  4. Chaordic (if you’re interested in where the word chaordic came from, see this book: )

It is then suggested that the closer to Chaordic you get the more effective the organisation is. However most organisations are stuck at the analytic stage. Hence the need to right shift organisations.

Here’s Bob Marshal’s diagram of the Marshall model, taken from the above blog post:

Marshall model
Marshall model

Note the red transition points, denoting how hard it is to break through into a new organisational mindset.

What I really struggled (am struggling!) to understand was what the different organisational mindsets really meant.

So  I wrote down some words that might be used to describe the different stages:

  • Adhoc: Cowboy, messy, chaos, creation
  • Mechanistic: Process, tools, rules, methods, control
  • Synergistic: Learning, flow, empowered, value
  • Chaordic: Opportunistic, come together, mushroom, sharing

As you can see by the words, the adhoc organisation sounds like an early start up. The mechanistic sounds like most businesses! Synergistic sounds like an Agile or Lean organisation and Chaordic sounds more like an open source community.

I then thought further and came up with these definitions, to help me map it to my understanding:

  • Adhoc: Finding value
  • Mechanistic: Building value
  • Synergistic: Flowing value
  • Chaordic: Enabling value

Take a look at Rightshifting, if you haven’t already, and let me know what you think about my definitions of the various organisational mindsets and if you think they are a useful  or helpful way of describing them.

More Rightshifting posts:

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


Avoiding monsters by opening the box of requirements

How many times have you had a requirement from a client and implemented it diligently, only to find it’s not actually what they wanted at all?

Perhaps the conversation went something like this:

Client: It’s an emergency I need to add images to the “about us” page.

You: Sure no problem I just need to enable that in the CMS. It’ll take 2mins.

Some time later

Client: (Irate) It’s not working! I add images and they all appear in the wrong places.

You: Hmm, ok I think I can see what’s happening. Let me add some extra styles which should clean that up for you.

A little bit later still

Client: (really irate now) You’ve made it worse I tried to add a table to make it look ok but now the whole page is wrong.

You: Ahhh, I see what you’re trying to do – add a list of staff with a biography. I think we’ll need to build you a tool to add members of staff to that page.

Client: (Exasperated) Well of course! That’s what I asked for!

Now in this scenario, it’s easy to blame the client and say they didn’t know what they wanted or how to communicate effectively. But, to be frank, this is plainly wrong. The issue here is not bothering to open the box of requirement, then being bitten by the contents once you did.

Every requirement, no matter how small, is really a box. It can contain absolutely anything and it’s beholden on us to work with the client to open the box, look inside and make sure it contains what the label says. To do this we ask questions about what the requirement is trying to achieve and what value will be provided by the requirement.

Here’s a diagram showing a journey through the unboxing of a requirement in order to build a shared understanding.

A journey to shared understanding with the client

This diagram shows that although we start with an expressed requirement, the requirement we have in our mind and the one held in the client’s mind may be different. Therefore until we share our understanding with the client and they share their understanding with us we cannot arrive at the actual solution. As the actual solution will always remain unknowable until we have uncovered our and the client’s pre-conceptions of the requirement/solution. In short unboxing the requirement!

Often we forget to unbox a requirement when we are trying to be nice, when the client is putting us under pressure or when a requirement comes late in the project. However these are the times we need to be most careful to actually check what’s in the box before ploughing ahead.

Formal documentation is also the enemy of unboxing a requirement, as the written word acts as a box in itself. A written requirement is often written when we have only had the requirement expressed (top left of the diagram above). We are then more likely to trust the written word and therefore fail to gain a deeper understanding of the requirement – missing the fact that although the requirement is written it has not yet gone through the unboxing process.

It is this journey to a shared understanding that helps us ensure that what we build is truly valuable and that we are protected from the nasties lurking in the bottom of the box, ready to bite us when we’re least expecting.

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.