User Stories Don’t Deliver Business Value

User stories tend to focus on the user not on the business value. I think it’s largely to do with the popular “As a <insert type of user> I want to <insert thing to do here> so that <insert reason here>” format.

This more formal wording of user stories takes longer to think about and write down and I’ve found it can slow down story writing workshops and hold up the creative process.

Remember that User Stories are merely the promise of a future conversation

My Tips:

1. Use 5×3 cards as max size

2. Get the customer writing the story

3. Try to write, in as few words as you can, a title that the customer will remember what is needed

4. Capture the business value as the story title

5. Avoid any implementation details (e.g. words like screen, page, button and anything else that is a thing that will get implemented in a system)

The trick is to defer discussing the implementation details of a story until the last responsible moment. Ideally this will be at the point that someone is actually able to work on the story. In general this works out fine but there are times when you’ll need a little more upfront thought. One example of this is when you’re integrating with things (software/hardware) outside of the teams control. Often a little more upfront work and coordination is required.

As stories hit the backlog quickly markup the ones that require more upfront thinking (look for dependencies, technical risk etc) and review the backlog at least weekly to make sure you’re on top of getting these stories in play in a timely manner.

Lean/Kanban people often talk about focussing on business value – in fact I’m one of those very people and generally this is the right thing to do. However there are times (like those described above) when technical concerns need to be balanced against business value.

WHAT…The Product Owner ISN’T The Customer

So it appears I may have been doing the right thing wrong all this time…Scrum talks about a Product Owner role and I’ve always had teams setup so the the customer (one or more actual people) fulfils this role. Recent discussions on the Scrum mailing list seem to say this isn’t the case.

Personally I’d rather the customer takes control of the product they’re paying to have built. Having an intermediary within IT making decisions on their behalf seems like a problem waiting to happen. In fact I’ve witnessed this first hand in a previous company (remaining nameless to protect the guilty) and mess that ensued.

The IT based Product Owner gets IT based goals and objectives and their primary objective is related to the software and not the organisational value that should be the ultimate goal. You got a business problem – you can guarantee the Product Owner will come up with an IT solution to solve it. Then you take a less-than-optimal-business-process and enshrine it in some software that is far more costly and complex to fix and becomes more difficult to use.

The closer I’ve had the customer to the development team the more successful the projects I’ve been involved in have been. Maybe it’s just coincidence but then I don’t believe in coincidence….

Sure it may seem impossible to change your organisation to adapt to getting the customer closer to the development team…that’s fine if you like living with pain. Have the courage to change the organisation and see the difference it makes. Agile/Lean don’t solve organisational issue they merely make them much more visible!

Never Let The Customer Forget

So no matter how hard you work and how much stuff you deliver I’ve always been amazed at how easily the customer forgets what you’ve done when things aren’t going so well or they can’t get what they want (*enter customer stomping feet and throwing tantrum*).

So one thing I’ve had teams doing over the last year or so is keeping all the work they’ve done visible at all times. For some teams they take a story card (different colour works best) and use it to record every release they make to production and keep a list of those cards somewhere very visible.

Other teams have put their completed cards (once released to production and delivering value) on the outside of one of the rooms in their office that has walls made of glass…they now cycle through taking off the older cards as newer one’s are complete since the wall is completely full of cards.

And the simplest of all..one team simply wrote a list of the releases they made on their information radiator (white board) along side the cards that were being worked on.

The customer really loves to see this, it creates a trust with the team and always generates a lot of interest when other people in the company wander past and ask what it all means…when you tell them it’s all the work that’s been released live it never fails to impress and excite people.

Whole Team Stand-up

I’ve lost track of what people are saying is best practise for stand-ups nowadays. I know what works for me and the teams I’m working with and one of these things is including your stakeholders/customer.

Don’t just include them but actually have them answer the same questions as the team. My experience has been they find it a little awkward or silly to start off with but there has always been an “aha” moment where either the customer or the team have got some extremely useful information that has been a big benefit or has lead to some really great opportunities. After that there is no turning back.

