Case Study
Agile Training Doesn't Have to be Disruptive
Rapid Agile training delivers measurable results in just two weeks
Think “Agile Training” and your mind may conjure up images of time-consuming disruption that impedes development schedules.
While it is true that Agile requires a committed approach to transformation, some companies are dipping their toes in the water with rapid-fire Agile training to see how it works within their organization.
Insurance software company Silvervine recently tried this with outstanding results.
Silvervine offers a customized approach to its software with individual implementations for different insurance companies, many of which have unique feature sets. And sometimes those feature requests come in fast and furious to the development team.
Chaotic Release Days
With each member having multiple responsibilities, the Silvervine team was struggling to keep up with customer demands. Visibility into their scope of work and predictability was suffering, and release days were chaotic due to inadequate planning.
Silvervine Project Manager Jaron Wilkins thought Agile could help. The team was already aware of Agile, they just needed someone to teach them how to apply it.
Using “Real” Work for Training
While eager to explore Agile, Wilkins was wary of disruption. “Because we were a small team, taking everyone away from the work they had to do would cause issues,” he said.
Motion Recruitment National Agile Practice Director Joshua Jack suggested a different approach from traditional training. “We took a limited impact approach so that we could minimize the amount of disturbance. Plus, unlike typical Practical Agile courses, we used their actual work during the training so they were not only training, but getting their work done,” he said.
The training took place over a two-week period. The goal was to get them to see their own work more clearly and get them to more of an Agile-enabled state.
Over the course of two weeks, teams received introductory training and then dove right into condensed sprints on their initiatives. Each sprint included either training or feedback loops that helped the teams solve complex issues in their own environment using their own resources, and focused on their own bodies of work.
Most Scrum trainers and coaches recommend sprints to be one or two weeks long. Teams go through the stages of team development (forming, storming, norming and performing) in fewer sprints if the sprints are shorter.
For this engagement, Motion Recruitment coaches took traditional training processes and “thin-sliced” them.
Two Weeks’ Work in Two Days
Jack explained, “We took what we normally did in two weeks and did it in two days. And then repeated it multiple times. For a two-day sprint, we planned 30 minutes, then sent the teams off to do their work.”
Iterative Delivery Framework
Continuous Delivery Roadmap
The results speak for themselves, setting expectations on what the teams could accomplish and deliver to customers.
- Improved project visibility. Visualization of work was key to realizing that leaders were asking too much of the team. Timelines were set and backlogs built properly.
- Work prioritization. Better prioritization led to a better understanding of the workload.
- Improved releases. Release days now go much more smoothly.
“We have seen dramatic results in just two weeks. The difference in our releases is really night and day. You know things are running smoothly when you don’t even realize it’s a release day.”
Jaron Wilkins, Project Manager