4 Software Delivery Mistakes Blocking Your Continuous Delivery

If you ask five experts to define Continuous Delivery, you’ll get six different answers. The responses will range from continuously merging code to a shared repository (i.e., Continuous Integration), to the use of modern delivery tools to manage discrete parts of the pipeline (e.g., provisioning, testing, and deployment), all the way up to delivering multiple releases per day to end users of an application.

But no matter how you define Continuous Delivery, the ultimate goal is to continually ship high-value software to your users. Unfortunately, many organizations are their own worst enemies in this regard.

Below are 4 common mistakes that organizations make when trying to do Continuous Delivery.

1. Focusing on development-centric processes instead of the whole release-to-production pipeline 

But it works on my machine!

Ok, so we can still laugh at this timeworn sentiment—at least when it happens during demos at the end of a sprint. But it’s definitely NOT a laughing matter when a major glitch happens right before—or during—Production launch.

This mindset also might signal that the neither the Development team, nor the organization as a whole, is thinking about software delivery beyond the Continuous Integration stage.

For example, doing a deployment in a testing environment is completely different from deploying to Production. They may seem the same from a technical point of view, but from a process perspective, they are vastly different. Organizations that try to scale their Continuous Delivery implementation through build automation alone will have a hard time achieving success.

Why? Because delivering great software frequently—and at scale—requires adopting a holistic approach on the part of all stakeholders, one that takes into account that the entire pipeline, not just Development, must work as a well-tuned delivery system. A successful Production deployment requires much more than getting the code right in Development. Writing great code is important, but so is:

  • Aligning Development efforts with other parties, like Marketing and Product Management, to understand whether what you’re developing is creating business value
  • Integrating compliance into your pipeline to ensure that you’re adhering to regulations and keeping an audit trail
  • Implementing proper security settings for the application in Production to protect your data and your customers
  • Configuring and managing all operations activities needed to run software successfully in Production, such as changing firewall settings, configuring load balancers, and updating procedures and other paperwork

If your team is focused solely on improving the Continuous Integration side of Continuous Delivery without looking at the whole release pipeline, you will soon hit a wall.

2. Not aiming to deliver software daily

Your developers and product managers might not think that striving for delivery every day is important. They may be used to patterns of work such as hardening sprints, or delivering on a quarterly basis, but these habits can actually hold your team back.

Having a lot of work in parallel and only integrating code at the end of a quarter or a cycle means that merge and functionality conflicts won’t appear until late in the process when problems are harder to fix. While extensive hardening is necessary for verifying all differences, full integration every day or night will help you catch issues quickly. Doing so is vital to the quality of your system.

But more importantly—discovering problems early contributes to your learning cycle. If security vulnerabilities or code smell is introduced, it’s best to have a fast feedback loop to your developer. Integrating continuous testing that runs either daily or nightly will help you avoid making the same mistake twice.

From a cultural perspective, breaking through resistance to daily delivery is not the easiest thing to do. Deep organizational transformation is sometimes required, not only in engineering but also in other parts of the organization.

For example, if your Product Management team is used to two to four deliveries a year, switching to a model with smaller, more frequent deliveries can be really difficult. You have to transform your secondary processes to achieve a goal like this, processes for things like the yearly budgeting cycle, the appraisal and hiring system (which might be very rigid), risk management (which requires enormous effort) and keeping the control framework up to date. Simplifying these processes is hard, but to achieve faster delivery, it’s a necessity.

3. Focusing on the technical pipeline and tools, not the business result

It’s tempting to think that software delivery is all about technology and tools. Unfortunately, those who think this way tend to focus primarily on optimizing software development rather than on all the pieces that come before and after code has been written. As a result, they miss opportunities to maximize the value of that software to customers. Taking a technical approach to Continuous Delivery may be ok for a while, but it will not help you drive more value continuously.

Software delivery is first and foremost a business endeavor involving everyone in the pipeline from Design, Engineering, and Operations to Marketing and Sales. All the people, tools, tasks, and processes exist to drive business value. Harmonizing all these pieces requires expanding your approach to Continuous Delivery from development centered to business-value-streamcentered.

