We are in a post Waterfall, post Agile world. So where does that leave us with our software and IT projects?

Agile started as a reaction to the Waterfall methodology. Waterfall said that software needed to be built from specification, tested to specification, released to specification. However Waterfall was always some kind of ideal which never truly existed. Likewise Agile is an ideal, a mixture of good practices and rules which have been spun into a theory of work. Neither of these ‘ways of working’ are hard and fast so why is so much time and energy spent debating the merits?

This amazing sketch from Samantha Laing after a talk by Jim Benson for me sums it up:

Poor Old Agile

Agile is certainly not a new way of working. It’s over 20 years old. The Agile Manifesto came about because frustrated developers, stakeholders and project managers said “we can do this better, we can work together better”. It was also a reaction to the perceived inefficiency of existing project management and software development methodologies. What we have 20 years later is exasperation from many stakeholders and product managers that they still can’t get what they needed built using Agile. Agile has spread to not only software development but how infrastructure, product discovery, and all sorts of other types of projects are implemented. The world that inspired Agile has moved on, but we’re still think it’s a good idea.

What do we need?

I’ve started to think recently that perhaps the fact that we think we need a methodology at all is actually over-complicating things.

I recently wrote the below comment on this excellent article:

The approach I’ve always tried to take with Agile is to sell it to developers as them being front and centre when it comes to running the project. This works for bullish devs who rate their ability and want to accomplish great things. For many who just see development as a paycheck there is no advantage or disadvantage to either method. What is more important is that everyone communicates better — rather than Agile vs Waterfall — build trust, communicate often, enjoy working together. Software projects shouldn’t be a grind so let’s work to not make them so.

Software projects shouldn’t be a grind. But why so often are they?

We start projects full of hope and ambition. We spend hours, days, weeks, months — no time is too long, no effort is too great, no money is too much. However the point of any project management methodology is to help validate ideas as we go, to reduce risk, to reduce uncertainty. Waterfall, Lean, Agile, MVP. All words that we recognise and understand but how often do we truly validate the ideas or the project we’re building?

In truth, everyone is too busy to validate. We trust it will work rather than planning to make it work.

Ideas have to be validated by people. Validation is a social contract.

The social barometer is the biggest indicator you have that your project is working. Checking everyone is ‘happy’ by taking a roll call or checking off a list is not really listening to your stakeholders.

So how do we ensure that our ideas are being built and delivered correctly?

We must make all stakeholders responsible for sharing the burden. And we do this with three simple things.

Trust, communication and alignment.

The three sides of the perfect project management triangle.

Trust — everyone in the project team from sponsor, stakeholders, project managers, testers, developers, infrastructure. Everyone must have trust and faith in the project and it must be demonstrated and felt by those taking part in it regularly. Where does trust come from? Transparency, professionalism, honesty, openness. No fear of hiding mistakes or blaming.

Communication — timing of communication, regular, open, explicit, clear. This works as much for internal communication as it does external. When stakeholders need to provide information to the project or are keen to show it off — they must show discipline and faith and trust in the project unless it’s agreed by everyone that the project isn’t working. This comes through…

Alignment — all parties in the project need to be aware of what’s happening in the project. A timeline, an agreed schedule of work, a prioritised backlog. Whatever you want to call it.

Essentially all of these three elements combine in providing us a continuous dialogue of the project. Keep it front of mind, in front of people, and make sure it completes on time, on budget and to the relief of everyone — it completes achieving everything you set out for it.

These three components — Trust, Communication, Alignment — are for me the most important parts of any design or project management philosophy. And you will find that they all find place in any methodology already existing.

These however emphasise the need for us to recognise our humanness in the process. We are not machines, we have emotions. Projects, even good ones, are always an emotional roller-coaster.

Recognise that humans need to be catered for in the process, prioritise this, and make sure above all you show Trust, you Communicate clearly and often and you provide Alignment. For details on how you do those things — see the details of your favourite project management philosophy.

After all, Agile says we should value People above Process, right?