The term “agile” has become unavoidable in the software industry these days. This was certainly the reason why it was decided to restructure the entire process in my current client project. The most important aspect: It was to become agile, the objective being an improvement on every level.
Switching to a new process in a project that has been in progress for years—and has kind of worked—was and is, in fact, not the easiest task a team can take on. That was something that not only the product owner (PO) and the decision-makers, but the developers and testers in particular had to learn. While the transition was underway, we, the testers, noticed several issues that needed to be changed. I would like to discuss these issues here because they may be helpful for other teams in similar situations.
For our team, these challenges meant a lot of work, but overcoming them in the end gave us an important sense of achievement.
New refinement process and missing acceptance criteria
The entire workflow, from the definition of requirements to the development and the testing of the application, was redefined from the ground up, introducing a new refinement process that was intended to ensure better task processing by means of a defined JIRA ticket structure.
Unfortunately, the team of developers and testers was not involved in the definition of this standardized content. As a result, there were no acceptance criteria for the first cycles with the new process. The tickets did not give any definition against which we could have tested.
Suggestion for improvement
During our weekly tester standup, we addressed the fact that this method did not allow the testers to work effectively. We also pointed out that it would be useful to involve the respective staff in the project in order to define the content for the refinement. We suggested that both the technical department and the developers and testers draft their requirements for a good ticket, and to develop a Definition of Ready (DOR) guideline on this basis.
This suggestion was quickly implemented and applied. The acceptance criteria for the test are now an integral part of the tickets, allowing for testing to be done without questions in this respect.
Involving the team and living the agile method
Another problem that correlated with the first issue was the lack of dialogue with the team members. At first, the transition to the agile method was simply dictated “from on high”. This is in itself opposed to the agile method, which is supposed to focus on the people involved. In addition, an arbitrary method was forced upon the ongoing project and the project staff. Naturally, this was met with resistance. The staff not only felt ignored—they were being forced into a process template that was not tailored for the project and did not suit the staff. The general mood in the project was tense, and the work became less efficient.
The tester is the last stop in the development process of the software before it is delivered to the client. We have to put ourselves in the technical department’s position and empathize with their concerns; coordinate with the developers, the PO and other departments; and always focus on quality as the first priority. Furthermore, every error in the upstream process multiplies before it reaches the tester. This gives us a decisive advantage: We get an overview of the entire process because we see a part of every section. Consequently, it is easier for us to reflect on possible weaknesses.
Suggestion for improvement
We used this advantage and told the PO that the staff must imperatively be involved when an agile process is introduced. After all, it is the staff that has to support and live the new process. Furthermore, it is important not to consider a certain method and adopt it for the project without any adjustment. Based on our many years of project experience, we could tell them that the method has to suit the project and the staff in order to be effective. For this purpose, it is important to not only consider one method, but to combine several methods, and to test and adjust them bit by bit, step by step.
This suggestion was heeded as well, and several meetings were scheduled to clear up any incongruities and eliminate weaknesses. Items on the to-do list were defined, and a dialogue was started. The mood in the project improved significantly, and the work is now going much more smoothly again.
Stepchild automation
In the course of the process transition, the issue of automation should be addressed more seriously as well. From the tester to the decision-makers, everybody agreed that this issue was important and urgent. However, due to the numerous difficulties encountered during the introduction of the new process, this issue was dropped from the agenda.
Suggestion for improvement
First of all, the testing department broached the subject again and again, gathered information, and recommended tools and tested them for their suitability. They also actively sought to liaise with key persons associated with this topic. This required a certain intuition to watch for just the right moment in some instances. All the information was reported to the PO, and we inquired about the progress of this measure at regular intervals.
These points were taken up as well, and the issue was pushed up towards the top of the agenda. The PO called meetings with the decision-makers and will continue to advocate for progress in the field of automation. The choice of a tool, the integration into the process and the question of an increase in staff have not been decided yet.
Conclusion
In conclusion, my experience that the transition of existing processes to another method can only be successful with psychological skill, a focus on the key points and dialogue with the team members has been confirmed. One thing such a transition always needs is time. It is important to push a process, but it is just as important to wait for the right moment in order to use the full potential and seize opportunities at the right time.
As a tester in this client project, I saw that it is advisable to have some people who have already worked with the agile method involved on every level of the project for such a reorganization. This way, their experience can be taken into account and contributes significantly to successful implementation. Assistance from third parties can be called in as well, if necessary. In hindsight, this client project benefited from the fact that both ZEISS Digital Innovation GmbH and I myself had already had experience with agile methods.
This post was written by:
