TABLE OF CONTENTS:
To begin with, a short disclaimer is in order directed at all of you Agile / Scrum maniacs:
this text undermines the logic behind utilizing bare Scrum, therefore, may induce in the reader an insatiable drive to inflict harm upon the author. Please, refrain from doing so…
The topic of introducing the Agile approach to software developing teams has been discussed in countless books, presenting countless use-cases, ending in countless happy endings and bliss in general.
What I would like to do is to show the topic from a slightly different angle, from the perspective of a Validation Team Leader – a team leader engaged in a thorough testing of an entire project done in the outsourcing environment. How did we do it? And did it look like in the books mentioned before?
One of Agile’s principles is that the team should be interdisciplinary and its members should be developers. People in my team are testers, testers who want to test, who want to automate tests, who ‘live by the test an die by the test.’ Clearly, there is some discrepancy here. I can call them whatever I like, yet they will remain testers. And why shouldn’t they if this is the business need? Theoretically, we could reorganize the team and learn how to develop production code, but then again, who would perform tests? Developers? My experience shows such adjustments for the sake of fitting into some concept are never a good idea and never end well.
According to Scrum, plans are built collectively and the whole team decides what enters the sprint and how much work will be done within the allotted number of Story Points. How did our team fare in this respect? Development timeline was prepared for half a year in advance and indicated what functionalities were supposed to be built, while planning involved only deciding on their scope of implementation. The testing team had to adjust to these conditions and accept that the only decision on their part was to plan the range of performed tests to fit them in the sprint. It is worth noting that new tests constituted about 5% of the existing inventory which might be perceived as a regress.
At this point, I am sure, most of “Agile Couches” reading this can see no problem in what I am saying and already have a list of ideas on how to implement Agile in this environment and another list of “activities” proving that it is possible. Unfortunately, in this case, it is NOT. Why?
As a company we encourage all initiatives connected with general agility in software development. To enhance our teams we have gathered here both certified SCRUM Masters and Agile Coaches. We do work on natively Agile-based projects and, to the satisfaction of our clients, we have successfully converted multiple non-Agile projects into their current, streamlined versions. Basically, how far we can adjust any given project towards higher efficiency depends on the client and their prior experience with Agile.
In this project, though, the relation between us and the client was strictly defined by many agreements and measured with countless KPI and SLA parameters. It stemmed not from the client’s need for overly strict control, but rather their lack of experience in the field of outsourcing and as a consequence, ability to implement Agile in such an environment. This lead to legal limitations in building the project team, making decisions collectively, scheduling, and planning. For their ill-devised idea of safety the client decided to choose the kind, range, and schedule of tests performed by my group, even though we were more than capable of taking this responsibility upon ourselves, as we have done in other projects over the years. Was the client to blame? I suppose not. Everyone wants to buy the best service and product possible, and it is not uncommon to be convinced that the best way of achieving this is to obsessively control the contractor.
In the case of this particular project I had to face questions such as: how to be Agile in such conditions? Can we do it? How do I give people space to work and decide on their own tasks and schedules? These problems proved very difficult to solve, especially within a testing team which, by definition, works on repetitive tasks and does not deal with much novelty. The solution had to include several stages.
I had to accept that some things could not be changed, at least not at the start. Therefore, I decided not to implement Scrum or Kanban in their pure forms. After going through several courses and harsh discussions with our Agile specialists I had a general image of the changes I was able to make. They were supposed to benefit the team both efficiency- and comfort-wise. It was one of the most difficult challenges ahead of me but also one of the most important ones, as it would define the basis of our later actions. It was crucial for me to allow the team to choose their tasks, without losing focus on the environment in which we had to operate.
We had to get the right “authorization” from our client to increase our independence as a vendor. The main obstacle here was the supposed risk the client had to take, shifting certain responsibilities to our domain. The fact that we would decide what to test and how to test it was obviously beneficial. The client was no longer burdened by the tasks we were competent and comfortable in doing. Additionally, the client did not have to take responsibility for this part of the project any more.
We were able to succeed thanks to good performance in prior projects – we had shown the client that we were an experienced, knowledgeable, and efficient team of specialists. For the management’s sake we included additional KPIs in the agreement to address the process of test execution, but we have reached our main goal – we could decide in the matters of testing, and the matters of testing range were always agreed upon by both sides.
Pure pleasure of implementing the solution was a reward in itself, as this stage was slowly revealing that the undertaken assumptions and ideas were the right choice. What did it look like? At the beginning of every sprint we were choosing the range of the tests involved, correlating it closely with the development team’s implementation plans. In Jira we created a Kanban board and filled its backlog with a substantial number of tasks, including every test we had assumed, and each task involving several tests grouped thematically. What is important, the board was open to alterations, adding or removing its parts. Like every Kanban board this one also had certain limits in status columns, yet these limits did not disturb the workflow. They were mostly used as information on the team’s load level and a safety measure against “blocked” or “in progress” tasks piling up dangerously.
Every day we had a daily meeting to sum up the progress which was a crucial element in our cooperation – it was a perfect way of sharing information. Tasks were being finished one by one and taken from the board by the leader, if the result was satisfactory. At the end of each sprint the retrospectives meeting was held – we discussed all the problems we had faced, we looked for solutions, drew conclusions, and went on to the next sprint…
So, how was it? According to most of the team it was great. Everyone had some freedom in choosing tasks for any given day, what tests to perform, and on what component, making work fit their personal preferences. When facing problems everyone knew who was dealing with the given topic before and who might serve them a helpful advice. Team members were happy to undertake new tasks to break the monotony of performing the same action over and over again. This way they were not losing interest in their work, remained vigilant, and efficient – in some cases they did not perform the same test for as long as 3 or 4 sprints.
There was no problem with keeping “placeholders” within the schedule because the model accounted for any changes within the board even during a sprint. The Kanban board clearly presented the status of tests performed on any given stage of the project, we knew precisely what had been tested, what was still ahead of us.
Finally, the client saw that they could trust us entirely with performing tests for them and shifted nearly all decisions in this area to our team, saving a substantial amount of time for other activities.
Did we fulfill the Agile manifesto guidelines? In my opinion, we did. Would I call it a pure Scrum or Kanban approach? I would certainly not. A hybrid more likely. But does that even matter what we call it?
Is it not more important to be agile in performing ones tasks than to be Agile in ones practices?
I think it is definitely a better idea to pick and choose parts of various approaches and make them work, instead of blindly following the one and only, true way of doing things. If one methodology does not seem to work for a team, why not alter it, adjust, combine with other ideas, and make it our own… At the end, it is all about reaching a better, more efficient, and less straining workflow. Just like Agile says…
Get more information about complete engineering teams!
