Leading agile change

7 ways to effectively manage an agile transformation

This article was originally published on Emerce (Dutch), and is also available on LinkedIn (Dutch) and Medium (English).

Managers who ask: “Why are we not speeding up?” Teams who say: “We keep on explaining the reasons we are being held back, but nothing changes.” “Great that we are now a self-organizing team, but it’s still the managers who are calling the shots.” Just a few remarks from the employees of a large financial institution that implemented agile. Do you recognize this? In this article, you will learn about the 7 characteristics of a successful transition team and what you need to do to ensure that your agile transformation will run smoothly.

It doesn’t happen by itself

Just like many other companies, the financial institution had realized that their way of working was no longer able to meet the requirements of this day and age. Slow procedures, low motivation, disengaged staff. They decided to implement the solution that everyone was talking about: Agile. Working with self-organizing, multi-disciplinary teams should save the company from going down. When the changes did not have the expected effects, the CEO asked us for help.

Unrealistic expectations

During our talks with management and with the teams, we discovered there was a lot of frustration. The teams did not know what the objectives were and why the changes were necessary. At the same time, the managers didn’t understand why things weren’t moving faster. Agile was seen as a silver bullet that would lead to improvements straight away.

“We trained everyone, we instated a project leader, implemented the transition plan which we carefully monitored through the steering committee. But still, we aren’t seeing the teams accelerate and we aren’t seeing an improved bottom line”- member of the steering committee

Start at the beginning

We have helped many different organizations with agile. Most of them apply it in their IT department, others use it for their marketing and growth teams. We see many similar challenges. An agile organization requires a different kind of leadership, a transition team (T-team) that functions well is essential. When we put a transition in motion, we always make sure the following seven requirements are in place:

“We’ve implemented Scrum, but it is unclear to me why it was necessary. All those extra meetings cost a lot of time. It’s a hype, it will pass.” — team member

1. Define your “awesome” end-state

Becoming agile is not an objective in itself. Agile is a method that you use to reach a certain goal, and that goal needs to be crystal clear before you start. Common goals are: shortening the time-to-market, becoming better at dealing with change, more innovation, increasing quality, less bureaucracy, bringing more energy and fun into teams, increasing commercial effectiveness, staying ahead of competition. Make sure the rest of the organization knows why your vision is important and what your “awesome” end-state looks like. By making the goals measurable, you can also make a fact-based assessment of how the transition is going. Just like when you’re trying to lose weight, you weigh yourself often so you know if you are on the right track to achieving your goal.

“We have explained very often that we can’t speed up because we are dependent on another department. But it seems nothing is being done to change this situation.”- team member

2. Remove impediments

Every team will run into impediments while implementing their new way of working. Examples of such impediments are dependencies on other parts of the organization, political games, unnecessary rules and procedures, unsuitable reward systems, conflicting goals. The transition team’s most important task is to take away the impediments that the teams cannot take care of themselves. You are the A-Team that comes to the rescue when they get stuck.

“My experience is that the biggest speed killer is us, the management, because we keep behaving in the old way. The largest change that needs to happen probably needs to happen within myself.” — a manager from the transition team

3. Don’t be the bottleneck

We often see that leaders think the staff needs to change. “If they implement Agile, our problems will disappear overnight.” However, the following is true for every change: leaders go first. In order to become agile, a change in mind-set and behavior is necessary, this includes the management team. As T-team you are the enabler of the transition, not the driver. Stop micromanaging and rethink the way you keep a handle on things. Make sure you don’t act like a steering committee that says: “You should change”, but instead, send the message: “This is the direction we would like to be headed. What do you need to get there?” That way, you remove the gap between management and staff.

4. Lead as an agile team

Do not underestimate the power of leading by example. When the T-team adopts an agile way of working, you show people that you believe in the change and that you understand what the new teams are going through. Work in sprints, do daily stand-ups, give a demo, keep your own backlog in a visible spot. By holding retrospectives, the T-team becomes a well-oiled machine that is constantly improving. A safe place where members are open to each other and are able to express their doubts.

