Process is a highly emotive topic, there are one set of extremists that believe that everything needs a process and even if you claim there isn’t one – actually if you look hard enough there is, and one the other side there are those that suggest that all process is evil and a waste of time.
Typically in these frothing debates the truth lies somewhere in the middle.
When you get down to the real ethos about Agile delivery it is a bunch of people getting down to do what is necessary to make a genuine improvement to a situation, reassessing their situation and then repeating.
Stripped bare and free of politics there are no requirements, no roles, no reporting, just people doing stuff. This works brilliantly in the teeny start up world, can you imagine documenting your first requirement when starting your own company, or allocating roles between 3 people as to who will do what? no of course not, everyone will do what is necessary, as well as they can, asking help when they need it.
So why doesn’t this scale? Even a single-team Scrum implementation brings a role, (Scrum Master) and definitions like User Story and Sprint and Velocity. What has happened?
Well critically the people doing the work are typically one step away from the passion of delivery, the real success criteria – the PURPOSE. Now we need to consistently communicate to a wide audience what is going on.
In a start up – the consequence of failure is so great that you’ll do whatever it takes to get over the line and don’t need to justify your self to anyone; at the other end of the spectrum with a heavily controlled PRINCE2 type environment it is entirely possible for an individual to do everything they are supposed to and deliver no value on a failing project.
As things continue to scale more process starts to creep in, this is usually as a consequence of lack of relationships, lack of a true, trusted connection. Process is a consequence of a problem – and not always the right solution. We need to acknowledge that the process is an inferior replacement to a trusted, close relationship and should be introduced only to the point where the people concerned are able to operate almost as well as they would in the context where it wasn’t needed. The process is not to be aspired to, it is the necessary evil. It is what you do when you can’t get people to work together due to location or contract or politics or possibly just personality
Process is a pollutant to your system – only introduce that which you truly need.
So how much do you need?
There really is only one way to find out, start with none and introduce process until you find things start to work and then ceaselessly attempt to remove it as people work together for longer. Generally each step you take will make the situation better and this lean (both in process and headcount) approach will be cost effective.
The alternative is the PRINCE2 or SAFe approach which starts with a HUGE pile of process, roles, terminology, gates, documentation etc and suggests that within it are all the pieces you need. If you are unsure exactly which bits you need in your entirely unique situation both in terms of context and people, then just apply everything. Once you have everything then you can start to remove bits.
But that is the difficult part, which bit to remove? The consequence of change when operating this way is the reverse, change the wrong bit and you move from a ponderous expensive working system to a broken one. Also the people likely to be tasked with deciding which process to remove are part of the process, and one thing I have learnt is that it is rare for someone to suggest that they are the problem.
Removing process is especially difficult to justify in a client supplier relationship. Process is expensive because it requires a lot people to manage all the people that are managing all the process artefacts that manages the work that the remaining individuals are actually doing. But once you have set the precedent to the client that that approach is necessary, being able to later remove people and artefacts with no impact on performance is awkward and embarrassing – it also negatively impacts revenue – easier to just continue on with the client losing but being ignorant of doing so. Savvy clients will challenge the initial setup but there are many that are not, and it is in the best interest of the big consultancies to keep it that way.
Identifying the processes and tools you need should be something mutually agreed by the team – the whole team, and then continually reassessed. If the team has requested something then they are far more likely to abide by / use it. Externally pushing something on the team will be resented and resisted – which typically results in the introduction of someone to enforce it and you can see the bureaucracy mount… you will be owned by your process!
This is why we have retrospectives, to assess the approach and change it, where retros are not productive is when you have lots of externally enforced processes that can’t be changed. What is the point about discussing something you can’t change – if you can’t adapt why bother inspecting? Before long you are back in the world of a disempowered, disinterested team burdened by bureaucracy.
So, free yourselves, cast off your process and then look at all the little pieces on the floor. Now pick up the bare minimum and see how you get on.