In many companies, especially those who provide services to external clients, the main focus from a project management perspective seems to be on resource allocation and utilisation. People are viewed as individual “resources” and an important goal is to maximise people’s utilisation (Before you say this is not true, think about how important this metric is at your company and that people tend to optimise what is being measured).

I know that especially for vendors who often charge by the hour or have to keep cost down in a fixed price and scope scenario, utilisation is hugely important. That’s fair enough. However, making utilisation the main driving factor, will backfire and ultimately lower utilisation.

Why is this a problem?

By foregoing the team approach, aiming to maximise utilisation and piecing together projects through dynamically allocating and re-allocating people we:

• Take away the focus from the real end goal which is delighting our customers (people who either pay for, use or support our application).
• Inadvertedly sub-optimise individual parts of the system such as e.g. design, frontend development or database design by isolating them from the whole product.
• Miss out on optimising the development of the whole product or project.
• Ignore the fact that software is developed as one-of-a-kind, which causes variety and makes predictive planning impossible. Honestly, stuff often gets finished either earlier or later than initially planned and there’s nothing we can do about it.
• Have difficulty absorbing this inevitable variety if resource utilisation is too high as people will either be idle or unavailable as a consequence of variety and lack of slack (This is bad for utilisation and people will either be stressed out and over-worked or bored. Also, no slack makes it difficult to deal with emergencies and opportunities).
• Run the risk of cascading delays within projects: If one part of the project is delayed dependent parts will be delayed as well, leading to a cascading effect.
• Run the risk of cascading delays between projects: Projects waiting for a particular person to come free will be delayed, again potentially causing a cascading effect on other projects’ schedules.
• Create an increased need for handovers between individuals. Handovers are regarded as one of the biggest causes of waste in software development and come with the added danger of losing valuable tacit knowledge. Handovers also often cause misunderstandings through ambiguity and are plain evil.
• Miss out on the advantages of working in teams. A well-functioning team collaborates to a level where the sum is way bigger than its parts. Well functioning teams create magic - much like the All Blacks on a good day.
• Make bad decisions: Without teams each individual on a project will only have part of the picture and it is almost impossible to make good decisions without knowing the history, background and reasoning behind all the other little decisions that have been made on the project so far. Also, diverse groups of people are usually superior in decision making ability to individual experts.
• Incentivise people to care about their particular part only, which leads to behaviours that are detrimental to the success of the overall system. For example, if I reward a football player for the number of goals he scores he will most likely engage in egoistic behaviour that damages team performance. The same is true for software development teams - especially if people’s utilisation is linked to their salaries.
• Waste time allocating and re-allocating people to projects and trying to get the impossibly complex and variable puzzle to work out.

What to do?

If we, instead of the above, provide a group of people with a shared vision, collective responsibility, the authority to design their own processes and ways of working (the essence of self-organisation) while incentivising them as a team and giving them the all the support they need they will have a much greater chance in achieving the end goal of delighting the customer.

So, let’s:

• Organise people into feature teams and give them the freedom to succeed
• Focus on improving the boundary-spanning handovers within the organisation (just as Mary Poppendieck says!)

People will also be happier and love their jobs a lot more if we let them experience the magic of a team and “move work through people, not people through work”.



For further reading about building teams and organisational structures and behaviours that support teams I highly recommend Esther Derby’s blog.

Tags: agile , team, organisations, lean

Checklists have a somewhat bad reputation in the Agile world, probably because they “smell” of too little self-organisation and too much process. I find this reputation is entirely undeserved as they can be extremely useful as a memory aid, or to visualize a workflow.

Checklists play an important role in areas where missing steps can have disastrous consequences, such as in hospitals or airplanes; or in situations where people are likely to forget individual steps, such as when they’re stressed and tired; or while learning a new process or way of working.

At work we mainly use checklists when we want to introduce a new workflow and need to make sure we don’t forget about the process or any of its steps.

Here’s an example of our checklist for the sprint workflow and working with user stories:

We usually keep our checklists visible until the new workflow has become second nature and we don’t need reminders or memory aids anymore. Although, in saying that I realize that we created this particular checklist 6 months ago and we still like to have it around :-)

For us checklists are a very useful learning aid and workflow visualization tool, and as long as we decide on the processes ourselves we don’t feel they interfere with our self-organisaton.

Tags: checklists, agile, lean

One of the things that immediately caught on when we started our journey towards being Agile at Snapper was the use of visual workspaces. The team loved the sense of achievement of moving a task from "In Progress" to "Done" and found the board helped them stay focused and co-ordinated. Everyone from team member to operations to management appreciated the level of visibility and transparency. Even my partner's 11-year old daughter thought my work place was the coolest ever as we had covered the walls in colourful sticky notes and Simpsons characters

This, in combination with my constant rant against excessive multi-tasking, too much work in progress and finishing one thing before starting the next seemed to have struck a chord with Gina, our designer, who started a "Kanban-for-One" movement at the office.

The “Kanban for One” board

The board, at Snapper known as “a Gina board” is used to organise personal tasks. The standard workflow is “Backlog” (stuff I want to/have to do), “Queue” (the subset of the Backlog that’s up to be worked on next), “In Progress” and “Done”.

The limited space for each of those workflow states imposes a natural limit on the number of items in each state, e.g. no more than 4 stickies fit into the “In Progress” area and getting more than 8 items into your “Queue” column is impossible. The lowest area on the board is either used as an expedite lane or for little inspirational messages and reminders.

The creator

Gina is the proud inventor of the Snapper Agile board. Unfortunately she has the least visually appealing board as she is stuck with an early version that had not received the benefit of several iterations of learning.

Spreading like a rash

Since people can place orders with Gina they’re spreading like a rash through our office.

Andrew with a board full of marketing tasks.



Sean, Head of Product, and obviously obsessed with the alignment of stickies.



The Product Owner’s wall


Reminders and ground rules on Gina’s board. I’m a bit confused about the haircuts though.


The Office

Conclusion

Apart from our team Scrum wall more and more people have or have ordered personal Kanban boards to supplement the team view with individual task management. We really like the boards to keep ourselves organized, protect ourselves from the temptations of multitasking and to communicate to the rest of Snapper what we’re working on.

Some people are combining the personal Kanban boards with the Pomodoro technique which seems to work really well too.

To read more about this topic read Courtney’s excellent post “Adapting Agile’s visible workspaces to the humble to-do list” over at Boost.

Tags: lean, kanban, workflow, agile

The idea

For quite a while I have been waiting for an opportunity to try a 5-why root cause analysis in a sprint retrospective.

The 5-why analysis has its origins within Toyota and lean manufacturing and is used to find the root cause of a problem through identifying a symptom and then repeating the question “Why?” five times. General wisdom and experience state that the nature of a problem and its solution usually become clear after 5 iterations of asking “Why?”.

Here’s an example from wikipedia:

Problem: My car won’t start.

• Why? - The battery is dead.
• Why? - The alternator is not functioning.
• Why? - The alternator belt has broken.
• Why? - The alternator belt was well beyond its useful service life and has never been replaced.
• Why? - I have not been maintaining my car according to the recommended service schedule.

Solution: I will start maintaining my car according to the recommended service schedule.

The plan

I have found 5-why root cause analysis very useful in the past but had never tried it with a group of people or a software development team.

I “conspired” with our very talented Scrum Master and the plan was to share data from previous sprints, analyse the data as a team and see if we could identify a problem. If so, we would suggest a 5-why analysis to see whether it would point us towards a root cause and a solution.

The execution

1) We started by presenting velocity data:

The chart shows our planned (blue) and achieved (red) velocity over the last 10 sprints.

It became obvious that, during the last 4 sprints, we had consistently bitten off way more than we could chew. While it is generally a good thing to strive for what is just out of reach and to improve though practice we thought the gap between attempted goal and real achievement was too big. We certainly didn’t want to lose management’s trust by over-promising and under delivering.