5. Have a team that can make an impact

Make one member of the transition team responsible for keeping track of the backlog; this person takes the role of product owner. This person does not have to be senior in rank, but he/she should be the one leading the transition. Additionally, the transition team also has an agile coach, who facilitates the team’s working process.

When it comes to removing impediments, you need people in your team who are able to do so quickly and effectively, for example the managers of the employees in the teams. It is also important to have a sponsor from senior management, who can join the team regularly and take away any impediments. Structural impediments do not disappear by themselves, it costs time to solve the issue properly. T-team members must have sufficient time available to make this happen.

“It is great that we are being asked what we need to make more impact. I get the feeling that management is now working for us, rather than the other way around”- team member after visiting the T-team demo.

6. Be transparent and ask for feedback

The transition team should present their results regularly in the form of a sprint review or demo. In this event, you present which steps you took, still have to take and which changes and obstacles you see ahead. Show what works, and don’t be afraid to show what doesn’t. Don’t forget to ask for input: “Do you feel that we, as a transition team, are doing the right things?” The management does not always have the answer to everything, and when you don’t have the answer, stop having meetings about it but quickly bring your challenge to the agile teams for advice.

A demo is a good time to continue the conversation about why the changes are important for the organization and what the end-goal is. This creates clarity, which helps to reduce stress.

7. One step at a time

For a sustainable change, it is best not to turn the whole organization around in one go. So focus on the most important issues, create short-term successes and gradually move to bigger things. Experiment and find out what does and what doesn’t work in your context. So no “big bang”, but “inspect & adapt”. By dealing with the changes team by team, you will be slowly permeating the old organization, until you reach a critical mass and “the others” will be forced to join the change. Be patient: it can take months or years for the culture of an organization to transform.

*Co-author Timo Mulder: founder & managing partner of Value First. He helps growth companies and corporates to speed up their innovation and marketing teams using agile and lean startup techniques. Together, Timo and Jurriaan have helped more than 200 teams and 30 organizations make a bigger impact.

Hackathon: spitsstrook voor innovatie

Dit artikel werd gepubliceerd op AG Connect, en is ook beschikbaar op LinkedIn.

Vrijwel alle succesvolle techbedrijven doen hackathons. Het is de manier om innovatie te stimuleren. Ik woonde de laatste hackathon van bol.com bij. Die dag konden ongeveer negentig techneuten zelf bepalen waar ze aan wilden werken. En als mensen werken aan iets wat ze zelf graag willen, ontstaan de mooiste dingen.


Het komt niet vaak voor dat je op je werk volledig vrij bent om te bepalen wat je doet. Meestal is er een manager die de plannen goed- of afkeurt. De tijd die je eraan besteedt, moet namelijk wel iets opleveren. Dat is ook logisch, want geld kun je maar één keer uitgeven. Dat verklaart ook waarom er strakke procedures bestaan om initiatieven, projecten en doelen tegen het licht te houden. Maar hierdoor wordt wel de drempel verhoogd om spontaan iets te doen wat je leuk vindt. Met een hackathon open je een soort spitsstrook, zodat je om de file heen op de snelweg kunt rijden.

Met hackathons maak je gebruik van collectieve intelligentie

Je bent als management nooit slimmer dan de tientallen of zelfs honderden andere mensen die in het bedrijf werken. Met een hackathon maak je gebruik van de collectieve intelligentie, want mensen kunnen zelf kiezen waar ze aan willen werken. Zo zorg je ervoor dat de intrinsieke motivatie, de passie voor het vak en de nieuwsgierigheid van mensen zichtbaar worden.

Wat levert het op?

Tijdens een hackathon werken mensen aan dat ene dingetje dat ze altijd al hadden willen doen, maar waar ze steeds niet aan toekwamen: iets wat nu echt opgelost moet worden. Daarnaast wordt er geëxperimenteerd met nieuwe technologieën en geleerd van vakgenoten die verspreid in de organisatie zitten. Want tijdens een hackathon helpt iedereen elkaar.