Your goal is to deliver value with your software, time after time. You can automate tasks, but unless business-focused orchestration is driving your pipeline, you won’t be able scale software delivery for your enterprise. Focusing only on the technical aspects of CI/CD will only get you so far. To truly succeed, you need to be laser-focused on the business value of each feature and how it is progressing through each stage in the pipeline.

4. Delaying integration, security, and performance testing until later in the cycle

Finding integration, security, and performance issues just before releasing software is much more expensive than if you catch these issues sooner. And they are harder to fix! That’s because these kinds of problems usually impact the code base much more substantially than functional problems do. Integration, security, and performance issues often require rethinking the architecture because they are deeply entangled with the system. Setting up a continuous feedback cycle to your developers is worth the hard work because it helps you catch these problems early.

Fortunately, release orchestration makes it easier to integrate security and performance testing into the pipeline so you can get immediate results and catch problems early. Xebialabs, for example, offers off-the-shelf integrations with testing tools, such as Sonar, Fortify, and Black Duck.

Security Testing

Security testing has four sides. Three of them, static code scanning, third-party library scanning, and dynamic security testing, can be embedded into, and therefore automated within, your Continuous Delivery pipeline.

The fourth side, penetration testing, most of the time requires a specific environment to deploy to because dynamic security testing frameworks can ruin your complete application. Because penetration testing requires human intervention, a good practice is to run these tests on a regular basis. Some organizations, for example, do them at the same time every day, or run them consistently on a monthly, quarterly, or yearly basis. Others follow a more risk-based approach, and judge whether, based on the impact of the new code, a penetration test is required.

Performance Testing

Running performance tests every night is a good practice. In particular, doing Load testing using data sets that are similar to those of your customers is extremely useful for determining whether the day’s changes impact performance in a good or bad way.

Running extensive performance tests over the weekend may also be useful because you can see how the system behaves under stress. Weekends are a good time to run these tests because it’s usually less disruptive to Development. Performance tests also require a real-world environment, preferably with a customer-like setup. This is crucial for getting good insight in the actual behavior of the system.


Avoiding these four common mistakes will drastically improve the outcome of your Continuous Delivery initiative. To recap:

  1. Delivering software is not just about Development and its build cycles—teams need to optimize the complete delivery pipeline.
  2. Fast feedback cycles are vitally important to have in place, so your team can find problems early in the cycle before they propagate and while they are cheaper to fix.
  3. Focus on the delivery of value to customers time after time. This approach requires teams to create a pipeline that is focused on the business benefit, not just the technology.
  4. Put an extensive nightly build and test cycle in place; it will help you continuously improve the quality of your software and learn what matters for customers, and what doesn’t.

In the end, it’s delivering value to customers… and collecting revenue from it… that really matter.

I’ve posted this article originally at blog.xebialabs.com.

How to Unleash the Data in your DevOps Tools to Drive Continuous Improvement

Where are the weak spots in your software delivery chain? How are they affecting the value of the applications your company delivers? If you can’t answer these questions, you may be limiting revenue opportunities for your organization.

That’s because for most companies today, software delivery is the key source from which their value stream flows. So, continuously improving the end-to-end delivery process must be IT’s number one priority. The question is where do you start?

Maturity Models for Continuous Improvement

A quick Google search on “Agile Maturity Model” yields lots of results for how to drive continuous improvement. Some of them are based on educated guesses (but guesses nonetheless). The better ones are founded on questionnaires from a sampling of organizations, but rarely are they based on real data. These models will offer some insight in how to drive continuous improvement of your software process, but their effectiveness is limited, mainly because they’re not specific to your organization. For that you need real data about your own delivery process.

The good news is, if you’ve entered the era of continuous integration, deployment, and delivery, the data is probably already at your fingertips. You just need to know how to unleash it.

Read the full and original post at blog.XebiaLabs.com.

6 Reasons Why I Joined Xebialabs as VP Product Development

“VeePee what?” somebody asked at the camping site a couple of weeks ago. “I thought you where starting as independent consultant,” another person asked on Linkedin. These are valid questions considering that, before joining XebiaLabs, I was, indeed, ambitious to become an independent consultant and I had planned to start a new assignment in that role. So, it makes sense that my friends and colleagues would be totally surprised that, when XebiaLabs asked me to become their new VP of Product Development, I jumped at the chance.

