Agile in an automotive project

As you have surely noticed, adopting an Agile approach is the current trend in the software development world. Many companies are turning away from a waterfall approach. I would like to share my personal experience in making this transition. After this experience, when I later read about Bruce Tuckman’s ‘Forming – Storming – Norming – Performing’ model, I realized it described pretty well my own experience.

I had been working for our client for more than 2 years. Waterfall was used everywhere and everyone was comfortable with it. Then the decision came that the whole company will move to an Agile approach. A lot of planning and preparation went into this change. For us as testers the first step was to migrate all our work from TFS to JIRA, which is better suited to the agile approach. The process was long and tedious but in the end we managed to have our new structure in the new tool and were comfortable using it. But that was only the beginning.

People not knowing what Agile really is

The fact that Tesena provides us with training about agile and that some of us even have an ISTQB Agile Extension certificate made the transition a lot easier for us. The problem was that pretty much everybody else on the project had no experience with Agile at all. Therefore, the company arranged some training where everybody could learn what Agile is about. The people learned who is the Product Owner and Scrum Master. They got familiar with what the backlog is and how the work is divided into features, which are further divided into user stories. After the training, we tried to divide some features into user stories and estimate them using planning poker. Nobody knew what they were doing. They had no idea how to estimate the user stories because they were used to work with man days. Now they didn’t know how many man days is 1 story point, so they didn’t know what number to show. This led to massive overestimating or underestimating of the user stories.

Better communication with Slack

Our sprints are 2 weeks long. The first sprint was a zero sprint just to learn the basics. But we didn’t manage to deliver almost anything. People were stressed about it and started to doubt the approach. The first retrospective we held was very negative. The estimation system was one of the main pain points. “How can we estimate work of someone else?” was a big argument. Our Scrum Master was trying to calm everybody down, saying that it’s just the beginning and that we are all learning and that it would get better. Communication was another issue. We had to be able to communicate fast and since the team wasn’t sitting together (as is recommended in Agile), this became an issue. We tried to rectify the communication issue using Slack and at least one co-working slot a week. This helped improve the communication within the team.

Bad communication

Another key part of Agile are the ceremonies. Daily stand-ups, planning, demo, retrospective. We were a pretty big team for Agile, with over 20 people divided into 3 sub-teams. This created an issue of time management. With so many people it was virtually impossible to finish our ceremonies in time. Even if we planned a slot for 2,5 hours, the planning would still take 4 hours. There were so many stories with many subtasks for many people. Everyone had their say and their questions about the stories. Then there were the stand-ups, a ceremony that normally shouldn’t take more than 15 minutes. Every day, we would have a stand-up that lasted 45 minutes! These long meetings cumulatively took a lot of time from our hands. So, on the next retrospective this was what everyone was complaining about.

Learning what to do during ceremonies

After a little while, we started to optimize the process. A decision was made that the sub-teams would hold our ceremonies separately. The 2 teams covering Reporting would stay together in one room because their work overlapped a bit, so this would make communication easier. The Tracking team would be in a different room because even though they belonged under the same platform, their work was different and it usually had to be done before the Reporting team’s (Reporting is dependent on Tracking). As it turned out, this was the best decision that could have been made. The effectiveness of our ceremonies rose sharply. Suddenly there were only around 8 people, who could talk to each other in a more organized manner. The stand-ups started to take only around 15-20 minutes and the time saved could be spent on our other activities.

Test approach

The fact that we weren’t Agile in its purest sense meant that we still had separate functions as developers, testers and business analysts. My work was still to create, execute and maintain test cases. Being the senior tester on the project and having the most knowledge about SQL, I was focused mainly on testing the databases. The JIRA management and maintenance was on the shoulders of my other senior colleague who is normally a test manager. But since there is no such role in agile, he showed his t-shaped qualities and helped with test execution and test data preparation. We had two junior testers with us. As well as learning SQL they were doing the UI tests. This approach worked just fine. We were able to have everything done at the end of every sprint.

Making more educated estimations

Everyone was starting to get on board with the new approach. To help the estimations we created a reference story (a story that is approx. in the middle of the story points scale and is a good candidate to compare it to other stories). In our case, we took all the stories that we’ve done so far and re-estimated them again. Everyone took one story and put it on the table under the amount of story points they felt would be the best for the chosen story. If someone else didn’t feel it was right, they discussed it with the rest of the team and in a short time, we had all the stories on the table. In the end there were only a few good candidates. We chose the story that had all the stages of the development – database update, development, testing. This seemingly little thing helped to understand the estimation process a lot better. After that our estimations were much more likely to be on point and our delivery success rate rose accordingly.

Productivity increasing with each sprint

People got used to the fact that everyone should be online on Slack and ready to answer any question coming his way. I must accentuate the work of our Scrum Master who was very eager to learn the new methodology and helped everyone to settle. His meetings were in the end very organized, he listened to the team’s needs and knew what was necessary. He was right all along, we got better. You could see the enjoyment returning and people being more friendly, knowing they can rely on each other. In the second Product Increment we were able to deliver most of our tasks (only those that were dependent on other teams couldn’t be delivered) and even some stretch goals. The team started to work like a well oiled machine. Everyone knew who to talk to, everyone knew what to do and everyone delivered.

Conclusion

This was my first agile project so even though I knew what it is, what it brings and how it works theoretically, I didn’t previously have the chance to experience it in practice. So, for me personally the transition was a difficult, but very interesting experience. I found out that the fear of the change was misplaced. Now I believe that the project works much better than it ever did during the waterfall approach and it’s much more engaging. So, if you have no experience with the Agile approach, don’t be afraid to try it because in the end it’s worth it.