How I Built an Agile Team

Implementing an Agile methodology was a critical success factor for the solutions developed by our team and for continuous customer satisfaction increase — indicated by the increase in satisfaction surveys, as well as the resulting customer comments congratulating the products and us. We develop solutions for a particular and crowded niche in the aviation industry.

Before introducing how Agile was implemented in our team, let me describe how our work environment was to contextualize it. In many articles about this subject, the authors state that Agile is not a silver bullet. I will also agree that this is true if you don't receive the support from upper management. In our case, the need to go Agile was identified by the team, and the whole implementation process was bottom-up. We were lucky to have support from the upper management.

Before Agile, the yearly planning was done according to an action plan approved for that period that contained which solutions were to be developed, a list of the scheduled updates, and the designated developer for each solution. Although the progress was measured monthly, the goal set was to deliver the finished solution by the end of the development period, that is, a Big Bang.

The development team was divided and one developer was assigned to each solution, and all the decisions were charged to that single developer. The tester was assigned randomly, drawing from the whole team to verify the final version.

This environment was very prone to the "since" effect: "Since you are implementing this feature, client X would also like this other feature," which was usually promptly implemented according to what the developer understood and how the client described.

With this scenario, the team felt the necessity for better control and standardization of the software development process. The first attempt was to turn to a process typical to the aerospace industry: the waterfall development process. We were not successful. We spent too much time writing requirements, with only a few user validations, before starting the implementation phase. Due to team inexperience, instead of writing requirements, we were writing novels. The project was canceled after two years and, if we had concluded it, it wouldn't have attended the users' needs.

A couple of months before the end of the project, one of the team members came up with a process framework called OpenUp. It was our first contact with an Agile framework.

There was a tryout with OpenUp in one of our projects, and the results were promising. However, all the processes were executed and controlled by only one person. To the other team members, it was just assigned the tasks, and they had little participation in the concepts being applied.

We decided then to expand the Agile process for the whole team. Everyone already had a pre-conceived notion about how Agile worked, what the roles were, about Sprints, etc.

There was mistrust and concern: would it be cumbersome and bureaucratic? Would there be too many people to report to? What if the client requests weren't met? There was even concern that developers would be blocked or in standby for the rest of the Sprint. That is far from the truth. Not only did the number of endless meetings drastically decrease, but the whole team participated in the project decisions. There was a cooperative spirit, and the client demands were met on schedule.

To reach these results, it was necessary to break the existing misconceptions about Agile. A whole week (five working days) was dedicated exclusively to Agile implementation. From that moment and beyond, we would be an Agile team!

Since one week is a short time to undergo a culture change, there was a little homework before we started. We adopted a textbook, Essential Scrum by Kenneth S. Rubin, so everyone got familiar with the concepts and decided which would be the minimum required chapters — in this case, chapters 1 to 8. The week would be then dedicated to reviewing concepts, team members roles, etc.; and how things would work in practice within our processes.

Days 1, 2, and 3 were dedicated to lectures about concepts, roles, ceremonies, and artifacts. Day 4 was devoted to role-playing and simulated practices. And finally, day 5, the D-Day, where every team member had to revise their tasks, change it to the Agile format, execute the first Grooming for all projects, and get ready for the first Sprint Planning meeting in the following week.

A hint about the role-playing and simulated practices: forget about simple group games like paper airplanes folding to explain how the Agile process works. My suggestion is something simple, but with many steps: draw a two-story house. The game should have all the roles, ceremonies and artifacts as close as possible to your team's final Agile process. In this game, the team will have to collect requirements, perform tasks grooming, assign tasks, collaborate with each other.

The "days" should last about five minutes. At the beginning of each "day," the team should do a Daily Scrum meeting. The "sprints" should last about four to five "days." At the end of each Sprint, the team should perform a Grooming, Sprint Review, and a small Sprint Retrospective. The next Sprint should start with a small Sprint Planning. By practicing all the process steps, the team will get used with the concepts. There must be attention to just one thing: since the activity is timed and the time given for each process is short, the team should be aware and constantly reminded that the role-playing exercise is not a race against the clock! The final product should look nice!

The last step was the hardest one: how to make your clients and stakeholders understand that you will not promptly attend their requests. They will be registered as a backlog item, and that is better for them.

There is no simple way to explain. The first reactions were very negative. But staying within the process is a must, and we had to fight that urge to return to those bad habits we left behind. As the first Sprints started to roll, the clients began to be involved in the development process and invited to validate the solution. "Hey! They are really working on the feature that I requested," might have been their reaction. "Wow! They really delivered on time, and it is better than what I requested!" might have been their second reaction. And what was initially a negative perception, became a positive one. But the most valuable lesson is to stick with the principles and fight bad habits. A lot of negotiation is necessary, and for this, I have to thank our Product Owners and our Scrum Maters by hard work negotiating with stakeholders, facilitating the process and not giving up.

Today our team is almost self-managed for the development part. Scrum is part of our routine, and some members dedicate part of their time to study the subject and to bring process improvements. The team is also engaged with new ways to improve our solutions with Design Thinking, Design Sprint, etc.

And by the end of the day, nothing is better than a co-worker saying "Thank you! Now I really know what I'll be working on for the next couple of days!" and delighted customers!