Omdat mensen aan het eind van de hackathon presenteren wat ze hebben gedaan, kun je er volledig op vertrouwen dat mensen hun tijd goed besteden. Bovendien: de hackathon hoeft niet meteen iets op te leveren. De inspiratie en motivatie zelf zijn al waardevol genoeg om het te doen.

Hoe organiseer je een hackathon?

Hackathons zijn er in verschillende soorten en maten. Van één werkdag op kantoor tot een volledige ‘hackweek’ op een externe locatie. Om draagvlak te creëren is het de moeite waard dat mensen uit de business de uitdagingen presenteren waarvan zij hopen dat iemand er iets aan kan en wil doen. De techneuten kiezen vervolgens zelf of ze aan een van deze initiatieven willen werken. Lees meer over hoe SpotifyFacebook en Uber dit doen.

Een simpel format voor een succesvolle hackathon is:

  • plan een dag in, nodig mensen uit;
  • zorg voor eten en drinken, muziek en sfeer;
  • bepaal een thema of definieer een business probleem (optioneel);
  • plan een demo;
  • evalueer wat wel en niet goed werkt, en plan de volgende.

Zo simpel is het. En is het alleen iets voor IT'ers? Zeker niet. Iedereen kan meedoen, ongeacht rang, stand of functie. Je hoeft ook niet per se software te maken; een goed idee uitwerken naar een prototype van karton is ook nuttig.

Agile CIO richt zich op het toekomstvast en wendbaar maken van organisaties door de best practices van bedrijven als Spotify, Google, Facebook en Airbnb toe te passen. We organiseerden hackathons bij o.a. Digidentity, Mijndomein en Aegon.

Hackathons at bol.com

This article was originally published on the bol.com blog, and is also available on Medium and LinkedIn.

"You hack it, you love it, you run it" is printed on a big sign above the canteen at bol.com's office in Utrecht. It's time for the hackathon, which is held three times a year.

Today, about 90 engineers are completely free to decide what to work on. "When you sign up for the hackathon, you mention what you're planning to do so you can form a team, but no manager has to approve it," says Maarten Dirkse, who started organizing the hackathons three years ago.


The hackers are all relieved from their duties; nobody will bother them today with regular work. The hackathon starts at 09:00 and lasts until 20:00. Lunch and pizzas are arranged, and at 17:00 the bar opens (just like every Friday).

"It's a really fun event in which you can build anything you've always wanted to build, but couldn't find the time for. It doesn't necessarily needs to be something useful for bol.com, although we do take suggestions from the business." Maarten continues. "People tackle a problem that bothers or motivates them. My favorite is an internal dashboard that shows beautiful statistics on today's revenue. It also plots new customer orders real-time on a map of Holland."



Hacker Mary Gouseti is a big fan of the hackathons: "it's a great way to learn new skills and experiment with new technology. It's also nice to work together with engineers from other teams that you normally don't work with. Everybody helps each other out. My favorite project is the "Translate to English" button, which allows non-Dutch speakers like me to browse bol.com in English."

"Several projects resulted in visible improvements and innovations for our website or mobile app. But even if an initiative can't directly be translated into business value, it does inspire and motivate the engineers, which is just as valuable" says Menno Vis, IT Director Software Development. 

"After the hackathon, we organize an award ceremony for which we invite the whole company. The hackers present their results in a 3-minute pitch. We have prizes for the coolest project, the project which has the most value for bol.com and for the project which is the most 'out of the box' or funny. Real working demos usually score more points than PowerPoint slides" Menno continues.

Another noteworthy event is the yearly "polish night". During this event, about 500 colleagues voluntarily work until late at night to get the site ready for the holiday season. They clean up a whole bunch of glitches in the product content to improve the shopping experience. Of course, music and drinks are provided.

The hackathon is just one of the things that defines bol.com's engineering culture. Management supports and encourages bottom-up initiatives and regularly asks employees to pitch ideas for new projects. Menno: "our philosophy for sustaining a high performing IT department is quite simple. Get the right people on board and give them the right assignment. Encourage them to take ownership and ensure autonomy at the lowest level in the organization. Provide freedom within a framework, high autonomy and high alignment. Just like our services: loosely coupled but also highly cohesive!"

Hackathons are a great way to inspire innovation and motivation by reinforcing autonomy, mastery and purpose. Bol.com gets this, just like Facebook, Spotify and Uber who conduct hackathons at regular intervals.

13 kenmerken van agile organisaties

Interview in BaaS magazine - boardroom as a service (in Dutch). Download as PDF, or see below.

Agile? Besturingsmodel aanpassen!

Veel organisaties worstelen met hun schaalgrootte en complexiteit. Dat maakt het moeilijk om bij te blijven in de snel veranderende digitale wereld. Alleen zij die snel kunnen reageren, innoveren en leren kunnen overleven. Door over te stappen op een agile operating-model wordt het mogelijk dit te bereiken. Echt overstappen naar Agile betekent wel een verschuiving in de principes waarop de organisatie gebouwd is, zo betoogt Jurriaan Kamer, verandermanager on oprichter van Agile CIO.

Agile is bepaald geen quick-fix, maar een totaal andere manier van werken. De boardroom moet meeveranderen, anders gaat het niet vliegen. “Agile gaat verder dan het neerzetten van een paar Scrumteams op de IT-afdeling”, zo stelt Kamer. “De werkwijze moet ook niet slechts gezien worden als een alternatief voor Prince II. Het is een fundamentele herziening van 20e eeuws Tayloriaans managementdenken (massaproductie, economies of scale, efficiency, planning, control, hiërarchie en vaste rollen, red.) naar een systeem dat geschikt is voor de uitdagingen van het huidige tijdperk: innoveren door te experimenteren, excellente klantervaring, organiseren rond gemotiveerde autonome vakmensen. De omstandigheden van vandaag vragen om een andere aanpak, en de bestaande processen, structuren en gedragingen moeten op de schop.”

Er wordt heel veel over Agile gesproken, maar het wordt vaak verkeerd begrepen of verkeerd uitgelegd. Kamer: “Het is niet zomaar wat aanklooien zonder regels. Het is zorgvuldig gekaderde vrijheid. Op veel IT-afdelingen wordt aan ‘fake agile’ gedaan. Vaak lukt het niet om de beoogde voordelen eruit te halen omdat agile wordt geplakt bovenop het bestaande systeem van bureaucratie en corporate hiërarchie. In werkelijkheid verandert er dan niet zoveel, of ontstaat juist een slechtere situatie dan voor de Agile-implementatie.”


