Projects are actively harming your products

There are many things that can cause a software project to fail. I suspect we’ve all experienced a failed project at some time or another. The users didn’t like it, it was over budget, it was the wrong thing, it was late, it was buggy, it got cancelled – the list is often endless. But there is one common factor, the project itself. By project I mean a temporary team formed to work together to complete a batch of work.

What’s so wrong with projects?

Projects by their very nature are the antithesis of software development. Software is an evolving and flexible medium. It doesn’t have a fixed end state. There are no pieces of software (or websites for that matter) I use today that didn’t exist in another form in the past. The software and the sites evolved and changed based on new technologies, shifts in the market and customer feedback. This is the very definition of software development. However, when we come to structuring the work of software development, we usually use a project model. A project infers a start and an end. A point that when we reach it, means the project is complete – we can pack up our tools and walk away. When we undertake a software project we draw an artificial line in the sand (usually based on some inaccurate estimates) and pretend that the project will end.

This artificial end point leads to thinking in terms of big releases. The reason we tend to think in terms of big bang releases with projects is that when the project ends we assume that we will no longer be able to deliver any more value. We therefore need to ensure we have as much jammed into the project as possible, because when the project finishes we won’t have a chance to add anything that’s missing. Couple that with the knowledge that our team is likely to be disbanded at the end of the project and we have a situation where we have to ensure as much as possible is delivered for fear of missing an opportunity, forcing us to into a big bang release just because we used the project model.

The waste of project teams

When we incept a project we’ll build a new team from the remnants of the last project team, or we might co-opt some departments together to form an ad-hoc team. This new team will dutifully plough into the new project, slowly learning how to become more effective.

This is a known phenomena described in Tuckman’s stages of group development:  Forming – Storming – Norming – Performing

Working in projects is counter to this dynamic and means that just as we get to the performing stage we take a pickaxe to the team and break it apart, often loosing much of the social capital and working practices that have been built up.

Build capabilities not projects

So what’s the answer? If projects are actually damaging to how we build software what can we do instead?

I’d suggest that we begin to think in terms of building capability to deliver ongoing software improvements – rather than building pre-defined projects. What I mean by this is evolving an environment where we think in terms of continuous delivery of value rather than working on large chunks of value in a project model.

A project is a great big chunk of value, where the value is not realised until the end. This is very risky as any delays will delay the whole set of value. If we break down the project into a continuous stream of smaller chunks of value we spread that risk out. We also allow for course corrections in case we discover something new or the market changes underneath us.

To do this we’ll need to look at how we form and keep teams together. We’ll also need to look at how the work gets to the team and how this work is broken down so that it delivers value in smaller chunks.

In addition we’ll also need to look at how we release software. As without the ability to release small chunks of software we’re doomed to always work in projects, because how we deliver the value dictates the model for creating the value in the first place.

Less projects less estimation

Another benefit to moving away from projects is an intrinsic reduction in the amount of estimation we do. In fact you might even get to the point where you can eliminate estimation altogether. Let’s imagine a big project to rebuild a website, re-write all the copy and migrate it to a new CMS platform. There’s a ton of risk here. The normal business strategy is to estimate and plan in order to work out what might happen so we can understand and mitigate the risk.

However, we can never know exactly what is going to happen and we’re estimating at the point of least information. Which means the moment we start executing the project we’ll find that our estimates are wrong and we’ll have wasted the time we spent estimating. Also, by the time we realise our estimates are wrong they’ll have become commitments. At this point the whole management and reporting model for the project becomes a fig leaf covering the truth of the situation. Not only that we’ve probably got a newly formed team (usually with external experts) that’s learning how to work with one another – so the chances of the estimates ever being right was likely negligible.

Instead imagine the same scenario where we have a stable team, a process optimised for the continuous flow of value and a mindset whereby we look to break the project down into manageable chunks of value.

Now instead of estimating we can decide on the smallest chunk that will deliver value to start with. That’s our risk exposure – the cost of the team for that short period. Then we can see how much is delivered and use real data to do future forecasts on when the rest of the value will be delivered based on that data. Or we can have a phased release of funds for the work. Deliver the first chunk of value, then based on the value delivered get funding for the next chunk. In the phased funding model we don’t even need to estimate, we just get on with the work at hand. I’ve talked about this kind of approach before in my go/no go blog post.

Time to move beyond projects

This has been a fairly quick overview of why I think projects are a bad idea and why I think we should be looking for solutions outside of the traditional project model. This non-project future is not dependant on any particular methodology and you can start thinking about how this might work for you even if you’re not doing Agile. This is just a call to start the debate within your organisation. Are projects the best way we can organise the work? Are projects the best way for us to deliver value to our customers? It may be in some instances they are but I ask you to consider the alternatives and to run some experiments.

Comments welcome as always.

Inspiration, references and further reading:

A recommended Agile reading list

The following books are the ones I have found most influential and useful in my Agile journey. I recommend them as essential reading for anyone working in or with Agile teams.

These books will help both managers and teams shift to a more Agile mindset. They also help frame why focusing on things like “Flow” over “Resource efficiency” will get you better results than just following practices blindly. Lots of them have practical advice for how to implement Agile or improving Agile practices and give you some of the theory behind the practice.

My Agile library

What books have you found useful/influential? Let me know in the comments!

P.S. Here’s the list of the books in the pic (with Amazon links, should you want to buy them):

  1. This is Lean: Resolving the Efficiency Paradox
  2. Implementing Beyond Budgeting: Unlocking the Performance Potential
  3. Kanban
  4. User Story Mapping: Discover the Whole Story, Build the Right Product
  5. Kanban from the Inside
  6. Scrum and XP from the Trenches (Enterprise Software Development)
  7. Succeeding with Agile: Software Development Using Scrum (Addison-Wesley Signature)
  8. Lean from the Trenches: Managing Large-Scale Projects with Kanban
  9. Agile Retrospectives: Making Good Teams Great (Pragmatic Programmers)

Are your clients eroding your culture?

I’ve been reading quite a bit about encouraging or growing certain types of culture in organisations. Cultures which promote continuous improvement or fostering greater empowerment with the organisation. However it seems that one vital facet of the culture of your organisation is always omitted. That of your clients (I’m speaking from an agency perspective here, although this may also be applicable in other contexts).

Much of what is written about changing working cultures is about the internal world of the organisation, but this is only one facet of what makes an organisation. An organisation is made up of many complex interactions and at these points of interaction is where culture appears. For example: how we behave to one another and the shorthands we use. These unthinking actions are the cultural life of the organisation.

Our clients are another cultural interaction point. The way they interact with us can have amplifying or cooling effects on the cultures we are trying to grow. We should pay attention to how a client behaviour may permeate down into our organisation as this behaviour may erode the work we are doing to embed certain values. For instance trust and transparency. Perhaps the client embraces our new way of thinking and reinforces our work culture. Or perhaps more likely they are mystified as we begin to talk in a language alien to them and reject our new behaviours.

So when we look to our organisation in terms of a culture change, or new values we want to adopt, perhaps we should spend some time thinking about how this will effect our clients. Work out strategies for bringing them on the journey with us, or even no longer working with clients that hold us back from our wider goals.

Our organisational growth (wether we like it or not) is subject to factors both within and outside of our control. We should therefore attempt to ensure that the direction of growth is towards the light and is not stunted by unwelcome or unperceived factors.