Learning to be an Agile manager — Part 3: Continue — A disruption in routine, SURPRISE!

This is Part 3 in a series on lessons I have learnt as a line manager for Agile teams. It takes the form of the “continue-stop-start” approach often used in retrospectives. See Part 1: Release Trains for background.

Around the time that Scrum was introduced the team viewed Dan Pink’s Ted Talk on motivation. In the talk Dan refers to Atlassian’s “Fedex-day”, the team wanted to do something similar.

A “Fedex-day” is a 24 hour, develop what you want and show your work to a group of interested people.

The first event was held a little over 3 years ago. The guidelines used for the first event resembled Scrum practices, ideas must have business value, 2 Sprints of 12 hours, work in a teams, have a groomed backlog at the start, use a predefined definition of done and a business stakeholders review after 24 hours.

After 24 hours 12 team members, delivered 5 demonstrable ideas with business value. The COO was the sponsor of the event and was the only business stakeholder at the review. Unfortunately, only one of the ideas was eventually implemented in production, this became the measure of success.

The intention of the guidelines were to accelerate learning with Scrum and to safe guard the “Fedex-day” concept from being see as a waste of time by business. Software people generally have a sense of pride in their work and want to let the world see it, they therefore spend the 24 hours wisely. If you can manage to keep your need to control the outcome at bay they will always pleasantly surprise you.

In subsequent events a business stakeholders review after 24 hours and participation is voluntary were the only guidelines that remained. The business stakeholder review was opened to anyone who is interested. The next event delivered more ideas and a larger percentage of the ideas were implemented in production. The concept gained traction at same time as the Scrum transformation gained some momentum.

Speed Recruiting

By the third event Product Owners started to influence team members to implementing ideas that they believed had business value, but was difficult to demonstrate without investing a little time to demonstrate. In a survey team members indicated that they valued ideas from Product Owners, as long as they have the freedom to make decisions on the implementation. By the fifth event “Speed-recruiting” was born, similar to “Speed-dating”, but for business.

The intent was to encourage a larger group of people to take part, not just Product Owners. Anyone can publish a one paragraph brief of their idea on a wiki for the purpose. The Idea Owner is then given a 2 minute slot to pitch the idea to team members, team members express interested to learn more by adding their names to the wiki post. A 30 minute meeting is then setup between the Idea Owner and interested team members to explore the idea. Team members the decide if the want to sign up to help implement the idea during the event.

More ideas were generated this way and the event received broader participation MIS, actuarial and other business team members participated in the subsequent event.

Rewarding Innovation

The CEO launched an innovation initiative with a prize for the idea implemented with the most business value. A number of ideas were generated and presented at a management forum, but none of then were unique and new enough to secure the prize.

Ideas from the “Fedex-day” events were not presented in the forum, but one of the ideas implemented through this platform caught the organisations attention.

A more effective way of dealing with claims that result from catastrophic events, this is typically things like hail storms or floods. The idea was implement in time for a significant hailstorm in 2014. It improved the way customers logged claims, it reduced the time to respond and to assess the impact of a catastrophic event. This resulted in cost savings resulting from fewer calls to the call centers and through enabling the claims team to engage services suppliers before the competition.

In the words of the CEO “it is World Class”. The CEO decided to awarded the innovation prize to the team that implemented the idea.

The value of the event for Scrum Transformation

The event was started expecting it to encourage innovation and provide a break from the routine Sprint cycle. It had a number of unexpected benefits.

In the organisation software development was seen as an “IT” responsibility, business process and innovation in this respect a business responsibility. These events help to change this perception faster, day-to-day Scrum Team (team and Product Owner) interaction can have a similar effect, but these events accelerated the change. This in turn improved Scrum teams performance and supported the transformation effort.

In one event the Head of Legal (Product Owner — Correspondence) decided that she wanted to pair program with team members to better understand “why things take so long”. Unfortunately other responsibilities during the day took up her time, but she still spend some time doing JavaScript tutorial on Codecademy during the event and developed a little more appreciation for the nature of software development.

The events had an influence on the team dynamic and culture within the larger development team. To work closely with team members under pressure and really tried helps to strengthen bonds of friendship.

Trust your team and you will always be pleasantly surprised.

Periodically disrupt routine, what you learn will surprise you.

This is part 3 of 6 in a series, See Part 2: Agile Sub-culture or Part 4: Continue — Let the team grow itself, hiring.