When a software project starts, and we’ve put considerable effort into the planning tasks, we feel the project is under control. Or “in control”.
However, that’s fundamentally wrong.
I tried to come up with a way to describe how I understand control in software projects, to illustrate the need and applicability of the empirical management methods like #NoEstimates or Scrum.
Here’s my attempt at describing how control evolves in a SW project.
How control evolves over time in a Software project
We need to define one concept before we start: running, tested, and released software:
- Running: software that is running in a production, or production-like environment
- Tested: the software has been tested with an adversarial mindset, and the defined regression testing has been completed
- Released: a certain number of users has had the opportunity to run the software in their environment for a non-trivial amount of time, say 3-4 days for most consumer software, or 5-10 days for special application business software.
We also need to introduce a variable to help us “measure” (or quantify) the level of “control” we have on the software project: time since “release” (see above for the definition of release).
Alright now we are ready to explain how control evolves in a software project.
My assertion is that control in a software project is inversely, and exponentially proportional to the time since the last running-tested-release of the software.
Control in a software project is inversely, and exponentially proportional to the time since the last running-tested-release of the software.
–SoftwareDevelopmentToday.com
If f(x) is our control metric, then we can say that:
In a graph form this looks like the following:
In other words: in software, the control we have on a project drops very quickly with each day that passes since we had our software released and used by a real customer.
In software the control we have on a project drops very quickly with each day since we had our software released and used by a real customer.
–SoftwareDevelopmentToday.com
Understanding this dynamic allows us to define the following heuristics to running software projects:
- Structure the software project so that releases are happening in short cycles (say 15 days like a usual 2-week sprint, or every week if you are using Kanban)
- Build in processes that allow you to regularly expose the running-tested software to real customers (e.g. a tech-preview program, or Beta program)
- As far as possible automate the regression testing of your software so that you can apply the two heuristics above
One more thing….
I very often see the “traffic-light” reporting being used for project. If you happen to use that, then we should add two more heuristics:
- Every project should be considered red if 15 days or more have passed since the last running-tested-release happened
- Every project should be considered red if it has not yet completed its first running-tested-release
Although control is possible, we must accept that in a software project control is a fleeting and elusive state that disappears with the very first line of code written after a release. Hence why we must strive to build empirical control processes (like Scrum or #NoEstimates), instead of investing more and more into planning approaches that become obsolete the very next day.
Planning may be useful, but it becomes obsolete the very next day. Use empirical methods like #NoEstimates and #Scrum instead!
–SoftwareDevelopmentToday.com