Is this something specific to Kanban…well heck no. Is this something that can help most teams…absolutely. It adds trust and transparency between the team and the customer. It provides the opportunity for the team to be even more effective. The team can also provide support to the customer that they never even thought of.

Sure this may make the stand-up take a bit longer but the value you gain could well offset this. Also don’t have long retrospectives – adopt a more kaizen approach to improvement which will free up time. Also don’t spend so long or don’t even do estimates – you’ve got more trust and transparency with the customer so your prediction of the future (which invariably won’t pan out) is not longer required.

So rather than seeing the stand-up primarily as a tool for the development team, instead take a systems thinking view and see it as an opportunity for everyone involved in the project.

Scrum of Scrums

So recently I heard of a team that is using Scrum and their manager had decided to have a “Person of the Iteration” award for the person that completes the most points in a Iteration.

I think this totally misses the point of Agile being a team of people working together to get as much stuff “done” in an iteration to the highest levels of quality.

Do you have an incentive to help other people in your team complete work? No Way

Would you like to pick all the easy stories in an iteration to have a chance of getting the award? You betcha!

What happens if several people work together on a story – who gets the credit? Well firstly you’re not encouraged to do this to win the award and secondly I have no idea how that works.

Personally I’d be working with the team to address some of the root causes of their low velocity and helping them find ways to improve rather than introducing awards that drive completely the wrong behaviour.

As a result I’m running a “You know you’re not Agile when…” series on twitter to keep me amused (you can find me as kanbanjedi).

Software Development is a Team Sport

So recently I heard of a team that is using Scrum and their manager had decided to have a “Person of the Iteration” award for the person that completes the most points in a Iteration.

I think this totally misses the point of Agile being a team of people working together to get as much stuff “done” in an iteration to the highest levels of quality.

Do you have an incentive to help other people in your team complete work? No Way

Would you like to pick all the easy stories in an iteration to have a chance of getting the award? You betcha!

What happens if several people work together on a story – who gets the credit? Well firstly you’re not encouraged to do this to win the award and secondly I have no idea how that works.

Personally I’d be working with the team to address some of the root causes of their low velocity and helping them find ways to improve rather than introducing awards that drive completely the wrong behaviour.

As a result I’m running a “You know you’re not Agile when…” series on twitter to keep me amused (you can find me as kanbanjedi).

Scrum & Kanban – Compare and Contrast

Henrik Kniberg has put together a good article on the similarities and differences of Scrum & Kanban here: http://blog.crisp.se/henrikkniberg/2009/04/03/1238795520000.html

On the whole a pretty good article. I don’t fully agree with the section that talks about using estimates if you need predictability. Estimates are simply a prediction of the future but real predictability comes from regular, quality releases of software from the team – cycle time and other metrics should be used as a far better measure of predictability.

Unless of course your team is in the very small minority of teams that can accurately predict the future. If you want a prediction of the future why not go to your local fair and visit the resident fortune teller – they will likely be as accurate as you.

I also don’t agree fully that Scrum is a pull based system. Letting the team decide the order they work on stories and then packaging that into a Sprint seems like pushing work in batches through the system. Iterations don’t really support flow and work is not continuously pulled into the system.

Finally the last page talks about starting to do Retrospectives. My advice from a Lean perspective is don’t – set yourself up to continuously improve (kaizen) and that as you find things that don’t work or don’t seem right then sit down and identify and fix the root cause. Don’t let things fester. Continuously look for ways to improve and be better. Don’t batch things up.

Eggs With Your Bacon Sandwich? Systems Thinking Stand-ups

One of the things in Scrum I’ve always struggled to come to terms with is the concept of Chickens and Pigs. For those of you in the dark this relates to who is involved in the stand-ups err..Daily Scrums.

It relates back to an anecdote about a Chicken and Pig working out how they setup a restaurant. The pig suggests the chicken give eggs and the chicken suggests the pig give bacon. The pig then complains that the chicken would be involved but he would be committed. So pigs are the only people that can contribute during stand-ups and other meetings. Pigs are generally the development team – some teams won’t even include the PO as they don’t actually make the commitment to complete the work in a Sprint.

