Project über management. What is too much or not enough?
Today, every company is already agile or has adopted agile. Still, there is a reality that many software projects fail.
Projects can and will fail
Failing a software project can mean many things.
-
The budget was not met
-
The quality was not met
-
The time was not met
-
The scope or goals was not met
-
The customer was not happy
Software projects always go differently than planned. Does that make you nervous?
Have you ever built a house? Did it go as planned? Very likely not, and this does not necessarily mean a problem. You have some margins planned in, and you have some buffer. Or you have an insurance.
The question is: How much can a project fail and still be successful?
Software is eating the world
In 2011, Marc Andreessen wrote an article about Why Software Is Eating the World. Now, more than ten years later, we still see some companies struggle learning doing software development.
It seems there are two categories of companies. Those who are software companies and those who are not. Software companies only produce software. They have no other business model. They had to figure it out, or they went out of business. No big issues.
Drama might play out when non-software companies must transition to software companies.
Non-traditional software companies, an example
Just the other day I found an interesting two-minutes video on LinkedIn of Ford Motor Company’s CEO Jim Farley about Fords troubles in learning how to do software.
Ford is a company that has their roots not in software development. They will have to figure it out or change the business model. Maybe become a patent troll or find some niche, like, mechanical only cars for vintage fans.
Not too long ago, software was a tiny part of a car. Today, it is a significant part. Probably the most expensive part and also the most important part. This maps also to other industries. Software is eating the world.
The difficulties of management software development projects
Peter Drucker described the concept of knowledge workers more than 50 years ago. Developers are one of the purest forms of knowledge workers.
We have developers traveling the world with their notebooks who are productive and earning a living. How do you want to manage them?
Books have been written about this topic, and I will not repeat them here.
I focus on a TL;DR version: There are no golden rules. Sorry. But some things are essential.
And the most important one is very likely: Keep it simple because complexity kills. If you want to keep it simple, do not über manage your software projects. And Respect Conway’s law.
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure
For software development, that can mean you need to ask yourself a question:
What is the ratio of non-developers to developers in your software project?
How many managers, project owners, scrum master and other people managing the process are involved and what is the number of developers, ui-designer, testers, etc.
There is of course no golden ratio. The world of software is too diverse. But by creating a number, there is a baseline to start thinking. Is the current ratio good for the development production line by also respecting Conway’s law.
Too high a ratio means the danger of producing just enough processes for the sake of process and keeping management busy. Too ow a ratio means that the developers are in danger of being unable to focus on the task, have no clear structure and spend too much time in finding out what to do.
Both scenarios might create too much complexity since they influence the communication structure. Start by creating a number.
For personal reasons and at the moment, I find the number 24 interesting. It is the number of hours in a day, and just a flipe away from 42 ;-).
It seems to be a nice number to create lagom (just enough) teams that one PO and one scrum master can efficiently manage to realize some projects.
But your milage may vary.