But there are some really good reasons why I decided to work for XebiaLabs. Here are the top 6.

1. Xebialabs creates products that have a huge positive impact on their customers

I’m very motivated by what is possible. I love showing people what they can achieve within their organizations and helping them improve their systems so they can reach their goals. I intended to do this as a coach, team by team and company by company. However, by guiding the XebiaLabs development team to continually improve our products—XL Release and XL Deploy—I can still do this work but with a much larger impact. In my role at XebiaLabs, I’ll not only have an immediate, positive imact on the development team, but on all our customers throughout the world.

2. As VP Product Development I can be entrepreneurial

One reason that becoming an independent consultant appealed to me was that it offered entrepreneurial opportunities, especially as compared to working for a large organization. At XebiaLabs, I have a lot of responsibilities but also a lot of freedom in how to get things done. With around 120 colleagues, the company is small enough to be entrepreneurial but big enough to have a strong foundation to build upon.

3. Great company vibe

Combine a good vision, a clear purpose and great engineers and you get an excellent culture that’s creative, productive, and fun. This describes XebiaLabs. All this, along with nice coffee and good laptop and the right tools, makes XebiaLabs a great place to work.

forrester-wave-20174. Working for a front runner in the market offers an excellent environment for learning

I love to follow developments in the DevOps market and understand how IT is rapidly changing and accelerating. Working for Xebialabs provides an excellent opportunity to keep up with market trends as they apply to our own products and those from other companies.

5. My experience and coaching skills can help the development teams at Xebialabs

Despite the fact that I’m very positive, I realize that XebiaLabs is not heaven on earth. That’s why I love working for this company. With a little bit of coaching, our development teams can continuously improve, and people can strive every day to grow their knowledge and skills. I’m happy for the opportunity to put my coaching skills and experience to work for the good of my teams.

6. International, outgoing, startup

I like to travel because it lets me meet other people and experience other cultures. I also love to write, speak, and to be part of a flourishing company. These are the ingredients that put a smile on my face and a twinkle in my eyes.

I hope this answers why I think joining XebiaLabs was a great move to make. If you want to know more about me or my thoughts on the company and our products, please use the comments section below.

I’m looking forward many great days ahead with XebiaLabs.

Kind regards


Feedback loops will radically change your improvement cycle

Do you recognise the struggle of transforming your organisation? Where to start and what the aspects are that really make sense if you want to transform it into a high performing organisation? In this series of posts I want to address 5 principles that must be part of your organisational foundation and way of thinking. These are 5 crucial principles I’ve learned in the past few years from organisations that feel the urge to transform and are willing to make some sacrifices.

5 Crucial Principles that create the foundation of your high performing organisation:

  1. Flow in different forms is crucial to speed up your delivery
  2. Feedback loops will radically change your improvement cycle
  3. Strongly focus on the improvement of secondary processes
  4. Autonomy of teams cannot be given, it must be created
  5. The simplification of your products and processes will lead to faster value

Every post in this series will address concrete examples to find the principle in your organisation, an explanation why this principle matters during a transformation and finally, some practical suggestions to start today.

Feedback loops will radically change your improvement cycle

While we were young kids we learned to give feedback instead of having a fight if we disagreed. We’re grown up and it seems the older we get, the more we forget to apply this crucial principle in our work. We do not so often give feedback to each other or expect feedback from the systems around us.

This is strange because feedback between young kids will teach them to adjust their behaviour and improve in the system they are living.

In our environment outside our work there are many feedback loops built in. They have shaped our behaviour and the things we do. We have learned that a red light means we must stop. We have learned that if we see fire we know the candle or the gas cooker is too hot to grab. We see when our kids are ill or when our partner is angry. Feedback is all around us.

Some concrete examples

discoverSo, let’s go back to work. You are working somewhere in IT, in the business or in a company who already united both. What are the typical feedback patterns you should recognise? What is feedback in a large organisation? And what to do with this?

Feedback loops from your IT systems to your (DevOps) teams

This is an easy one, however, not used by many teams. Monitoring of your IT systems to receive useful information and insights in the behaviour of your system. Most of the time, teams have low level monitoring in place. Memory, CPU and disk space are carefully monitored. This is great because these insights can already help avoid the first wave of incidents which are fatuous.

