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.

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 Scrum any time!

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

Tags: agile organisations, organisations, governance, obstacles , showstopper

I was recently asked by a friend how to pick a Scrum team.

My friend is a project manager within a New Zealand government department and to deliver an important project he was given complete freedom of choice with regards to project methodology and people.

He chose Scrum as a delivery framework and needed 8 people to form his dream team. The big question was which people to pick and which skills to focus on.

I've never been fortunate enough to pick my own scrum team. Normally, I get a certain degree of choice and then a combination of who happens to be available and people who I really, really fight for. And sometimes I fight to avoid getting someone on the team. 

Having complete freedom I think I'd focus on: 

1. Personality and work attitude - people who are solution oriented, like to deliver, like to succeed, are easy to work with, can communicate and just get the job done
2. People who like each other or have a chance of getting along, i.e. have respect for each other and can have fun together 
3. Absolutely no primadonnas: We can all be flexible and accommodate a lot but the lone genius who lives by his own rules just does not work (I usually remove them and I have never regretted it)
4. People who are confident enough to handle the visibility and transparency that come with Scrum

Sure, people should be qualified and good at what they do but it is much easier to teach people skills than to perform personality transplants. 

Tags: agile, team, personality, transparency, visibility