Our agile journey so far – Part 3: You build it, you run it, you love it

On 15-05-2017
Category: Blog, Culture, Development

Our agile journey so far – Part 3: You build it, you run it, you love it

  

This is the third post about our growth story. In the last blog post we elaborated on some necessary steps to take in an organizational change. We have explained that the steps bol.com has taken are very much in line with John Kotter’s steps. In this post we will have a closer look at the process in the spaces. 

This post is written by Roy Gielen, an agile enabler who interviewed several persons at bol.com on this topic. We want to thank him for helping us to put our story on paper, making it possible to share our journey with you!

You build it, you run it, you love it!

 (by Roy Gielen)

We’ve already seen that bol.com introduces autonomous teams that work together in spaces. Every space is responsible for its own fleet and decides what to build, how to build and run it and how to love it. These three steps are translated into a slogan called: YBIYRIYLI: You build it, you run it, you love it! Bol.com chooses to pilot this strategy in an agile way and every step brings the company a bit closer to the moon.

What if …

They start with two scrum teams to test the new way of working. The first job of those two teams is the what if … phase. Mihaela, scrum master of one of the teams, tells me: ‘We asked ourselves some questions. What if we could deploy our own material to production when necessary? What if we move from a periodic release to a continuous delivery model? What if we could release every four hours instead of every four weeks and deploy our own stuff to production, wouldn’t that be cool?’ This disruptive way of thinking with a clear but ambitious purpose is essential to break old habits and processes and make progress in the trip to the moon.

These two scrum teams are the first teams that have to dive into the asteroids! Mihaela: ‘When starting this initiative it is important to know your important stakeholders: the business, the system engineers and the developers. It is important to earn everybody’s trust to make a success out of it.’ You can imagine the system engineers found pitching this idea to these groups the most anxious and doubtful part about this change.

You build it

As we’ve seen, the YBIYRIYLI has three phases. Phase one (you build it) is the phase in which the idea is piloted. In this phase, the two scrum teams get access to the production environment and the operational engineers (ops team) are their back-up. The most painful change for the ops team is that they will ‘lose’ their control of the production environment because they don’t need to put stamps on approvals for changes and incidents anymore.

In this phase, one of the most important things the team realizes, is that they need to work together closely, to attach and to bond. This phase of team formation is a starting point for the other phases, because it is important to create a baseline of trust. Trust can be earned in three ways: get rid of the barriers between the teams, have a ‘one goal strategy’ and prove with piloting that this will work.

The scrum team earns its first trust during the introduction of the fingerprint identification on mobile apps. One of the two pilot scrum teams is the mobile app team. This team showed the other teams you can build and deploy a solution as a cross-functional team in the mobile app in a very short period.

You run it

Phase two (you run it) is the phase of full control. The scrum teams don’t need any approval from the operations teams anymore and are fully responsible for the products they build and deploy. So when an issue pops up in production, it is the team’s task to solve it. This is a big mindset shift for the scrum teams. The issue cannot be solved by only implementing these technical practices, they also need to focus on people, collaboration and mindset for a successful DevOps implementation. So now the teams need to monitor their own environment and products and also solve issues when they pop up. This is a heavy phase because of two reasons:

  1. The scrum teams need to learn skills how to maintain, monitor and manage as if they are a system engineer. It is a new way of thinking for a developer and in the beginning it feels awkward.
  2. The teams need to adopt new skills and a new way of working. They get new responsibilities while the organization still expects the team to build new innovative products as well.

To make sure the teams stay motivated, bol.com applies one of the eight steps of Kotter’s model: celebrating quick wins. Although they are still learning in the end of phase two they reach the moon! They celebrate this with certificates for the first astronauts on the moon.

Convincing other teams

By testing the new way of working in a small group (two teams) and small chunks of functionality they convince themselves that it’s working: it is possible to deploy software in less than four weeks! Based on this experience, the two scrum teams go storytelling to the other teams to make them realize that they also need to change and why. Employees telling other teams how they think they should work, based on facts and experience, is a great step in a company. It has much more impact than a not very knowledgebale manager who tells his subordinates how they should work. This is the most important part of a learning organization. Like Menno Vis, IT director software development at bol.com, says: ‘It is driven by employees, endorsed by management and engaged by the business.’

You love it

In the third and last phase (you love it!) more teams get aboard and land on the moon. Because the teams work autonomously, every team can choose its own tools and can focus on fine-tuning all processes and software to turn it into a smoothly running machine. In this phase they also have the goals to include the business more about functional monitoring. They have automated tests in place to support the continuous delivery model. In this last phase, everyone at bol.com is loving how they work: more people, more releases, more user stories per team and less incidents.

Until now, we’ve seen a lot about the processes and strategies bol.com uses to be able to work agile in a large and growing company. But one of the most important parts of a company is, of course, the people. How does bol.com make sure the employees are happy and stay motivated? That will be the subject of the next post.

 

About the writer

Roy Gielen is an agile enabler, personal coach and change manager at Ctree BV. He is currently studying for an MBA and writes about successful responsive organizations. Thanks to this combination of skills he guides organizations and their individuals in their journey to responsiveness, keeping in mind that every change starts with the individual. He future proofs organizations so they are ready to adapt in this fast changing world.