The Road to Building Sustainable Software Capability – Part 2: Stabilization

This article is the second installment about a real-life journey undertaken by the Managing Director of a company and her team who had little knowledge of software development but absolutely needed this capability to sustainably serve the evolving needs of their customers.

In the previous article The Road to Building Sustainable Software Capability – Part I: In a Pickle I covered the journey up to the point an external software development provider was chosen to replace the current provider who was stepping back from maintaining the companies key software solutions.

Having selected the software provider the next problem was how to start maintaining the existing solutions so that customers and stakeholders could continue to be served in a sustainable manner. This could be broken up into several sub-problems:

1. Organizing the internal team to work with the external software provider
2. Collecting customer/stakeholder bug reports and change requests
3. Planning, prioritizing, scheduling, executing, testing and tracking the maintenance work

Team organisation

As mentioned in the previous article, the incumbent software provider was no longer maintaining the solution and a backlog of bugs and desired change requests had piled up. The internal person who used to work with the previous software provider to organize the maintenance work had stepped back from the role as well. The previous maintenance process involved the internal person working with the previous MD to define the maintenance releases and to role them out as a fait accompli with the important support staff in particular often not finding out what was to be in the releases until it was too late to make the changes that they wanted.

I suspect this is what it may have felt like to the team when diving into the Unknown Realm of Software Maintenance

The team had to assign someone to go through this backlog and prioritize it for development and release. This person, called the Product Owner was chosen from the internal customer support team because of her familiarity with the product and first hand experience with the maintenance items. To help her understand the role, I gave her a brief overview of product management and pointed her at a few web definitions such as 7 Key Product Owner Responsibilities.

the Product Owner was chosen from the internal customer support team because of her familiarity with the product and first hand experience with the maintenance items

The other missing role was that of software Tester who was to be responsible for testing the changes made by the developer to make sure they accurately met what had been specified and did not possess significant defects (bugs). The team was very fortunate in that they had an experienced customer support person whose role was being freed up by the significant re-organisation currently taking place in the business. Although this person was not a trained software tester, she knew the product intimately and more importantly had borne the brunt of the previous process where she and other support staff were often powerless to enact changes. To help her understand the role I gave her a brief overview of efficient testing methodology and how to create a test plan.

she knew the product intimately and more importantly had borne the brunt of the previous process where she and other support staff were often powerless to enact changes

In a nutshell, efficient testing methodology meant doing detailed testing of maintenance changes as well less detailed Smoke Testing of the remainder of the system where appropriate.

One notable issue was that the tester in particular was to undergo a substantial change in role by being moved out of the support team. I had the feeling that “OMG am I going to lose my job?” may have flitted across her thoughts. I have found it critical when building out internal capability to make sure that the team members understand the importance of their new roles. The MD and myself had to take the time necessary to make it clear that this was not a ruse to make her redundant from the company but rather to train her up in this new, crucial and more importantly sustainable role.

“OMG am I going to lose my job?” may have flitted across her thoughts

Another significant hurdle to overcome with the internal team was to give them the confidence that they could be involved in software maintenance without any prior skills in this area. So an initial goal of a small release was set and I would guide them through the process to ensure everything was done properly.

The next thing was to collect change requests and bug reports. Initially this could be simply managed via email and a simple list. A more sophisticated tool could be deployed and found later. They key was to quickly get value being generated and confidence gained by focusing on getting a maintenance release out.

They key was to quickly get value being generated and confidence gained by focusing on getting a maintenance release out.

To help with planning, prioritizing, scheduling, executing, testing and tracking a simple task board was set up using Trello. This was chosen because it is simple to use but other tools such as Jira could have been used as well.

Example Trello Board with sample cards

The process used for the maintenance release was kept simple:

1. The product owner would add items from the stakeholders into the backlog in the form of cards and priorities them.
2. The development and test work would then be done in increments called sprints. Each sprint would last 1-2 weeks typically.
3. At the start of the sprint the team would meet and discuss what cards were to be moved to the For Execution column for execution in the current sprint.
4. The developer would then make the changes required by the card and pass it onto the tester.
5. The tester would then test the changes and either pass them back to the developer if there were issues or move them to the Ready To Deploy column if everything was ok.
6. Once sufficient work was completed in these sprints for a release, the product owner would send out out an email to all stakeholders informing them of the upcoming release and schedule a suitable time with the team.

Well, the team followed the above process and made a successful release to much jubilation. If my memory serves me correctly something along the lines of “these software releases aren’t that hard” may have been said. This gave the team and the rest of the company tremendous confidence.

“these software releases aren’t that hard”

As an added bonus, because of the testers extensive experience in her previous customer support role, it was found the tester could act as an efficient first point of contact for the developer to rapidly answer questions and they developed an excellent rapport. The tester could also assist the Product Owner by mocking up the requirements for the developer to make them easier to understand and take even more load off the product owner. This, further boosted the teams confidence. An example mocking up tool is Adobe XDs.

With this new found confidence and maintenance process the team then proceeded to make more successful maintenance releases, ad nauseam, confident they had mastered software development … right?

Well not exactly …

The developer pointed out that although he was able to perform crucial maintenance of the existing code for the solutions, they were indeed at the end of life. To add new features critical to improving customer and stakeholder experience would require the development of entirely new solutions using current technology.

Creating new replacement solutions, in new technologies was a significantly different problem to the simple maintenance process the team had mastered and this part of the journey will be described in the next part of this series The Road to Building Sustainable Software Capability – Part 3: Success with an Awesome Web Application.