To radically change your improvement cycle and stability of your systems you must go one step further. Measure the functional usage of an application. Can you monitor during the day and predict if the nightly batch will run successfully? Can you predict the number of users during the day, week or month and scale your systems accordingly? By understanding the impact of the users on the system you can design, develop and improve your systems based on what is really happening.

Feedback loops in the teams

This is probably the most obvious improvement cycle. However, this is hard to implement. Team who take themselves very seriously and want to improve take feedback amongst each other seriously. Stable teams and the confidence to say things out loud are crucial. A retrospective can be a useful instrument to have very frequent organised moments of feedback.

In their daily work, teams can give feedback to each other. When they are reviewing code, have a standup or simply discussing a new strategy. If trust is in place, feedback can flow and a conflict for the better is of great value. Continue reading

Agile Coach Labs: hoe oefenen met retrospectives op de vloer voor een andere dynamiek zorgt + downloads

Hoe is het mogelijk dat je na een drukke dag je toch nog een avond vol energie kunt hebben? Dat kan als de randvoorwaarden maar goed zijn. En dat was het deze Coach Labs opnieuw. Hoe kan het ook anders met 34 deelnemers die graag iets willen leren, twee totaal nieuwe oefeningen buiten je comfort zone, een perfecte organisatie door Wemanity en een mooie locatie met eten en drinken bij ING.

logo_coach_labsMet deze vier ingrediënten heb je de basis te pakken voor een geslaagde avond. En voor mij was het opnieuw een geslaagde avond. Hoewel ik de oefeningen al kende vallen er zoveel dingen op, worden er scherpe vragen gesteld en omdat je met veel ervaren coaches bij elkaar bent ga je wel twee spades dieper. De ervaringen zijn niet te vangen in een dure training, conferentie of webcast. En daarom speciaal dankjewel aan Maarten Tomassen die dit voor de 8e keer heeft georganiseerd.

Wat er gebeurt met een vloeroefening

Hoe vaak doe je een veilige retrospective allemaal weggekropen aan een andere kant van de tafel? Of met post-its waarbij gevoel en emotie in 3 of 4 woorden gevangen moet worden? Dit kan teams enorm vooruit helpen in de verbetering van hun proces en de basis samenwerking. Maar wat als je als team door wilt stoten? Wat als je wilt groeien naar diepere volwassenheid?

Een retrospective op de vloer waarbij je dingen gaat zien, voelen en ervaren omdat je veel te dicht bij elkaar staat kan dan best lastig zijn. En juist dit hebben we geoefend tijdens deze coach lab. Op basis van de transitie fasen van systemisch transitie management hebben we geoefend met wie waar staat, wat je ziet, en vooral wat je hoort als je in gesprek gaat. Sommige blijven achter in de transitie omdat ze simpelweg de urgentie niet voelen. Andere stuiteren vooruit op weg naar fase creatie.

Zomaar wat inzichten:

  • Een vloeroefening maakt (soms pijnlijk) zichtbaar wat we altijd al dachten maar niet durven te zeggen
  • Door mensen soms op een andere fysiek op een andere positie te zetten en ze van daaruit te laten kijken kan er al veel veranderen
  • Het is soms nuttig dat die scheiding van te tafel even tussen ons uit is, we komen dan fysiek dichter bij elkaar.


Observeren en luisteren is soms van meer waarde dan nuttige adviezen

Continue reading

Flow in different forms is crucial to speed up your delivery

Do you recognise the struggle of transforming your organisation? Where to start and what the aspects are that really make sense if you want to transform it into a high performing organisation? In this series of posts I want to address 5 principles that must be part of your organisational foundation and way of thinking. These are 5 crucial principles I’ve learned in the past few years from organisations that feel the urge to transform and are willing to make some sacrifices.

5 Crucial Principles that create the foundation of your high performing organisation:

  1. Flow in different forms is crucial to speed up your delivery
  2. How feedback loops will radically change your improvement cycle
  3. Strongly focus on the improvement of secondary processes
  4. Autonomy of teams cannot be given, it must be created
  5. The simplification of your products and processes will lead to faster value

Every post in this series will address concrete examples to find the principle in your organisation, an explanation why this principle matters during a transformation and finally, some practical suggestions to start today.

