Bloggo back to the blog
G(r)ood Testing 22 – Successful testing in waterfall projects? WINO, Agile goes undercover
Many organizations say with conviction that they are agile and work according scrum. Yet this is not always true. They might have stand-up meetings and neatly follow all the ceremonies of the scrum-guide. But at the same time they still use traditional methods and they fail to apply the agile principles. We see it in various companies that we accompany with their agile implementations. They do not finish their items, fail to do refinement, apply strict functions within their multi-disciplinary teams and are working in silos. Such an organization in fact does ScrumBut or SINO: Scrum In Name Only.
Measured from the fast amount of reactions that we received on an interview that Derk-Jan held with Andre Keijzer, SINO triggers many emotions with agile evangelists. You can read the interview the e-book “Agile in the real world, started with Scrum”. Andre, an old-school tester, was trapped ever since his organization adopted agile. He talks about the problems he encountered as a tester. Many readers of the interview were supporting him: “It’s logical that Andre can not work like this, this is not Scrum”, “This is disastrous,” and “Don’t blame agile; this organization has misunderstood agile. ”
Waterfall In Name Only
But the inverse situation also exists. Some organizations would surely benefit from an agile approach to testing, but don’t want to change. Saying that you’ll do Agile, instantly yields to resistance in these organizations. Fortunately, you can often improve in the testing process by implementing elements of agile. You do not need to start an organizational wide agile transition. You don’t even have to claim that you are doing Scrum. The point is that you book successes with little practical enhancements without generating resistance posed by a big change. We are not talking about Scrum that is not Scrum, but a traditional test approach that is slightly less traditional. Agile goes under cover. We call it WINO or Waterfall In Name Only. Below we share a few of the WINO elements that we used in practice.
For this project we were asked to define a performance test approach. Within this traditional project hardware was purchased, configured and tested. When we made the test plan it became clear that a lot of the dependencies were still unclear. It was to such an extent that estimation and planning were impossible. A number of challenges were recognized but it was unclear how to solve them with a technical or procedural solution. For this reason we started working in two-week periods (that we didn’t call sprints) in which we worked on small chunks of work (that we didn’t call backlog items). We regular stumbled upon impediments that had to be solved first before we could continue. We brought in the specialists to help the development team and the software tester. To ensure progress a briefing (that we didn’t call a daily standup) was held every morning. This frequent exchange of information created an optimal cooperation between the project members.
The introduction of agile elements did not prevent the project from delaying (it did). But it did enable us to manage and adjust expectations during the journey. This improved the progress and reduced the amount of accusations between the customer and the IT department big time.
The collaboration between IT and the client can also be improved by introducing demos.
Another project was dominated by the contract-driven relationship between the customer and the supplier. This meant the supplier worked in its own silo and we, as the customer, had little insight in the progress and bottlenecks. In a conversation with the development party we addressed why we needed insight. We explained that we needed their input to prepare our acceptance test. A demonstration was organized to get insight in the work that was carried out up to that moment. This was the start of a regular demo session that was held every three weeks. During these demos we reviewed the progress and quality. Eventually we were able to plan in advance what items the contractor would show in the next demo. We learned to understand the business process and could affect the order in which they completed their items. This way the client became the Product Owner (without calling him that). The improved cooperation results in a combined approach for the system tests that were executed before items were shown in the demo.
The examples described in this column show how we integrated agile aspects in the traditional approach. Whenever the waterfall methodology resulted in problems, we offered an agile alternative. Without waving the big agile flag, we introduced and tried small agile elements. More often than not these worked well and contributed to better understanding, transparency and cooperation. Agile without claiming to be agile. WINO, but with success!
Have you ever used agile elements in a waterfall context? Let us know in a comment below.
Co-Author: Eric van de mark
Eric van de mark is Senior Agile tester for Valori. He is expert in introducing Agile elements and improving testing. He is trainer, game-host and gives presentation on agile adoption and testing.