How I Built an Agile Team
How I Built an Agile Team
The path may seem long, but once Agile works, it works. Here's Luigi Scarminio's team's journey to becoming an Agile team, with a few tips for those beginning the trek.
Join the DZone community and get the full member experience.Join For Free
You've been hearing a lot about agile software development, get started with the eBook: Agile Product Development from 321 Gang.
Implementing an Agile methodology was a critical success factor for the solutions developed by our team and for the continuous customer satisfaction increase — indicated by a grades increase in satisfaction surveys, as well as spontaneous comments congratulating us. We develop solutions for a very specific and crowded niche in aeronautics industry, by the way.
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 that is true if you don't receive the support from upper management. On our case, the need to go Agile was identified by the team and the hole 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 basically which solutions were going to be developed, a list of the scheduled updates, and the designated developer for each solution. Although the progress was measured monthly, it was only required that the finished solution to be delivered by the end on the development period, that is, a Big Bang.
The development team was divided one developer per solution and all the decisions were charged to that single developer. The tester was drawn from the whole team to verify the final version.
This environment was very favorable for the "since" effect: "Since you are implementing this feature, client X would like also 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 a better control and standardization of the software development process. The first attempt was to turn to a process common to the aerospace industry: 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. By team inexperience, instead of writing requirements, we were writing novels. The project was cancelled after two years and, if we had finalized it, it wouldn't be a user friendly solution.
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 was executed and controlled by only one person. The other team members were only delegated the tasks and they had no contact with the process, and when they had it was only superficial so the concepts were not clear.
We decided then to expand the Agile process for the whole team. Everyone already had their pre concept about how Agile worked, which were the roles, about Sprints, etc.
There was mistrust and worries: would it will be cumbersome and bureaucratic? Would there be too many people to report to? What if the the client requests weren't met? There was even concern that developers will be blocked or in standby by the rest of the Sprint. That is far from the truth. Not only are the number of endless meetings drastically decreased, but the whole team participates in the project decisions, there is a cooperative spirit, and the client demands are met on schedule.
To reach these results, it was necessary to erase the existing misconceptions about Agile. A whole week (5 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 erase misconceptions and to introduce the correct concepts, 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 review 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 dedicated 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 elicitate requirements, perform a grooming, distribute 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 and a 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 timed and the time given for each process is short, the team should be aware and constantly reminded that the role-playing activity is not a race against the clock! The final product should look nice!
I spent a lot of lines explaining our context and a few explaining how we developed the concepts into the team, but why? Because the last step is the hardest one. How to make your clients and stakeholders understand that you will not promptly attend their requests, 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 have to fight that urge to return to that bad habits we left behind. As the first Sprints started to roll, the clients started 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 the bad habits. A lot of negotiation is necessary and for this I have to thank our Product Owners by negotiating and our Scrum Masters by 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!"
Opinions expressed by DZone contributors are their own.