This audio was created using Microsoft Azure Speech Services
An Agile transformation can be challenging in a larger company. Fortunately, it can be easier if the Agile focus is part of a larger digital transformation with strong executive sponsorship. Either way, if you want to make progress in socializing Agile principles across an organization or infuse into a program, you will need to constantly evangelize the benefits backed up with solid success stories. Recently, I have been fortunate to witness two great success stories applying Agile to traditional IT projects. When I say traditional, I mean deploying a vendor’s configured software platform across a large population for a specific purpose. Both were modeled in a similar way, equally producing positive results, so I thought it was time to share our experience with others.
One successful program in our organization was the deployment of a common travel expense management platform. The other – the deployment of a common Procure to Pay (P2P) solution for indirect purchasing. Both programs were global initiatives being deployed regionally within North America. Our North American team attempts to influence with Agile methodologies whenever possible, and it turned out to be well worth the effort. The main benefits were budget efficiencies, reducing schedule risk, and most importantly, convincing key influencers on the value of Agile.
Team Creation
The first interesting discussion happened when the supply chain regional leader began describing the traditional waterfall approach to team meetings and structure. As you may suspect, it was weekly team meetings with 35-50 people across multiple functional domains. The plan was to track the schedule in MS Project and provide action items after each meeting. To begin thinking differently, we collaborated on a more agile approach using Agile principles and the Scrum framework.
We started by shrinking the team to a “two-pizza”-size team of 10 to 12 members. That is where we saved money. By putting more thought into creating a smaller group of focused individuals, it was determined that most of the original group didn’t need to actively participate. We focused on a smaller group that would be completing the tasks rather than people who might have an opinion or knowledge on the topic. We mapped clear connections from scrum team members to part-time influencers for answers or input.
By keeping the team small, we were able to eliminate distraction and maximize time while maintaining the influence of the broader organization. Later, we estimated this approach saved hundreds of people hours during the five-month deployment.
Key team members included:
- Regional program leader – acting as the Product Owner. The Product Owner training was a crash-course in leading backlog grooming sessions with stakeholders, properly writing user stories, and responsibly maintaining clear priorities.
- An experienced Scrum Master – you can’t compromise with an inexperienced Scrum Master or Agile Coach to mentor a group transitioning from traditional waterfall projects. This is one key role that can’t be quickly trained and put in place if you want true success.
Team Ramp Up
With the core team, we trained on key Scrum concepts of sprint planning, visualizing work, daily standups, and constant team feedback. The team decided on two-week sprints. Each sprint was kicked off with sprint planning and a retrospective feedback session at the end. Jira was introduced to the group for maintaining backlog and visually moving tasks across the Scrum board.
At this point, you may be thinking this is a lot of pre-work to kick off a project. Well, some of the team did as well and truly didn’t believe this project was a good fit for Agile. Why? “This is not a software development project…”. We know what we need to do, and Agile is when you have unknown requirements…”. “We can’t have dedicated people on the team…”. Yes, all that was true. We challenged these basic assumptions to reveal the additional benefits of Agile.
There were a few concepts to changing the skepticism, including enhanced team focus, benefits of visualizing detailed tasks, and committing to time-boxed sprints. Even though we tried, most of the team was not 100% dedicated to the project. During the initial kick-off, we got buy-in from everyone to prioritize the time required to attend sprint planning, daily standups, and retrospectives. We struggled to ensure participation along the way (especially daily standups), but prioritizing these meetings over all other activities was key.
Team in Action
In Jira, the team was able to create their own tasks under each user story visualizing the required work. If tasks were expected to take more than a few days, the team broke down the task.
Below are a few of the benefits Jira provided the team:
- A balance of storyboard administration versus hiding potential delays in large stories or tasks
- Clear visibility into what work needed to be done as the work was broken up into smaller chunks or tasks
- Strong sense of satisfaction and accomplishment when moving tasks toward the “Done” column
- Better insight into clarifications needed or any critical barriers
The two-week sprints helped us to maintain team focus and prevent the build-up of tasks late in the project. In the initial planning, we challenged ourselves to release value after each sprint. Unfortunately, we determined it was not feasible. The team worked in an Agile manner with unit-testing and integrating features after each sprint packaged for final user acceptance testing and go-live.
A formal go-live date was selected mid-way through the project, which was not ideal. A key part of Agile is to release when you are ready. The release affected a large population needing a predicable cutover date from the previous system. With the benefits of Agile, the go-live date could have been moved up by three to four weeks. Three weeks would have been a 20% improvement in the overall timeline. User acceptance testing and training were completed weeks in advance. It was a struggle to overcome the challenge of preparing and communicating a cutover date in advance but remain flexible to release when ready. I would appreciate any advice if you have experienced a similar challenge.
Team Retrospective
Leading up to our successful and relaxed go-live, we asked ourselves, “if the juice was worth the squeeze?”. The resounding feedback was “yes!”. With Agile, the team believed the risk was reduced, the quality was increased, and the better product was delivered. There was no concern about organization charts or functional silos. The team felt empowered to make key decisions and focus on the work to be done.
Earlier, I mentioned my favorite benefit of implementing Agile, which is convincing key influencers. These influencers can now evangelize within their own groups. The education and results will begin to echo broadly across the global organization. We can reinforce the larger goal of accelerating our company’s Agile transformation with these success stories. I hope you have some of your own and wish you good luck if you are in the middle of your own Agile transformation. Please don’t hesitate to share your experiences with me, and make sure to read my other articles below:
Conversation
Dale Watson
4 years ago
I appreciate the candid and realistic depiction of the Agile journey for these two programs. Experiencing the energy generated by creating transparency with focus is critical in leading a team to objectively inspect and adapt throughout a program. As shown in these programs, value is then gained for the organization and possibly more importantly for the team members, who then are eager to look for future opportunities.