The BEST project management structure
Are we talking about Waterfall, Agile, Scrum, Kanban, Extreme Programming, Prince 2…?
Everyone has their favourite methodology, and everyone usually hates all the others.
We're reminded of it every time we see the “Software Development explained with Cars” infographic (By Mart Virkus) that goes around the internet every few months.
It shows four of the most popular project management frameworks as if they were a car manufacturer.
OPC was recently working on a very large Drupal project, and we were officially running Scrum.
Because a project management structure is like a battle plan, and a battle plan never survived past the first contact with the enemy, over the life of the project we ended up doing just about all of them.
With all the best intentions we had weekly scrum meetings where everyone briefed what they were working on, and what blockers they had.
SCRUM and KANBAN are two popular methods for
organising workavoiding chaos
But, with ever changing requirements (because business areas have so many internal hoops that they need to jump through, the original document is never the same as the final) it meant that half way through a sprint the choice was:
- do we keep working on something that will be correct to the documentation when we started, but not with the actual finished requirement,
- stop working on the task entirely now that something has changed and start it again as a new item next sprint,
- modify what we were working on to provide the correct outcome
Of course, the answer was the third option. Because we were on a very strict timeline, and we didn’t have time to intentionally make something incorrect, or to throw out work and start again.
Some entire sections of the project morphed from Agile to Lean like some sort of project management Transformer, so that they were able to deliver a minimal viable product in order to meet an arbitrary deadline set by the business area.
In the end, we started our own project management technique called JGID*.
JUST. GET. IT. DONE.
The final product needs a reset password functionality, but there isn’t a user story for it yet? Just get it done.
There is a demo happening in half an hour but despite your best efforts, a rouge comma got through into the UAT environment crashing half the system… should we wait for next sprint… no… Just get it done.
You are scheduled for a five hour meeting to discuss the velocity of the next sprint based on a retro-active deep dive on each of the components developed in the last sprint. Skip it, and just get it done.
Because in the end what is more important?
That you rigidly stuck to the project management methodology, or that you finished the project on time and on budget.
* Certification in JGID can be obtained by skipping one useless meeting and spending that time working.