How to Approach Software Process Improvement
In the first part of this two-part blog series, I talked about why I care about software process improvement. If you haven’t already read it, you can do so here. Now, we’ll talk about the phases you’ll go through when putting your software process improvements in place.
Phase 0: Before We Start
Take Ownership
I always try to complete my homework first. Simply said, the basic prerequisites should be fulfilled before I proceed. To start with, I do my best to perform in my current role with the tasks I’m assigned, while any improvements are considered something extra. Secondly, taking ownership is necessary. If the team needs to narrow the Maven repository configuration, looking for experts is usually not the fastest way. We probably need to gain a reasonable level of expertise quickly enough to be able to change anything soon.
Quantifying the Costs
I also try to do at least some basic calculations around whether the effort will pay off. Probably the first question your boss will ask you is “How much will it cost? How many man-days will you need? “ The bad news is that saving money in the long term will cost you something upfront. But being able to quantify the costs and benefits can give you the right advantage and convince your boss.
We considered purchasing the licenses of IntelliJ Idea Ultimate for our full-stack development team. The team wanted to leverage the embedded application server with its hot-swap functionality. This would speed up the three-minute build and redeploy turn-around.
Doing this 10 times per day wastes 30 minutes every day. Multiply it by 150 to get the impact in one year. The license price per day was about three dollars. Was saving 30 minutes of the programmer’s productivity worth it? Absolutely. Was the work comfort and satisfaction worth the price? Of course (although no calculation can be used to justify it).
Is it always possible to quantify the benefits? No. How many man-days or bugs do we save when introducing static code analysis, fostering a code review process, improving the quality of the project documentation, and involving an agile approach? In such cases, relying on the industry’s best practices and trusting common sense are the only weapons we have.
Diplomacy
Last but not least, in today’s complex development environments and projects — and big teams working within them — we would barely leave any track if we played the game alone. I always make sure I have the support of my team, the project manager, and the customer … Sooner or later, I will ask them for help, a time slot in the release schedule, paying for licenses, extra CPUs in the testing environment, backup server, consultations, or more importantly, for changing their mindset.
I listen and engage in informal small talks in the kitchenette over coffee, and joint lunches, trying to absorb the whole story, spreading the word, and slowly buying my colleagues in. Then, at the team meeting, when folks hear me talking for the third time about that urgent change, it’s no surprise for them anymore and a couple of heads may even nod.
Phase 1: Observing and Understanding the Project
What helps me identify the most neglected areas and most severe bottlenecks is the understanding of the big picture. Otherwise, any change would be just a guess with a random result. I need to understand all the puzzles of the development process. Who does what and why?
Prioritize. If you gathered many observations, select the most serious insufficiencies solvable in a reasonable amount of time with minimal resources, while bringing the most appreciable effect. Such a quick win can buy you the trust of management or your team for your next bigger challenges. I personally use a good old Excel sheet with the following columns: severity, difficulty, area, current state, consequences if not solved, proposed solution, assignee, dependencies, and effort estimate.
Example
Severity: High
Difficulty: Medium
Area: Testing
Current state
- Qualification testing takes place in the very last week at the end of the development period and is often not completed in full.
- The process is not systematically planned (resources, time, quality, scope), repeatable, and controllable.
Consequences
- Degraded quality, a high number of errors
- Team leaders are overwhelmed with bugs from production and they don’t have enough time for improving the quality of the development process itself and managing their teams properly
Proposed solution
- Implement test methodology/strategy and test plan
- Collect metrics from the development, testing, and production
- Introduce continuous (dry-run) testing of all new features
- Hire more testers
- Prolong the qualification testing period by one week
- Implement automated end-to-end tests
Assignee: Test lead, Delivery manager
Dependencies: Make the developers responsible for the quality of the developed features
Effort estimate
- 2MD test strategy and plan (one-time)
- 1MD collecting metrics (each release)
- 50MD one additional tester doing the dry-run testing (each release)
- 40MD prolonged QT
Benefits
- 50% fewer production bugs
- 30 MD less production support
- Predictable qualification testing
- Predictable production quality
- Improved customer satisfaction, lower customer churn, and higher annual revenue
Phase 2: Planning
You can see your improvement as a regular project. Usually, it needs a justifiable business case, clear scope (who should do what, when, and how), resources, time (possibly split into several phases or milestones), and a rollout of your project. Having a plan significantly improves the transparency and manageability of the whole activity.
Phase 3: Rollout
The final day has come and the shiny rocket is ready to be launched. However, for risky or big changes, I tend to progress gradually in small steps. For instance, we enabled the SonarQube pull-request analysis in one team only. Once the expected behavior was verified and Jenkins resources monitoring didn’t show any extremes, we enabled the analysis for the rest of the teams as well.
Similarly, having a rollback option, a plan B, will buy you a good night’s sleep. In the case of Git migration, we had a backup server ready. Even if everything goes smoothly, I always like to communicate all changes in advance and provide aftercare support to resolve potential issues, assist others, and answer any questions.
Conclusion
Let me summarize what we found useful and what helped us make some of the improvements possible.
- Start the observation right after joining the team/company before you get used to overlooking all the shortcomings.
- Every project is unique. Technology comes and goes,. but the principles remain and are worth getting right from the start.
- The entire development process deserves your attention, not just the implementation and code.
- Ask multiple people for their opinion, with open-ended but specific questions. This doesn’t work: “What would you improve?” Try this instead: “How many development bugs were there, and how many did you manage to correct and test by the end of release?” or “In which module do you have the least test coverage and what percentage is it?”
- Use checklists to repeat the successes and avoid stupid mistakes. Create your personal checklist where you take away acquired knowledge and lessons from every project.
- Find out what the biggest thorn in your side is. Support your software process improvement proposal with clear arguments and/or calculate the benefits.
- Be grateful for the critics in your team. They bring your overly optimistic ideas back down to earth. Divide the expected benefit by two.
- Get your colleagues involved in the game and you will have more fun.
- Be prepared that the activity may delay you now, but it will help us in long term.
- Start small, in your immediate surroundings, and gradually, with some quick wins. Do first things first and evaluate the impact of the changes individually.
- It does not end with the introduction of change. You should also introduce a control mechanism to adopt and keep the change.
