Divide et Impera!
Divide and conquer! : in politics and sociology, it is a strategy of gaining and maintaining power by breaking up larger concentrations of power into pieces that individually have less power than the one implementing the strategy. wikipedia
Basically, split the forces of your enemy into smaller groups or individuals, which are easier to control and defeat.
Wait, what has that to do with project management in software engineering?
Do I mean to isolate and weaken the individual team members so that they can be easily ruled, sorry, managed, and that the goals can be achieved without any form of dissent?
Of course, not!
But how could I achieve the goal that was assigned to the team I was working with - 20 developers, more than 1 million lines of code, more than 15 thousand errors, hundreds of features to be rewritten - if not with Divide and Conquer!?
Software development is the act of breaking a complex problem down into smaller problems and composing simple solutions to form a complete solution to the complex problem.
This is actually true for any big task, it helps if you break the task down into smaller, more manageable parts. Little piece by little piece, the big task is less intimidating.
“How do you eat an elephant?"
“Easy — One bite at a time”
So what did we do in practice?
we individuated 4 macro-areas of intervention within the project/codebase.
we split the team of 20 + people into 4 squads who could focus on one of these 4 macro areas independently - almost.
we run an analysis on features and errors, aggregated them, and then split them into categories that were assigned to the different squads and individual members who were in charge of that category.
we made iterations more frequent. instead of monthly deadlines, we were reassessing our status weekly ( at the beginning we did not even have anything “showable” if not that the number of bugs (defects) and errors was decreasing…) and eventually, re-adjust course.
Not everything though could be broken down in smaller bits, nor was it advisable.
Where did we not divide instead?
Decision making: devs can be solitary animals: but we didn’t want to have a developer working on his task alone, just to realise after days or weeks the solution was wrong or did not fit the big picture. So, we had iterative coding design sessions to discuss solutions collectively ( within the small groups though).
Knowledge sharing: weekly present some interesting solutions or learnings to other team members.
We dismantled Silos and Towers of Knowledge: especially with this high churn rate - we could not afford to have someone be the only one responsible for doing things or knowing how to do certain things.Helping each other: devs are stubborn and like challenges - but we could not afford people being stuck for hours, or days on a problem - so we enforced “asking for help, or seeking people in need” 30 minutes of struggle → shout it out to the team: maybe someone already went through a similar problem and already has a solution.
In the end, by combining an atomic and aggressive approach to the problem with a mutualistic approach to the people, we were able to reduce the scope and increase productivity.
By working on a smaller scope, we could ignore the rest.
By avoiding distractions we could improve focus
By having a shorter feedback loop - "Do something, Make sure it is ok, Rework or Move onto the next task" - we improved our speed
By sharing the struggles, celebrating the progress, sharing knowledge, and showing help to each other, we fought frustration, insecurity and a sense of impotence in front of a massive task.
And in the end, despite all my predictions, we made it.
As Francis of Assisi said:
Start by doing what’s necessary; then do what’s possible, and suddenly you are doing the impossible.
This is the transcript of a speech I gave at my local Toastmasters Club (an international organization to practice public speaking and leadership skills) for Level 4 of my Innovative Planning Pathways where I had to write and present a speech about my experience in a project.
You can consider it a fictional story, although a lot of what is described there comes from my direct experience.
I hope you find it interesting and of some help.
Top comments (0)