And yes the chicken and pig terminology can really put people off scrum – especially stakeholders who struggle with the metaphor and tend to feel it excludes them.

This means stakeholders outside of the PO and the development team don’t provide any input at stand-ups – stakeholders like sales, marketing, senior management, finance, etc. Whilst this is great for the development team as it keeps the discussion ring fenced it also means that valuable input the other stakeholders might have isn’t injected into the discussion.

The stand-up should be an opportunity for the team to optimise the work they do and the way they work. By not giving a voice to all stakeholders the team potentially misses out on valuable information that could alter the way they work and what they work on.

With all the teams I’ve worked with in the last 6 months I’ve had all the stakeholders answer the 3 questions and it’s been a revelation to everyone involved. Initially the stakeholders don’t really know what to say but pretty quickly they have all sorts of gems to contribute and even take responsibility for getting issues resolved. Additionally they feel more involved with the team and the relationship of trust grew quicker and became stronger than other teams that didn’t involve the stakeholders.

Some teams voiced a concern that the stand-ups would take too long. Some of the teams that use this now found it made almost no difference as the stakeholders got through their part pretty quickly. Other teams decided to spend longer in the stand-ups with the stakeholders because they felt the valuable information and discussion they had and the trust that it built with the stakeholders was invaluable in allowing them to be even more productive.

I highly recommend teams that haven’t tried this to give it a go for a few weeks and see if you don’t notice a difference. Let me know how you get on.

Agile Is Easy

We’ve currently got some .NET Agile zealots developers in our office doing some work and last week we had a prospective client come down to see the team in action.

The engineering practices in Agile (Continuous Integration, Test Driven Development, Pair Programming) aren’t the easy thing to do well and seeing our team doing it brought home to our prospective client is that it takes a lot of effort to do it really well but, the payback for being able to do it is massive.

I frequently visit clients who think that a couple of weeks of consultancy time is plenty for them to be fully agile. The reality is something different…it’s a much longer process that takes a lot of effort.

The other thing to remember is that it needs the support and understanding from everyone in an organisation – from the top down. If the CEO/MD isn’t bought into it then it’s always harder to make it happen – only stellar performance on a project will start to change the way the organisation works but you can expect lots of challenges on that project if other people aren’t bought into it – trying telling a Release Management team you’re going to be giving them new releases of your software every two weeks and it’ll take lots of beer to calm them down to a point you can have a serious conversation with them again!

Priority Tokens

I met up with Karl Scotland just before Easter for a chat about our experiences with Kanban systems and whilst reviewing his information radiator we talked about the idea of having numbered priority tokens for each of the WIP limit slots as a way of keeping teams focussed on priority, even for the work actually in progress.

Basically cut out some circles and number them from 1 to X…1 being the highest priority. The number of tokens should be equal to your WIP limit. Then place each token next to the MMF (minimum marketable feature) or work item based on the relative priority of the work. The team should be asking themselves are we doing all we can to get the highest priority item of work completed?

The idea being it can help the team work out how to most efficiently self organise to get the highest priority stuff done quicker. It also means if the priority of work changes the tokens can be moved about to make it immediately visible where the focus should be.

Too often I find teams that have 1 work item per person on the go when it would be more effective to have several people working on a higher priority item to get it done earlier (or on time). Unfortunately having several people working on one thing makes managers scream “…but that’s inefficient because X, Y, Z” (replace X, Y, Z with a set of excuses) or developers scream “…but it’s impossible for more than 1 person to work on that”.

However helping managers understanding that getting things completed rather than lots of things being worked on in parallel is part of my job and I’ve yet to find a situation where this didn’t turn out to work much better for the team. From a development point of view there are instances where it isn’t practical to have multiple people work on something but that’s generally down to poorly designed software and bad configuration management practices – fixing these underlying issues solves a ton of other issues as well and means you can be more effective as a team.

I need to add that this isn’t something that I’ve tried yet but I’m hoping when Karl gets his new boards up on the wall we might be able to give it a go and see how it works out.