Flow in many shapes and different forms is crucial to speed up your delivery

You may have heard of flow before, flow as a state of mind, a magazine or a diagram to represent a certain process. There is more. If you break flow down in the view of organisational transformation, flow is about the efficiency of moving and processing units in a steady stream. A unit is a broad concept and applicable in many aspects of your organisation.

Do you want to increase the productivity in your organisation? You aim to deliver more value, for example by creating more and better IT systems? Not only must your IT department focus on more delivery. It is the total organisation that enables the value creation. You have probably improved the IT teams. They are likely already running liked high performing assembly lines, but if nothing is coming in very structured, they are doomed to fail. If your customer has a request, but it takes months before you can answer his questions, the flow in your organisation is most probably blocked.

Production via your production teams is one of the foundations of your organisation and a way to earn money. This department produces value for your customers as soon and as fast as possible. Flow is therefore crucial and bottlenecks in the production lines need to be solved. To get a better understanding of how flow is expressed in your organisation, let’s take a closer look to see some examples.

Some examples

discoverFlow of code to production

How long does it take to push code production? Are you aware of how the process is designed from the developer’s laptop all the way to production? This is one of the basic flows in your organisation that needs to be optimised. If the developers can push code to production quickly in minutes to an hour instead of days up to weeks, a lot of bottlenecks are already solved in this improved flow.
Continue reading

Systemisch Transitiemanagement: een klein tikje, een groot effect

Zal ik even met de deur in huis vallen? Ik heb NIETS met trainingen voor een certificaat, geef niet snel hoger dan een 7 (there is always room for improvement) en neem liever niet deel aan in-je-ziel-roer-trainingen. En dan toch…

Afgelopen week heb ik de training Systemisch Transitiemanagement van Plan-B afgerond. Wat ben ik trots op dit certificaat, blij met de training en zeker de trainers (een dikke 8). Ik heb enorm veel geleerd van mezelf, mijn invloed, en mijn eigen rol in een organisatie en transitie. In deze post een aantal van de vele zaken die voor mij de kern vormen.

Je had er bij moeten zijn

Laat ik daar maar mee beginnen, je had er bij moeten zijn om het echt te voelen, te zien en te ervaren. De theorie is zo eenvoudig gemaakt dat soms het gevoel me bekroop, is dit het dan? Is het soms zo simpel? Als je ervaart hoe complex soms patronen in relaties zijn en bepaalt gedrag een organisatie beïnvloed, dan snap je dat het juist eenvoudige interventies zijn die er toe doen.

Dit maakt het nu juist leuk, als het probleem complex is moet de interventie wel simpel zijn.

De kenmerken die me zo aanspreken

STM gaat er van uit dat gezinnen, teams en organisaties zich gedragen als een systeem of als je dat mooier vindt een organisme. Een organisme dat zich prima voelt bij de status quo. Alles wat deze status quo probeert te verstoren kan uit het systeem worden gewerkt.

De training richt zich op de onderstroom van een organisme in transitie. Deze onderstroom is in veel organisaties onderschat. We veranderen wel een organogram, geven een bewustwordingstraining en dan vinden we het als snel genoeg. We zijn nu veranderd.

Een systeem wijzigen heeft veel meer aandacht nodig in het wijzigen van de onderstroom. Dat wat zich onder water afspeelt. Wat als de ordening wordt verstoord? Wat als nieuwe mensen zich moeten aansluiten en andere juist afscheid nemen? Wat gebeurt er bijvoorbeeld als een aantal spelers altijd maar moeten geven en nooit iets ontvangen? Dit zijn drie aandachtsgebieden die soms nauwelijks opvallen en tegelijkertijd om aandacht schreeuwen om een klein tikje te ontvangen.

Een interventie is als een tikje, ogenschijnlijk nauwelijks impact en uiteindelijk grote gevolgen

Vraag niet hoe het kan, profiteer ervan. 😉

Wat kun jij doen?

Voor mij was de training enorm waardevol. Het heeft mijn gereedschapskist enorm verrijkt. Mijn suggestie voor elke manager, coach, product owner, facilitator of wie dan ook, verdiep je in dit gedachtegoed.

Je kunt natuurlijk zelf de training volgen bij Plan-B of alvast het boek Systemisch Transitiemanagement aanschaffen.


