Releasing software on time is a choice!
Software is in most cases not an enabler for your business but a foundation. Often the software is where you can/must differentiate from your competitors. The right choices (process & features) can accelerate your business. Many organizations / managers see SW development as a discipline no different from electrical or mechanical engineering, resulting in unconscious decisions which negatively effects the SW development. I once promised a CEO 3 things: The software would be too late, too expensive, and too many bugs. After a couple of years, we received a complaint: software development was too fast!
An unconsciously organization: When executing a project, you have 3 variables: time, specification (features), and resources. (I prefer to use 5: time, specification & quality, resources& money). And at least one of those variables must be flexible.
In most projects all variables are frozen. Typically, time, specification and resources are fixed. As time progresses, problems and changes will occur (we cannot reduce the specification, and you cannot get more resources) and as a consequence quality will reduce and additional time will be needed resulting in a delay of the release. In many organizations, this trade-off is made unconsciously and time and quality ”accepted” flexible.
A different approach
I’m convinced it is possible to make the conscious decision to have software be delivered on time. As resources & money will not be flexible and you don’t want quality to degrade (explained later how this affects your efficiency), the specification must be flexible!
How did we solve this? By adopting the agile principles. We moved to 2-week sprints with a product owner who could take decisions, conducted regular customer tests, etc. We decided to go for a 6-month release cycle (2 SW versions, so a release cycle every three months).
At the start of the project (6 month cycle), marketing needed to have a vision of the product that would be brought to the market. Together, we defined “must-have features”. But here, the limitation was that those features could not require more than 60% of the resources (after e.g. planning poker). The remaining 40% could be used to handle underestimations in the “must have features”, create some room for additional features (small improvements) and resolving unexpected hick ups. This way we were able to deliver the promised features in time.
Successful multi-site development.
Multi-site and quality was another issue to solve. We had 10+ sites in 5 time zones with many agile teams working in the same code base. Note: all agile teams where synchronized and working with a 2-week sprint. Agile customer testing required any team could deliver a test version to a customer at the end of a sprint. This all required a very stable code base. How to address this?
- We had a continuous (automated) testing with live dashboards with real time monitoring
- A feature was “done” after being tested by SQA, bugs were fixed and signed off by the Product Owner.
- A very clear bug definition with priorities was used: “bugs which required a team to drop their work and fix the bug (regardless time zone, team, ..)”. Any bug which had to be fixed before the release, had to be fixed within 30 days of discovery, etc.
- There were 2 important related KPI’s. Aging of bugs: “Bugs should not be older than 30 days” and “bugs reported back from the field (did we deliver quality?)”.
All of this resulted in on-time (faster than expected) software delivery.
Note: there are more boundary conditions e.g. architecture required, but those are beyond this article.
Efficiency improvement.
There was a second advantage. Efficiency of the software team increased. Why? Other factors aside, there were two main underlying reasons (more but those are easy do explain):
- Bugs found by SQA needed limited documentation as the bug would be fixed within 30 days and the SQA engineer probably could still easily reproduce the bug. Also, the SW engineer who’s code introduced the bug still would know the code very well (why did he do it this way), resulting in faster fixing with limited need to re-write
- Bugs coming back from the field had to be fixed in roughly 90-days. So any bug to be fixed with a hot fix would interrupt current development. But with a known release date, only the bugs found in the first 3 months had to be fixed as a hot fix. Most of the others could be fixed in the regular release (less testing, less versions, etc). So less interruption of the team flow and process.
Conclusion Releasing software on time is a choice.
- It is possible to go to a fixed release timing (SW release on time), but this requires company wide acceptance / commitment.
- The 60% for “must have features” was critical to be able to resolve unexpected hick ups.
- A high quality code base was required for conducting customer tests but also resulted in a higher efficiency for SW development.
- KPI’s and dashboards supported a clear explainable process without emotions (regardless of culture).
- Creating a high performance team culture by empowering the team members (see also whitepaper High Performance Teams).
Releasing Software On Time is a Choice ’ by Corné van Sommeren
‘Building Strategy and translating same into organisational reality is a strength I would like to share with you’
Chief on Demand – Triceps Innovation & Technology
About Triceps
Triceps helps you achieve your goals. Thanks to our matching and coaching, you as a senior executive will switch to the next gear. At which management table do you really come to fruition? Or are you already at the right table and want to increase your effectiveness and creativity with support? With attention and strategic insight, Triceps gets you moving, both as human and as professional.