In Silicon Valley ging Jurriaan Kamer op zoek naar de verschillen in het ‘organisatie-DNA’ tussen traditionele corporates en ‘digital-first’ agile bedrijven. Na zijn bezoek aan Google, Apple, Facebook, Twitter, LinkedIn, Airbnb en Spotify concludeerde hij dat een rijtje van dertien zaken het verschil maakt:

  1. Door het beste product te maken voor de klant volgt geld verdienen vanzelf. De focus ligt op 'product excellence’ in plaats van op de business case en het maximaliseren van aandeelhouderswaarde.
  2. Het management faciliteert in plaats van dat het top-down stuurt: de manager is niet de baas, maar heeft als taak om de juiste context te creëren zodat de medewerkers en teams kunnen leren en groeien.
  3. Managers blijven op de hoogte door direct met de vakmensen te praten die het werk uitvoeren, in plaats van dat ze gedetailleerde rapportages eisen.
  4. Mensen communiceren rechtstreeks in plaats van via escalaties en managementlagen, problemen worden door mensen zelf opgelost, managers zijn alleen bezig met het oplossen van problemen die hun medewerkers echt zelf niet kunnen oplossen.
  5. Managers zijn zelf ook inhoudelijke vakmensen, zodat de kans op verkeerde beslissingen afneemt; er zijn geen middle management lagen die alleen een proces managen maar weinig van de inhoud weten.
  6. Het hogere management is volledig transparant over strategische doelen, resultaten en uitdagingen, zodat de medewerkers beschikken over informatie die nodig is om te kunnen bepalen wat goed is voor het bedrijf.
  7. Teams hebben autonomie om zélf te bedenken wat de beste aanpak is om het doel te bereiken waarvoor ze  verantwoordelijk zijn; de autonomie wordt bereikt doordat ze zo min mogelijk om toestemming hoeven te vragen.
  8. Fouten maken wordt getolereerd en zelfs gestimuleerd; het management snapt dat teams sterker worden door (gecontroleerd) op hun bek te gaan.
  9. Er zijn geen projecten en projectmanagers meer, want het werk wordt naar mensen gebracht in plaats van mensen naar werk; waarde wordt gerealiseerd door continu meetbaar te optimaliseren, in plaats van door een project te doen met een kop en staart. Budgetteren gebeurt op basis van vaste constante teams die hun eigen waarde aantonen.
  10. Nieuwe businessmodellen worden al experimenterend ontdekt samen met de klant, aannames worden getoetst en initiatieven worden niet gestart op basis van ‘gut feeling’ van het management.
  11. De agile-bedrijfscultuur is sterk en zorgt voor het juiste gedrag: vertrouwen, samenwerking, openheid, transparantie, respect en waardering in plaats van hiërarchie, compliance, controle en rigide processen.
  12. Elk bedrijf heeft z’n eigen structuur die ontstaan is door deze iteratief te verbeteren; de structuur wordt niet bepaald door een extern framework (zoals bijvoorbeeld SAFe).
  13. Vakmanschap en werkplezier staan centraal, bedrijven zijn hierdoor in staat om de nieuwe generatie toptalenten aan te trekken en te behouden.


Om deze kanteling te maken is het noodzakelijk dat het topmanagement deze verschuiving begrijpt, doorleeft en omarmt. Vervolgens kunnen ze de organisatie in staat stellen om deze verschuiving door te maken. Als dit niet gebeurd is blijft het voor bottom-up agile initiatieven onmogelijk om door de organisatiebarrières heen te breken en te gaan vliegen.


Do we still need managers?

Below are my slides from my presentation at Scrum Day Europe.

Slides from the presentation at Scrum Day Europe, 7th of July 2016 in Amsterdam.

Text from the booklet:

Many companies have implemented Scrum and are “doing agile.” However, many companies struggle to achieve the expected benefits. The management team has implemented scrum and then expects a miracle to happen. However, often they have failed to embrace the true nature of scrum and especially forgot the part that talks about creating self-organizing autonomous teams. Agility isn’t a gem that can be bought; transforming your operating model to become future-proof is a difficult task. It’s not just a small update, it’s a major overhaul of how your organization operates. Agile is not just a framework used in the IT department; becoming truly agile requires a digital transformation of the business and other departments like HR, finance, and operations. You also have to overcome organizational impediments like anti-agile company culture, top-down leadership behaviour, counter-productive organization structure, and approval processes. Only top management can enable this shift. If we look at some the Silicon Valley-style digital first organizations, we discover that these companies still heavily rely on managers. However these managers do something completely different than the ones we find in traditional enterprises. In my presentation we’ll dive into some of the learnings from how management works in these companies.


Old-Style Project Management Is Broken — Here’s How to Fix It

This article was originally published on Switch and Shift, and is also available on Medium and LinkedIn.

In fast-moving industries, innovation hinges on a company’s ability to move quickly on new ideas, meaning hierarchical corporate structure is on the road to extinction. Project managers are in the passenger’s seat, traveling on the endangered list.

Businesses typically organize themselves into siloed departments responsible for executing specific, repeatable tasks, but when the business needs to undertake a change or improvement, it creates a project. The project manager gathers a temporary team with members from different departments who work together to successfully deliver the project.