De emotie op laten lopen om de transitie te bevorderen en andersom

Een ander deel van de training was gericht op emoties. Het is soms goed om emoties eerst eens wat op te laten lopen om urgentie te creëren. Urgentie is nodig om de echte transitie in gang te zetten. Zonder urgentie geen verandering.
Continue reading

Workshop Agile Leadership, concreet gemaakt in 3 principes

Met een groep van ruim twintig managers nadenken over Agile Leadership is echt leuk. Als je dan ook nog eens een introductie op het thema mag geven is dat helemaal de hoofdprijs. Wat is nu eigenlijk Agile Leadership? En hoe maak je zo een (hype) begrip nu concreet in de praktijk? Wat moet je doen als je aan de vooravond van een transformatie staat en jij je gedrag wilt veranderen? Wat ga je nu daadwerkelijk anders doen als je met je team van A naar B wilt gaan? Dit zijn een zomaar wat vragen die we in de workshop hebben besproken.

In de workshop heb ik aan de hand van drie (Agile/Lean) principes voorbeelden gegeven over hoe je als manager/leider je gedrag kunt veranderen. Of hoe jij de omgeving kunt veranderen waardoor de transitie naar B in gang wordt gezet. Jou gedrag en het gedrag van de teams bepalen uiteindelijk of je de transitie kunt maken.

De drie principes:
  • Het laten groeien van de autonomie van de teams
  • Het creëren van flow in je organisatie
  • Van sturen naar leiden, van (fake) control naar inzicht

Het laten groeien van de autonomie van de teams

Om teams te laten groeien in autonomie kun je allerlei strategische plannen maken die ver tot in de toekomst reiken. Een andere optie is klein te beginnen en dag in dag uit te verbeteren naar meer autonomie. Niet dat autonomie het doel kan zijn maar wel dat het veel positieve bijkomende effecten heeft. Vergeef me als de statements kort (en) door de bocht zijn.

Wat kun je doen:

  • Een belangrijke focus van de manager is het oplossen van de beperkingen/remmingen rondom de teams zoals
    • verkorten en waar mogelijk automatiseren van change management processen
    • risico management simplificeren en waar mogelijk automatiseren
  • Bij de start van een transformatie van een IT organisatie zijn er cruciale metrieken die er toe doen.
    • De frequentie van het aantal releases naar productie deze moet om hoog gaan, en tegelijkertijd
    • Het aantal gemiddeld aantal open staande incidenten naar beneden
  • Veel andere metrieken doen er in het begin niet zo toe:
    • Je kunt ze niet geautomatiseerd meten of
    • Het mondt uit in spreadsheet management (een valkuil voor velen) of
    • Je volwassenheid is nog zo laag dat het er niet of nauwelijks toe doet als je zeer gedetailleerd gaat meten.
  • Het vliegwiel van continue verbeteren op gang krijgen door de coaching van het team en individu is cruciaal
  • Reduceer afhankelijken met andere teams door je technologie (zowel infra als applicaties) zwaar te reduceren
  • Leg meer en meer beslissingsbevoegdheid in je teams (vakantieplanning, reisjes, training, opschalen van je infra)

Het creëren van Flow in je organisatie

Flow is ook zo een mooi principe waar je als leider in een organisatie grote invloed op kunt hebben. Flow heb je in allerlei vormen in de organisatie. Het op gang brengen van flow is niet altijd eenvoudig en tegelijk cruciaal.

Door er voor te gaan zorgen dat je van idee steeds sneller je werkende software bij de klant te krijgen kun je sneller je hypotheses toetsen. Alleen door deze snelle feedback kun je als organisatie leren en gericht beter worden.

Hier een aantal suggesties:
  • Flow ontstaat door alles maar dan ook alles via de backlogs naar de teams te laten gaan, ook het werk dat vanuit de hiërarchische IT of risk lijn komt.
  • Alleen door feedback loops terug de organisatie in richting the hiërarchische IT lijn of HR en Risk afdelingen kun je voorspelbaar worden en zijsturing maand na maand afbouwen.
  • Er ontstaat pas flow in de backlog als er een duidelijke roadmap en portfolio aanwezig is (bij voorkeur visueel)
  • Er ontstaat pas flow in de roadmap als er een duidelijk doel aanwezig is vanuit het bedrijf en product.
  • Als IT manager mee werken aan de roadmap en de cadans van kwartaal/feature planningen verbeter je de flow in de teams
  • Het streven naar single piece flow in de teams, backlog en portfolio zorgt ervoor dat je netto meer gaat leveren en veel sneller in de markt kunt toetsen of je hypotheses waar zijn.

