When implementing agile in an organisation, one of the first questions management will ask is “what metrics will I get”. This is not an unreasonable question. They are financially responsible for their part of the business and are used to dealing with a particular set of metrics that let them assess the performance of their teams and take action if action is needed. RAG (Red Amber Green) status on projects, schedule variance, earned value, actuals vs estimates, risk profile, and so on.

When agile comes on the scene, those measures go away and management feels like they have lost control. So a question about agile metrics is perfectly reasonable. How do I, as a manager, see that my process is working well? How do I tell when things will be delivered? How do I tell how much stuff will cost? When answering this sort of question, the answer we most frequently turn to is velocity. Most agile systems have some concept of velocity – how much a team can produce in a given time. The problem is that velocity is a very poor way to measure those things at any scale beyond a single team. Velocity just wasn’t designed to answer this sort of thing. Why? Well to see why velocity isn’t a good measure for these questions, we need to look at what velocity is designed to measure.

Most agile teams these days organise their backlog into user stories. The user story isn't mandatory in any agile methodology but they have become the defacto standard for agile projects. There are many good reasons for this, not least of which is that a well written user story keeps the focus squarely on delivering something of value to the user. Many user stories though are not well written. It takes more than using "story normal form" - As a I want so that I can - to generate a good story.

Many of the backlogs I see are filled with stories that, frankly, stink. Bad stories don't keep the focus on what is important. They distract, confuse and mislead. There are some criteria like INVEST that we use to assess user stories and properly applied they make a big difference to the quality of the stories. They do take some time to learn and apply though so I'll give you a few quick tips to get started. Over the years I have come across a number of common mistakes that teams make when writing stories that cause their backlogs to stink –

I have noticed a trend recently in the Scrum community of de-emphasising, or getting rid of entirely, the concept of Tasks. Teams are encouraged to just run with stories and no finer grained level of detail. I’m not sure this is a good idea. I do have to say here that when I say "tasks", I am not necessarily talking about technical tasks. A task (to me) is something of less than a days duration that needs to be done in order to get the story done. It could be a sub-story, a technical task or a single acceptance criteria, or whatever the team uses to break down the stories into smaller chunks.

I do a lot of coaching at large companies. Big, monolithic, and often very conservative organisations. Organisations like that are very difficult to change. They have become big and successful by being conservative and risk averse. There is a lot of resistance and inertia. They may recognise the need to change. They may recognise the benefits of change. Actually making that change though, means taking risks and they just can’t quite take that step. They will fiddle around at the edges and do some cosmetic stuff, but actually changing into an organisation that embraces innovation and risk is just a step too far.

At work I do a lot of stuff. I help teams produce software that is used by millions of people. When I am home on the weekend I do more work, but it's different work. I work with my hands producing things. Physical things. Although what I do at work is valuable (far more valuable in dollar terms than my attempts at DIY) I almost feel more of a sense of satisfaction at seeing a finished thing worth $50 roll out of my workshop than a million dollar project roll out of one of my teams. Because it's real. Because I can touch it and pick it up ( well, maybe pick it up... some of them are quite heavy). Because it is a physical thing.

In the Agile world, we (and I am certainly no exception) talk a lot about Self Organisation, but what does that mean? What is this thing called Self Organisation?

Let’s look again at our team from the last post and take a closer look at the Team Lead. It’s easy to see how Fred got into the situation he was in. The job of Team Lead is very unclear in an Agile world. One of the agile principles is that all team members are equal so what does a team lead do? I usually recommend that teams don’t have a team lead. That forces them to look after themselves rather than relying on a team lead to do it for them.  Most large organisations though insist on having a Team Lead for every team. That’s OK. We can live with it. We just need to work out what an agile team lead does.

I recently coached a team that had a problem. Actually, they thought they had a lot of problems. Their builds were a mess. Their environment was unstable. Their tests were broken. They were finding it very difficult to get any work done. Their once excellent planning was starting to drift away from reality. When we started to look into these problems though, it became clear that all these problems had one single cause – their team lead.

Hi Folks

We probably all know the old story about the tortoise and the hare. Speedy hare raced off, got tired and had to have a rest while slow tortoise kept plodding on at a steady pace and eventually won the race. Even hare's mad dash towards the finish wasn't enough to catch up. Everyone knows the moral of the story - slow and steady wins the race. When it comes to running projects though, we behave more like hare than tortoise.

Hi Folks

If you ever visit a lean manufacturing plant you will see, at every workstation, a cord or button or lever attached to a big, red, flashing light. It's also attached to the production line machinery. Press that button, pull that cord or move that lever and two things happen - first, the big, red, flashing light starts flashing and the production line stops. In Lean Manufacturing, this system is called Andon (Japanese for Indicator).

Hi Folks

In my last post, I mentioned in passing the phenomenon of sub-optimization - where optimizing one part of a process negatively affects the throughput of the whole. This is covered by the seventh (and probably least understood) principle of Lean - See The Whole.

Hi Folks

In many companies, resource utilization is considered an important measurement. The idea is that resources, whether they be machines or people should be occupied as close to 100% of the time as possible doing chargeable work. On the surface this looks pretty sensible. No point having people spending time doing things that the company doesn't make money from is there? The more time people spend working on chargeable tasks, the more money the company makes. Right?

Hi Folks

I had a discussion recently with a group of software architects about whether Architecture had a place in Agile development. This is an important (and at times hotly debated) topic so I'm going to expand on the discussion here.

In Lean, waste is anything that does not add value. The key to Lean is getting work flowing rapidly and this is done by identifying and eliminating sources of waste. Some sources of waste are obvious - tasks blocked through lack of feedback, rework due to misunderstood requirements and things like that. Some sources of waste though are not so obvious. Some are so insidious that we live with them all the time and assume they are an inevitable part of daily life.

Over the last 2 days I have been taking part in the inaugural Scrum Australia conference. We have had Agile conferences for a while but this was the first specifically Scrum-themed one held in Australia.

I recently checked back in on a team I had started up a while back. Over the months since I had set them free they had made a few modifications to the process and in doing so had fallen into one of the most common traps I have seen teams fall into - they had made it all about the developers.

My first inkling that there was something amiss came when one of the testers on that team approached me for some advice on how she could be more efficient in her testing. She felt she was falling behind. When I dug a little further it turns out the team had delegated the job of unit testing to the testers to "free up the devs". This was in addition to the acceptance test automation the testers were doing as well. The devs had also resisted any attempts to assist with testing so "they could be more efficient".

The key to Agile and Lean methodologies is “the rapid delivery of customer value”. Anything that does not add value is considered waste. In Agile, value is often defined as “working code” but this is too narrow a definition. It assumes that the only stakeholders that matter are the end users of the software and that the only product the team needs to produce is the software.

In reality, the team is unlikely to be producing just software. At the very least there will be documentation and other end user collateral. There will also be artifacts that are not valuable to the end user but may be of immense value to other stakeholders. It could be argued then that pretty much anything turned out by the team has value to someone. So what is waste? Working code is too narrow. Absolutely anything the team does is too wide.