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

Last week I presented at WebDU in Sydney. The conference was excellently organised by Geoff and the Daemon guys and I met lots of interesting people. And I love Sydney! In short I had a blast.

Apart from a workshop on user stories I presented on 10 ways to fail with Agile. Judging by the Twitter stream my presentation about the most common mistakes and pitfalls during Agile adoption and how to avoid them has been well received (okay, they also tweeted I looked like Starbuck in Battlestar Galactica Season 1 ;-)

As promised here is a version of my slides which more than just pretty pictures ...

10 ways to fail with Agile on Prezi

Tags: organisations, agile, failure, inspect & adapt, adoption, transition, scrum

To get our code to production what is left to do is to turn the "potentially" releasable product into a releasable product. To do this a number of activities are required: Which ones and how much effort they require varies greatly between types of organisation.

The fastest way to perform rollout activities is to do them within the development team and to automate as much of the process as possible. While I envy and respect teams that are mature in terms of test and deployment automation and operate in an organisational context that allows them to easily move code from environment to environment I find that this is very often not possible within larger organisations.

Often, among other activities, someone outside the team has to be instructed as to how to deploy code, other parts of the organisation have to be informed about the changes (eg. end users, operations and maintenance teams, etc), and manual regression testing has to be performed.

For the kind of large organisations Mike Cohn refers to in his description of a bank with COBOL code and no automated regression testing or large organisations new to Scrum and Agile I, too, find this is best done within a so-called release sprint.

What is in the release sprint?

Projects I have worked on and organisations I have coached usually included two types of work in their release sprints:

• Work that couldn’t be performed every sprint because it was too time-consuming and/or expensive (e.g stress testing, full regression testing, getting copy text translated)
• Work that is only needed when releasing to production (e.g. bundle software, send out release notes to ops team, send comms package to change management, move code through various environments)

What is a successful release sprint like?

The following was common for successful release sprints across all projects and organisations:  

• Independent of how much functionality we had developed and how "big" the release was the release sprint was always the same length (e.g. always 2 weeks).
• Everyone on the team had a 100% focus on getting the release out of the door. 
• We never developed any new functionality during the release sprint.
• Although sometimes unpredictable we made use of the task board and tracked our work with a burn-down.

• Sometimes, on larger teams (8-9 people), we were only a subset of the original development team but most of the team stayed on to help. (People who didn't work on the project did other work for the organisation such as e.g. R&D, "business planning", etc but that was not a project issue)

What are your experiences?

Tags: organisations, transition, agile

There’s a saying in software development “If someone gets hit by the red bus ... “ which roughly translates to that if you lose a project team member or two you still want to be able to get the work done and finish the project.

Normally, red busses are rare: The realistic worst case scenario is one or two team members out with the flu or someone quitting their job. A good team can normally recover from such disruptions.

But red busses can be bigger and more damaging and wipe out large parts of a team: This usually happens if a new CEO, new management or a new government revokes funding, recession hits or an organisation just plain runs out of money.

In this case one of two things normally happen:

1. The project goes on with fewer team members
2. The project gets canned or put on hold

Waterfall
This is bad news for everyone but has a devastating effect if your project runs any flavour of the waterfall methodology:

Fewer team members:
Going on with fewer team members will not just result in major delays but will risk the success of the entire project.

Job roles in waterfall projects and organisations are highly siloed, i.e. testers test, developers code and a business analysts deal with requirements. A team losing several members will not just work at a lower capacity but some work simply cannot be done: If a project for example loses its testers testing will not be performed and the project comes to a grinding halt.

Canning the project:
Stopping the project has even more devastating effects and most likely the entire investment in the project is lost.

Waterfall methodologies use a phased approach: Requirements gathering, Design, Build, Testing and Deployment. Depending on which phase the project gets stuck in an organisation might end up having paid millions for a functional specification, technical design or developed but not yet tested software. All work on a product that cannot be rolled-out and used and that might never see the light of day.

If a waterfall project is stopped before the final phase the product cannot be used and the return on the (often considerable) investment is zero.

Agile
For an Agile project loss or reduction of funding can be bad news too but the risk when using an Agile methodology such as Scrum or XP, if implemented properly, is contained and the investment will not have gone entirely down the drain:

Fewer team members:
Going on with fewer team members will reduce a team’s capacity but as the responsibility and accountabililty for delivery lies within the entire team rather than individual job roles an Agile team can usually keep on delivering.

Agile teams organise around generalising specialists where people have both a primary and several secondary job roles and if one or more specialists have to leave the team other team members will take on their work. If an Agile team for example loses its testers the team’s business analysts, developers, scrum masters/project managers etc will share the workload and ensure that the software is tested and working properly.

Even at a slower pace the team will produce software that can be rolled out to end users.

Canning the project:
If the project is stopped or put on hold the damage is limited. Agile teams develop software incrementally and the primary measure of success is working software. Every 2-4 weeks (dependent on iteration length) the team delivers fully functional software, i.e. software that is fully designed, built and tested.

The basic rule to implement high priority features first ensures that, if the project is stopped, the most important pieces of functionality have been fully developed.

Unlike in a waterfall project project sponsors will never be left with just a functional specification, pieces of documentation or untested software. You might not get everything you initially wanted or set out to build but everything that has been worked on is fully functional and ready to provide value to the business and/or end users.

Real Life
Loss of funding and team members is what has happened after a change of government at my (now former :-) workplace, a New Zealand government entity.

My Agile (Scrum) project has already produced working and usable software in an incremental fashion. Even if it should get stopped we have delivered business value and a good return on investment.

In this case the organisation’s choice of running Agile has put them ahead of their peers.

The waterfall projects? I wish them the best of luck - they’ll need it.

Tags: organisations, agile, risk

People keep asking me whether I’d run all projects using an agile framework such as Scrum.

When I answer “of course not” they often not only expect but gently try to steer me towards an answer that excludes certain type of projects: “You certainly wouldn’t use it for a mission critical system, would you? Or a compliance project? Or an infrastructure project? “

Actually, yes! I have used Scrum for business critical systems at a major mobile phone manufacturer, have implemented mission critical systems for a publicly owned European Rail Cargo company, a friend of mine has successfully delivered a compliance project and another one has even developed fighter jet control systems for a European Air Force using scrum.

It’s not about the type of project. It’s not even about the size of your project. It’s about whether you’re willing and able to create a setup that allows agile projects to succeed. To me the rather vague terms of organisational and cultural readiness can be narrowed down to a list of primary show stoppers:

I’d NOT run agile if ...

• People on the team are not fully allocated and committed to the project
• You can’t stack a great team and only get the people that everybody else wants to get rid of (Give me some of the company “stars” even if it’s just to show commitment and get me agile personalities!)
• You don’t have the courage to let the team make decisions, to allow them to learn by making mistakes and to trust them to get the job done - you’re stuck in command control
• You don’t have a business person who has the time, courage and authority to work with the team and to make quick decisions
• You expect instant success and need a silver bullet (Sorry to be the one to bring it to you but if your project is impossible or if you don’t have good people no methodology or framework is going to help you ;-)

There are of course numerous other things that are important for agile teams to succeed but usually there are work-arounds for non-ideal situations.

If I don’t meet any of the above obstacles I’ll go for Agile any time!

What’s your list of show stoppers or essential requirements for running an agile project?

Tags: organisations, governance, obstacles , change, agile, scrum