Van sturen naar leiden, van (fake) control naar inzicht

Tenslotte hebben we het uitgebreid gehad over hoe je rol als manager langzaam over gaat in die van leider, coach en ondernemer.

Het bijzondere effect is dat je door technologie en visualisatie van allerlei metrieken veel meer inzicht krijgt in wat er speelt. Waar je vroeger slechts schijnbare controle had door alle voortgangsrapporten kun je nu op elk gewenst moment inzicht krijgen. Hier ten slotte wat voorbeelden.
  • Grip op je openstaande risico’s? Maak het visueel in je Obeya
  • Inzicht in de voortgang op de korte termijn? Ga naar de borden van de teams
  • Inzicht op de lange termijn? Voer het gesprek bij je delivery roadmaps in de Obeya
  • Weten of je transitie niet stagneert? Kijk waar je ben in je Explorer Maps.
  • De status van je applicaties in productie? Kijk naar je monitoring.
Ik kan me voorstellen dat je bij sommige items van de opsommingen wel wat meer achtergrond wilt. Elk statement zou dan een post apart zijn. En dat is in deze post nog niet gebeurt. Het doel was slechts overzicht.

Wil jij ook een workshop op maat?

Wil jij ook een workshop over de hierboven genoemde onderwerpen of andere zaken die langs komen op mijn blog? Ik doe dat graag, informeer naar de mogelijkheden door te kijken op de pagina “Diensten” of stuur een mail naar andreas@ideetotit.nl.

Een fantastische Agile Coach Lab Meetup vol met coachingstechnieken

Wat een fantastische Coach Lab was dat. Het was een optelsom van leuke dingen. Een mooie locatie, de zon, inspirerende mensen, een nieuw netwerk en een geweldig onderwerp vormden de ingrediënten van een cocktail vol inspiratie.

Het was alweer even geleden dat ik een meetup had bezocht maar deze donderdagavond 11 mei was het dubbel en dwars waard. Met zo’n 20 (aspirant) coaches hebben we een avond kunnen oefenen met elkaar. Ik deel graag 4 lessen van deze Coach Lab die mij weer even op scherp zetten.


Les 1: Rollenspellen zijn brilliant

Wat is het heerlijk om je even te laten gaan. Even die gefrustreerde manager te spelen die je altijd verstopt. Die Dev Engineer die het liefste maar wil programmeren of thuis wil werken. Een team dat geen team is en een coach die zelf harder werkt dan het object van de coaching. Een rollenspel is brilliant.

Continue reading

4 Fascinerende aspecten van continue verbeteren

Continue verbeteren is iets fascinerends; een soms moeilijke reis naar het onbekende. Al streef je doelen na, de realiteit van elke dag kan je route sterk beïnvloeden. De afgelopen 3 jaar is bij mij de bewustwording voor continue verbeteren gegroeid. En hoe meer je het probeert toe te passen hoe meer je ontdekt dat het zo lastig is om het uit te voeren. Vier fascinerende aspecten springen er voor mij bovenuit:

  1. Je weet niet waar je heen gaat: Improvement Kata kan je helpen
  2. Het mag je wat kosten: Kaizen als ultiem begrip
  3. Het is zo moeilijk: discipline is het enige wat je kan redden
  4. Het is zweven tussen optimisme en realisme: Stockdale Paradox

1. Je weet niet waar je heen gaat: Improvement Kata kan je helpen

Hoeveel plannen je ook maakt en hoe duidelijk je de stip op de horizon probeert te schetsen, een ding weet je zeker, zoals je hem van te voren bepaalt gaat hij zeker niet worden. Een paar jaar geleden schreven we nog dikke verbeterplannen. Vandaag de dag doen we het radicaal anders.We sturen en plannen onze verbeteringen op basis van Explorer Maps. Deze zijn een-op-een afgeleid van de Improvement Kata.