One of my first projects when I returned to the testing ranks, was an Agile/SCRUM multi-project program. Goal was to implement a future proof solution that supports continuity and enables continuous innovation of customer services (“any time, any place, anywhere”). My assignment: align the company’s generic test process with the project approach and manage the testing within the program accordingly. Major challenges: the generic software (test) process is not tuned to Agile/SCRUM (yet) and the (lack of) Agility of the project.
A generic software (test) process gives you a head start when moving towards Agile
The organization that hired me, put a lot of effort in improving the software development process, including testing. Supported by several external consultancy firms, they developed and implemented a broad set of tools, templates, guidelines and training for their people. The generic process covers every discipline: from project management to operations, from design to development, from architecture to testing. It was great to learn that testing was one of the driving forces behind this initiative. Therefore, it’s not a surprise to see that the organization highly appreciates testing. Turned out that they created a great starting point for becoming more Agile.
Adapt instead of abandon
Although several teams applied Agile/SCRUM, the generic software development approach was not aligned with that yet. Despite the willingness to become more Agile, some people were hesitant to move in that direction. Turned out that fear of losing what they achieved was the reason for that. By tuning the generic process to Agile/SCRUM instead of abandoning it, our project showed that the essential parts of the software development process remained intact and valuable. No reason to abandon (test) design or tooling. And a well-oiled DSAP-approach for test environments is great in an Agile/SCRUM project as well! Even some of the mandatory reporting turned out to be effective in our Agile/SCRUM project as well. To me, the biweekly reports about the status of the projects forced me to get in the helicopter and get a bird’s eye view instead of looking at the project alone. Simply by requiring a substantiation (facts) of the status you report, asking you to look beyond the borders of the sprint (product) and tracking completeness of the deliverables, including testware. It enabled me to provide helpful input for the retrospectives and ensured that my actions were more based on facts and less on emotions.
Contract negotiation over supplier collaboration?
It was the program manager’s decision to use Agile/SCRUM. And for the right reasons. The project start architecture formed a perfect start for the project. It created clear, coherent themes for the development teams and ensured they had the necessary freedom required to start designing, developing, testing and delivering in sprints.
It was the program manager’s decision to hire suppliers based on a fixed price fixed date contract. Alas, for the worst of all reasons: that’s how we do things here… For example, one of the SCRUM-masters created a high-level draft schedule for the first 8 sprints, based on the information available. Unfortunately, it was used against him and his team: the program manager did not allow changes to this schedule. Alas, again for the worst of all reasons: the project manager did not want to write an exception report and since he has communicated the schedule to the steering committee, he doesn’t want to tell them we’re deviating from it…
Collaboration over contract negotiation!
Turning point was a program retrospective. The program manager organized it, the SCRUM-masters and the test manager (me) initiated it and we made sure that, next to a part of the project team, several members of the steering committee participated in this meeting. In their opinion, a major improvement would be more collaboration. They wondered why, in an Agile/SCRUM setting, this was clearly lacking…
The new contract form chosen was simple: time and material, with a twist of commitment (make it beneficial for all parties involved to deliver high quality products). True collaboration and the ability to respond to change, were the logical consequence. And it enabled the teams to focus on what is important: delivering working software and increase velocity.
Test automation played a major role
At those moments where we were disappointed in the way we were (not) moving on in the project, the one thing that motivated me and my test colleagues, was test automation. Together, we took the time to update and extend the existing test automation solution to cover the new functionality. Worth another blogpost.
Ruud Teunissen 