Agility: confessions of a converted digital project manager

The fact remains that companies are increasingly drawn to Agile organizations, which are reputed to be more flexible and adaptable, as well as customer-centric. This means that anyone working in the digital sector (whether they are a developer, tester, project manager, expert or architect) is very likely to encounter a project run within an agile framework. As they are difficult to avoid, we might as well approach Agile projects in the best possible frame of mind. My experience may be able to help you with this. 

DOES AGILITY GET BAD PRESS? 

People in France have a tendency to remember negative aspects, to the detriment of positive ones. And this was indeed the case the first time I chatted to people about the topic. These were the main gripes: 

• Agility is a method that allows the client to change their needs too fast, meaning the team has to constantly do things over again 

• Agility is a method where employees are treated like children, with the application of rituals within an overly rigid framework 

• Agility is a method where you feel like you’re submerged by a constant repetition of sprints and rituals  

In short, these first impressions were a little bit off-putting! 

A MIXED FIRST ATTEMPT 

Like many colleagues, I found myself suddenly confronted with the methodology when I joined a “Pseudo Agile” project, so called because the team was trying to selectively apply components of the methodology, such as:  

• Backlog implementation 

• Sprint creation 

• Planning poker sessions 

This can work in some cases, but with this project a number of essential components had been left out, including: 

• Calculation of team velocity 

• Precise management of priorities  

This meant that the team felt like it was constantly switching between periods of action and inaction.  In these conditions, the prejudices I had heard about the application of Agility appeared to be true. However, the conclusion I came to was something along the lines of: “I never want to be involved in this kind of Agile project again,” rather than “I never want to be involved in an Agile project again.” 

As is very often the case with feedback from Agile projects, the feeling of unity within the team was an interesting dimension. Furthermore, the reasons for the difficulties encountered in this project were partly identified and avenues for improvement were visible. I had the feeling that, with more time, things could have worked out. 

A CONCLUSIVE SECOND ATTEMPT 

My second encounter with the methodology occurred in a very different setting. This time, I was actively involved in the Agile transformation of a project previously managed using a V-model, as a certified Scrum Master. This transformation was initiated to pursue improvements identified by the client and SQLI: 

• Less time spent going back-and-forth on contractual aspects 

• Earlier delivery and testing 

• Enhanced interaction between the development and testing teams 

• Consolidation of the knowledge base  

With my previous experience, and assistance from an Agile coach, I was able to handle this project with greater assurance. Several fundamental aspects helped us begin on a sound footing:  

• Training on the concept of Agility (in this case the SCRUM method) for the whole team before switching to the new mode 

• Assistance from an Agile coach with the first three sprints 

• Precise definition of the roles and duties of each team member   

Even in these favorable conditions, we were rapidly confronted with several problematic situations:    

• A feeling of having too many meetings and not being sufficiently concerned by topics addressed during rituals 

• A number of unreliable estimations that caused tasks planned in the sprint backlog to go off track 

• Development work that was started too early, leading to an increase in back-and-forth discussions during the sprint 

• Unexpected events that disturbed the sprint backlog, preventing the team from fully completing the objective set at the beginning of the sprint    

However, the training sessions on Agility, as well as assistance from the coach, meant we had a solid foundation for discussions and were able to immediately enter a continuous improvement process. At the end of the day, we were prepared for things not going as described in the methodology and were not surprised that we had to correct our course. 

Among other things, we worked on the following aspects:   

• Backlog priorities, to avoid forgetting anything and encountering unpleasant surprises during the sprint 

• Measurement of the percentage of unexpected events in the calculation of team velocity 

• Optimization of time spent on rituals, by reexplaining their benefit and better preparing meeting agendas 

• Adaptation of the criteria for inclusion of a User Story in a sprint, as well as for completion of a User Story  

These essential adaptations were applied during the first three sprints, which enabled us to rapidly achieve a way of working that suited everybody involved, while delivering positive results for the management team. 

Following a year and a half of applying Agility, this way of working has been crowned with success. Some developers even go so far as to say that they would not want to work in any other mode. As far as I am concerned, while I recognize that the implementation of Agility resolved the problems we faced in this project, I feel that the right ingredients are needed for it to work, including analysis of the need to apply the methodology, assistance and training, and engagement of everybody involved. Knowledge of the methodology is essential to be able to effectively adapt to the framework of a project. This is particularly true in the first few months of applying Agility. This experience has now confirmed to me the importance of being comfortable with this type of project methodology to remain competitive in the world of digital projects.  

It can work! 

So, if you are not familiar with this methodology, try to build as much knowledge on the topic as you can. Finally, if you have had a bad experience, try it again. Give Agility a second chance!