Lessons learned from 6 months of “AGILITY”

Few months ago, we made a conscious decision in my program to use an agile framework to tackle one project within our portfolio. The agile road for that project has been certainly challenging and stuffed with surprises. It took a lot of creativity and “agility” to manoeuvre this project in our traditional environment.

There is so much to say about this experiment that my leaders could “write a book” on all the adventures and chapters we faced within the last months. 

Here are some reflexion of what worked well and what could have been done differently.

First, agility is a mindset...

and not meant to be used in a systematic and rigid manner. 

It is an inspiration, especially for companies that are at early stages of agility, like my client’s. Few things we could have done differently to foster further the agility spirit :

• Appoint the right Scrum Master: Appoint a “non doctrinal” scrum master with change management and coaching skills. For beginners like my client, they needed someone to old their hand to take the first step into agility. Forget about reaching level 5 of agility, they first needed to set foundation and do a first step into agility. It turned out that our scum was very knowledgeable but had unrealistic expectations about level of agility we could reach in this first experience of agility. Scrum has to dose properly the agility to the level of maturity of he company. ONE STEP AT A TIME.
• Train and coach your team on Agility: Invest more time in agile training and coaching for our project team members. Most of our project resources had never worked in an agile project previously... it took time and significant effort to onboard and align all players. This created a lot of inefficiencies at early stage of the project and prevented us to have greater results on initial sprints.
• Don’t get caught in a battle of “agility religion”. Remember, it’s a spirit and needs to fit to the stage your company is. Everyone can have its point of view on agility and tell you, well real agility should be done this way or that way... Do what is right for you. Adapt based on what makes the most sense to you and your team.

Second, it is ok to take an hybrid approach...

fixed scope and fixed timeline does not qualify for “agile projects”. Our project had a predefined set of features (must haves non negotiable) that needed to be deployed by X date. It did not mean that we could not use agility, it just meant that we needed to adapt the delivery approach and shape it up to what we needed. Elements that worked well In our hybride approach: 

• We did the inventory of all user stories and than developed the critical path to be able to better plan sprints. Elements/ features on the critical path were retained for first version of software, others were pushed to a later release. We than were able to perform a ROM, develop a roadmap by sprint and than adjusted our capacity based on the mix of resources we needed.
• We however had to do the exercise twice as we did not succeed in developing a clear non-functional critical path initially. This should have been done properly the first time at beginning of the project and fined tuned after. We should have captured all non-functional stories and integrate them as well in Jira and should have linked them to our functional critical.. which we did late and obviously created signifiant issues.
• Our project sprints were set for durations of 2 weeks at the time. Ceremonies such as sprint planning, daily scrum, sprint closing were implemented and followed rigorously. We used JIRA to manage the stories, used other tools such impediment board to facilitate project. 

Third, report progress in a meaningful way for the business...

Reporting progress on an agile mode is definitively different than tradition milestone progress reporting. Don’t get too technical with burn down charts or point consumption charts in reporting progress to steering committee. Business want to know 

• What will be delivered? What features? Show a demo at the end of each sprint to the business
• Where you are in those deliveries?
• When they will be able to use it?
• Do you have any risks or issues and what are the actions?

On our end, I think we could have improved this aspect. It is a new product we are developing and I feel that steering committee members had still a vague understanding of what they could expect even with demos and several meeting on the new BI plateforme. We could have invested more time in preparing the business to the upcoming change. 

Those are the key elements but as I mentioned, there has been many learning points. Really enjoyed working with my vendors and business teams on this project. Together, we were able to adjust and bring to the table the best “dosage” of agile to our project.

Contact me if you wish to exchange further on your project.

Mylene