These specialists are already assigned to multiple projects, so department heads are reluctant to assign these scarce resources to yet another. Time is micromanaged in order to maximize productivity. The result is a project that mostly consists of coordinating and waiting for specialists to align. This confusion can lead to a slow, bloated mess.

When ING Bank started its transition toward agile management, it used a small project of only 1,500 man-days to baseline its performance. In all, the undertaking lasted 11 months, and no fewer than 47 employees across 25 departments were involved. Delivery planning was seen as unreliable, while expertise, infrastructure, and specialization were all perceived as fractured. The cost of delivery of even something small turned out to be highly uncompetitive.

This example painfully illustrates that the old model of project management, still prevalent in many large organizations, is broken. Agile organizations use a different model that renders project managers obsolete.

The Project Management Revolution

Digital-born companies in Silicon Valley such as Facebook, Spotify, and Airbnb don’t employ project managers. Why? Because they understand change is continuous, and they have built it into their DNA.

Instead of assigning specialists to time slots and batches of work, these corporations rely on self-organizing teams composed of people with multiple disciplines. Rather than move people to work, they let work flow to fixed teams.

Without irrelevant deadlines and sprawling oversight, the teams are free to innovate and collaborate. This not only gives the company stability rarely seen in more structured organizations, but it also empowers employees and conveys trust in their abilities.

As opposed to temporary project teams in which members tag in and out, stable agile teams can mature through continuous improvement to unlock the group’s full potential. Strong teams can attack any problem. While Twitter’s senior vice president of engineering, Chris Fry put it this way: “Build strong teams first; assign them problems later.”

Moving Away from Project Management

So what does this concept look like in action? Do you just put current project managers out to pasture? Not necessarily. Former project managers can take on several new roles, including:

  • Scrum master/agile coach: The scrum approach favors collaboration and self-organization over traditional project hierarchy. The scrum master facilitates the team in its agile way of working and focuses on improving collaboration.
  • Product owner: The product owner keeps his or her team focused on the overall vision and is responsible for guiding the team in the right direction, toward building the right product with the right features.
  • Manager: Self-organizing teams plan their own work, manage their stakeholders, and optimize their workflows based on need. Units don’t need someone watching over their shoulder to make sure they’re working correctly. Therefore, in an agile context, the manager mainly takes a hands-off human resources role.

He or she uses a coaching leadership style to develop and retain the team’s talent and craftsmanship. As opposed to traditional companies, agile companies require their managers to have hands-on experience with the specialism they’re managing. Airbnb even goes so far to require newly hired managers to contribute code for six months before they can start on their managerial roles.

Many people think companies with self-organizing teams don’t need managers anymore, but that’s a misconception. Managers at Spotify, known as chapter or tribe leads, have no more than five direct reports. They see their people as top athletes, and to best aid their development, each coach can focus on only five athletes at a time.

Making the Transition

Of course, not everyone will be pleased with an organizational shift. Middle managers who built their careers by solving problems through micromanagement will struggle especially.

In “Coaching Agile Teams,” author Lyssa Adkins writes that managers must learn to let go of “command-and-controlism.” This “deprogramming” of the mind is tough, just like any behavior change.

But the advantages of transitioning to agile management far outweigh employees’ growing pains. The focus on craftsmanship and mastery will spur professional growth and fulfillment, and employees will take ownership of their work. Moving up the hierarchy should no longer be the preferred path because agile companies have created alternative ways to define career growth.

Agile companies are organized to minimize projects, but sometimes a project is unavoidable when an endeavor requires coordination effort across the organization. Project management skills are still needed, but their days as a full-time role are numbered.

According to Adkins, leaders need to change our fundamental beliefs about projects because we’re moving from the Industrial Age to the Age of Complexity. Planning the work and working the plan doesn’t work anymore. We need instead to embrace complexity by accepting that plans become accurate over time through constant revision.

Delivering on time, within budget, and on scope no longer equals success. Instead, the only measure is clients receiving the business value they need. Throw out the old project management system, and embrace the era of agility.