Agile or not?

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.

Advertisement

Being a tester (again)

It has always been my ambition to be manager of a (testing) company. And I achieved that a couple of years ago. So far so good… But then something strange happened: I gradually realised that I wasn’t happy being a manager and, of course, people started noticing it.

Why I wasn’t happy? Although we discussed testing most of the time, testing slipped away from me and I started to miss the actual testing in my daily work. And I felt left out: everyone at my company was testing, except me!

Time for a drastic career change and go back to being a tester again!

Walk the talk (again)

Those that have worked with me for (quite) a while – without exception – told me it was great that I joined the testing ranks again and never questioned my new/old position or decision. Some even said that I should have never left the ranks in the first place… Of course, there were others that immediately asked questions like : “When are you leaving?”  “Have you found a new job?” “Doesn’t it feel like a demotion and major set-back?”.

My answer was and is simple: there is no reason (yet) to leave. My company is offering me what I want: challenges in testing. By stepping up to those challenges and “walk the talk (again)”,  the questions automatically seem to stop…

Several colleagues and (test) friends suggested – independent from each other – that it could make a nice blog series writing about a “successful journey” from manager to tester. It is going to be fun, they claimed, since most “successful journeys” cover the opposite direction.

So, I decided to give it a go. Reason: my last blog post is several months old, the journey is worth writing about (I think) and I hope I can inspire some of you to do what you need to do: make sure that you keep doing – or go back to – what you like, what you’re good at and what gives you energy!

One stop shop

Luckily, I never completely let testing go, so I was aware that a tester needs to be a one-stop-test-shop for the projects and the teams you participate in.

You have to make sure that you quickly contribute – in any context – the best way you can to your team or project.  Whoever your customer is, you need to be able to help them, support them and ensure they get the test service they need.

By the way, tester or test service to me is a broad concept: as long as it covers an aspect or service slightly related to testing, I tend to consider it a tester’s job. Well, at least supporting it…

Turns out that my experience enables me to “get in the helicopter” every now and then and by doing so, I get a quick view of the “world” and am able to give advice that is in line with the facts.

So far so good, I kicked off a new category in my blog. Hope you’ll enjoy reading my blog as much as I enjoy writing them. Feel free to provide feedback (positive, negative, thums-up, thums-down, smileys, frowneys,.. )! I really like being a tester again, no regrets whatsoever. Since I have constant access to the magic of testing, there is inspiration enough for new posts! Next one might be about test automation, testing in Agile/SCRUM teams or both.

La plus perdue de toutes les journées est celle où l’on n’a pas testé.
(paraphrased  – Sebastian Roch Nicolas Chamfort, Maximes et Pensées)