Therefore, we decided to focus on this problem for the remainder of the retrospective.

The problem

The problem was easily summed up as “We over-promise and under-deliver”

The first why: Too many stories are almost done

We came up with two reasons for why we kept over-promising and under-delivering:

1. At the end of the sprint too many stories were “almost” but not entirely done (testing not finished, found a defect, etc)
2. Two of our team members had just gone from 50% to 100% and we overestimated the immediate benefit in terms of velocity

Much like in a decision tree we chose to pursue the path of being left with too many almost finished stories as the other reason was probably a one-off we could safely put into the “shit happens - we have learned” category.

The second why: We are running mini-waterfall

To find out why so many stories were almost but not entirely finished by the end of the sprint we had a look at last sprint’s burndown and cumulative flow diagrammes (I love those Rally reports).

The cumulative flow showed us that by day 4 most of our stories were in progress (yellow) but not many were actually completed (blue and green). Only 2 days before the end of the sprint the majority of stories were completed (blue) and then accepted by the product owner on the very last day (green).

This looked suspiciously like a mini-waterfall process where we first went though a development and then a testing phase.

The problem with any waterfall approach is that it forces feedback towards the end of the time box where it is hardest to react to. This is true for feedback on quality (through testing) and feedback on whether we have correctly understood the needs of our business and users.

The third why: We’re not doing tasks in parallel

We were then asking ourselves why we were running a mini-waterfall process inside a sprint.

Not only were we doing testing at the end but we also seemed to have a problem with co-ordinating GUI (Flex) and backend (web services) work. People found themselves waiting for someone else to finish a task before they were able to pick up the next task to finish the story. Often people decided to work on the next user story rather than wait for someone else to “unblock” them.

We decided we were simply not good enough at working on tasks in parallel to get one specific user story finished.

The forth why: No TDD, test automation and stubbing

People came up with several reasons why we weren’t working on tasks in parallel to get one story “over the line”:

1. Lack of communication
2. Only partial TDD, test automation and stubbing
3. Lack of collective responsibility
4. Not cross-functional enough

As we now had four possible paths to follow we briefly discussed each of them and then did a dot vote on which path to follow. The team decided on number 2: No TDD, test automation and stubbing.

The fifth why: We have an attitude problem

We really went into deep discussions about why we weren’t doing things that everyone knew were good and healthy and after another dot vote amongst several candidates we decided the most relevant root cause was that we had an attitude problem.

We knew what needed to be done, we knew that we needed to make it happen but somehow we hadn’t managed to just get it done yet. Probably because we hadn’t been fully aware of the consequences. We agreed to start fixing the problem immediately.

The solution

More specifically we all agreed to:

1. Ask for help when stuck
2. Accept help gracefully
3. Automate our regression testing (Flexmonkey/RiaTest), do TDD when possible
4. Make more use of stubbing and mocking to be able to develop the front and backend part of a story simultaneously
5. Hand over to the next person after finishing a task, i.e. don’t expect people to see progress from the task wall only; inform the rest of the team when e.g. the web service is finished or the story is ready for testing

My conclusion

Here’s the list of my personal takeaways and things I have learned:

• A 5-why root cause analysis can work amazingly well for a targeted retrospective.
• To avoid any danger of a 5-why retrospective turning into something like the Spanish inquisition it needs to be very well facilitated (Hallelujah for good Scrum Masters :-)
• A 5-why analysis with a group of people will produce a decision tree as there will be mostly more than one answer to each “Why?”.
• Voting to decide on which reason is the most relevant one and should be discussed works well and speeds things up.
• It made my day that I got the opportunity to try this ;-)

I wrote this to illustrate and examplify a retrospective technique that worked extremely well for our team. I think this was one of the best retrospectives I have ever participated in and I hope other people will give it a shot and share their experiences.

Tags: agile, retrospectives, mini-waterfall, root cause analysis, inspect & adapt, lean, kaizen