The Purpose Alignment Model

When scaling Agile/Scrum, we invariably run into the alignment vs. autonomy problem. In short, you cannot have autonomous, self-directing teams if they have no clue what direction they should go. Or, even shorter, alignment breeds autonomy.

But how do we create alignment? And what tools can we use to quickly evaluate whether or not what we want to do is part of the mission? Niel Nickolaisen, chief technology officer at OC Tanner, created the purpose alignment model. I use it with innovation labs in large enterprises to determine what aspects of innovation to keep, and what to leave to others.

Read more →

7 Agile Practices You Can Apply in a Controlled Environment

So your teams want to do Agile, perhaps have even started doing so. Now your project managers run around wondering what story points are and why any number of people seem to be attributing hours to their project code. So the question is: what can you adopt easily without turning the Governance of your organisation upside down?

Prince2 can severely hinder your agility

Prince2 can severely hinder your agility, but that is no reason to stop smiling

Is this an ideal Agile way of working? No it's not, but it's a good first step that you can take without frustrating the environment too much. That will make additional steps easier.

Read more →

"Tealing" The Capitol using Holacracy, Lean and Scrum

Something absolutely revolutionary (or should I say evolutionary) is currently unfolding @WaTech. This CIO-department of the State of Washington is transforming towards the first Teal governmental organization in the US and perhaps even worldwide.

C24DFB21-3029-4E3A-BC31-A6C9CEB01A34Invited by initiator CIO deputy Michael DeAngelo, Joe Justice and I visited the WaTech offices in Olympia to observe and coach the Scrum teams applying Scrum, Lean, and Holacracy.  What we’ve seen there can be described best as energizing, accelerating, customer centric and dedicated.   Characteristics you’ll expect from a start-up, not from a governmental organization.

This was exactly what Michael DeAngelo had in mind starting this journey in order to be more competitive with WA-State based companies like Microsoft, Disney, Expedia, Amazon and Boeing by creating an awesome "Smell of the Place".

Ingredients for this tasteful recipe were Agile, Lean and Holacracy.  These methodologies paved the way for a different, more empowered mindset of WaTech employees.

WaTech is using Scrum to enable fast learning and acceleration and stay focussed on the most important Minimal Viable Product (MVP). In combination with the core principle of Lean, how do I create a maximum of customer value with as little effort as possible, a powerful combination was born.

But still, bureaucracy and time-taking decision making would still be there without Holacracy.  How does Holacracy eliminate this?   Holacracy is a system that makes accountability in an organization crystal clear.  Decisions don’t need to travel looking for a home.  They belong to the person who is empowered for the specific role.  As a result, 80% of team members feel empowered and confident they can lift impediments themselves.

hola sergeAnother powerful mechanism in Holacracy which prevents long decision making, is consent.  Unless you have a tangible example how a proposal could cause harm or move the organisation backward, the proposal will be accepted. Currently, an average decision in a governance meeting takes less than 2 minutes. This means a decrease of 93%(!) with the situation before Holacracy.

Step by step but determined, WaTech is moving towards a self-organizing Teal Organization.  WaTech employees feel more empowered, valued and happy.  It's no rocket science to draw the conclusion this a blessing for the citizens of the state of Washington.

Perhaps the most important outcome is team members don't think in restrictions anymore but use their imagination again pushing borders achieving the unthinkable: projects which would have taken 3 years before, are now executed in just 3 months.

The next phase of this transition will be even more exciting and challenging; Leadership from the local government is needed to enroll Agile, Lean and Holacracy in more departments. However, new elections are underway later this year.  Let's see what happens. But I'm convinced the teams we've seen in Olympia would even survive the biggest storm!

Screen Shot 2016-05-21 at 10.12.11 PMCurious about a more in-depth analysis and the current situation @WaTech?  Join our presentation and panel discussion @Agile2016 in Atlanta!  See you there on July 25th!


Versnel je team met Scrumban!

Herken je dat ook? Teams die meer dan een half jaar aan het scrummen zijn en sprint commitments maar niet halen? Of maar geen stijgende 'velocity' laten zien? Blijven verbeteren zonder een echte verbetering te zien? Scrumban is het toepassen van de Kanban Methode in de context van scrum en geeft deze teams een weg hieruit door een structuur en principes te bieden.

Veel voorkomende symptomen

In de praktijk kom ik het volgende veel tegen:

  • herhaaldelijk missen van de sprint commitments,
  • het hebben van 2 Definition of Dones,
  • een velocity die over sprints heen hetzelfde blijft,
  • het blijven sleutelen aan het proces zonder zichtbare verbetering,
  • 'deployment' user stories, of 'user acceptance testing' user stories.

Het probleem met het 'snel' repareren van deze symptomen is dat als je de eigenlijke oorzaak niet goed genoeg onderzoekt en deze niet wegneemt, het symptoom in een andere vorm terugkomt. Het komt dat terug maar in een andere vorm en herken je het niet zo snel meer.

Om te weten hoe de Kanban Methode hierbij kan helpen, duiken we een beetje dieper in Kanban.

Kanban Methode principes

De 4 principes van de Kanban Methode zijn:

  1. Neem het huidige proces als startpunt,
  2. Respecteer de huidige rollen en verantwoordelijkheden,
  3. Spreek met elkaar af geleidelijke verbeteringen na te streven,
  4. Moedig leiderschap aan op alle nivo's.

Juist vanwege de eerste 2 punten maakt dat de Kanban Methode uitstekend is toe te passen op Scrum teams: hun huidige manier van scrum doen, is het startpunt!

Met deze principes weten we wel dat het toe te passen is op scrum teams, maar nog niet 'hoe'.

Aan de slag met Scrumban

In de praktijk merk ik vooral dat:

  • het doel of purpose van het team niet helder is voor hen,
  • sterke focus op het 'eigen' werk,
  • een backlog die bestaat uit verschillende soorten werk.

Purpose. Een van de eerste dingen is dat om de focus op juiste dingen er weer in te brengen. Dit doe ik dan door samen met het team het purpose te achterhalen. Voor wie doen we het en wat zijn de behoeften van de klant? Hoe herkennen we dit? Maak het meetbaar. Dit maakt het makkelijker te bepalen hoe we het nu doen en of dit al voldoende is of juist niet.

Soorten werk. Waar komt het werk vandaan? Hoe komt het aan bij het team? Aan wie levert het team het op? Met wat voor regelmaat: ineens, met pieken, via een backlog, terugkerend werk, etc. Wat zijn de kwaliteitseisen en verwachtingen?

Focus op het geheel. Als de purpose helder is, breng ik met het team de keten waar ze onderdeel van uitmaken in kaart. Van begin tot in productie. Hier kun je ook prima afhankelijkheden op andere teams en partijen kwijt. Ook maakt dit transparant dat het doel is dingen in productie te krijgen.

Metrics. In ieder geval beginnen met het meten van 3 dingen:

  1. gemiddelde doorlooptijd per soort werk,
  2. hoe vaak komen verschillende doorlooptijden voor?
  3. hoeveelheid werk dat er in de keten tegelijk onderhanden is.

Met deze informatie bepaal je een eerste verbeteractie met het team waarbij je ook een link legt naar de purpose; je wilt dat deze er beter van wordt.

Hoe pak je het aan? Een stappenplan

Wat hiervoor beschreven is, zijn de eerste stappen in wat bij de Kanban Methode onder STATIK wordt verstaan. STATIK staat voor 'Systems Thinking Approach to Introducing Kanban'. Bij sommige stappen sta je wat langer of korter stil dan bij andere stappen.

De aanpak bestaat erin met het team de volgende stappen te doorlopen:

  1. Doel of dienst van het team: wat is de identiteit van het team?
  2. Onderzoek bronnen van ontevredenheid bij klanten, gebruikers en het team zelf,
  3. Analyseer de vraag van de klant en de mogelijkheden van het team,
  4. Wat voor werk komt er op het team af? Waar gaat het naar toe? Wat zijn de verwachtingen ten aanzien van kwaliteit en snelheid?
  5. Breng in kaart wat er daarnaar met dit werk gebeurt,
  6. Kijk naar de risicoprofielen van dit werk,
  7. Ontwerp het kanbansysteem (met bord)
  8. Doe het!

Met name de eerste 2 stappen zorgen ervoor dat de veranderingen altijd een verbetering van de dienst zullen zijn, of op z'n minst de verwachtingen hebben deze te verbeteren.


Tot nu toe heb ik een algemene aanpak beschreven die in de praktijk werkt. Voorbeelden hiervan zullen in komende blogs verder aan bod komen.

5 ways to organize Agile teams

Do you feel like your teams could be organized better? How to organize teams in an optimal way is a common question in Agile organizations. A question you should always discuss and answer together with the people in the actual teams.

This post provides you with an overview of 5 possibilities for organizing teams and the main factors to take into account. Your main considerations should be based on product complexity and maturity, as well responsibility, coordination efforts and sustainability. Depending on your specific context one will suit your situation better than the other, or maybe you will come to the conclusion you are so Agile you can leave the concept of team all together!

Read more →

How to achieve Ultimate Agility?

World Business teamwork puzzle piecesIn reaction on the Era of Big Transitions we currently live in, many organizations are reinventing themselves as we speak.  How can we survive?  Or rephrased more positive: How can we turn this threat into a unique chance?

Most organizations start with this journey by redesigning their culture, way of work and organizational structure.  But are these building blocks not too rigid and too slow to change?

In my opinion, we should be seeking for smaller building blocks. For example in nature, the smallest building blocks are atoms. Of course, we can’t go back to atoms for redefining the most ideal building blocks for an Agile Organization. But for now, imagine people in organizations are like molecules forming the organization. Small, but not the smallest.

But as we can observe almost every day, people are often not that agile at all. We love what we have and don’t like change. But is this really true? Is this not just our behavior which makes us feel comfortable?  Do we unconsciously as human beings, somehow share deeper needs and values and different types of interaction? Referring to nature’s metaphor again: where are our atoms, our smallest building blocks?

This question challenged my mind for quite a while. Until last month.  As Agile Coaches we went on a Aikido Ki Workshop to experience the physical and mental side of resistance and cooperation.

In Japanese martial art, this Material Energy or Life Force is called “Ki”.  By respecting and connecting with the “Ki” of another person, you will be able to take away the resistance of the opponent.   I’ll bet, this all will sound hazy to the most of you, but it’s actually quite easy to experience.

What to do with this almost spiritual blogpost?

As long as we focus primarily on our personal interest, we will never achieve the purest form of Agility and cooperation. We’re on earth as one collective organism, whether we like it or not, all with one goal: making this world a bit better iteratively.  By Learning, Inspecting and Adapting. Together.  This is where our evolution (read: agile) is all about.

It’s like creating an Internet of People.  It all starts with making real connection with the people around us.  Somehow that’s where it becomes very hard for most Western minds. On the other hand, it’s so logical for us we should create an Internet of Things as the next big step for our prosperity. Food for Thought. Don’t you think?

Solving Agile portfolio planning for Lawns 'R' Us

Agile portfolio planning is a great (chief) product owner tool to plan and trace initiatives across various teams. Implementing it can be difficult and cumbersome at times. This post explores the number one critical success factor to do Agile portfolio planning right; Outcome oriented decision making.
Outcome goals are valuable for streamlining your Agile portfolio planning and engaging people involved. Having them clear, enables you to judge all initiatives and ideas based on their contribution to these goals. This creates focus and clarity. For product owners this means it will be easier to explain to others where and when people will work on certain ideas, as well as saying no to the irrelevant ones. Simple two by two frameworks can help you clarify the details and course of action, be it directly product related or impacting you from the side-lines.
Read more →

Experimenteren kun je leren

pdcaValidated learning: het leren door een initieel idee uit te voeren en daarna de resultaten te meten. Deze manier van experimenteren is de primaire filosofie achter Lean Startup en veel van het Agile gedachtegoed zoals het op dit moment wordt toegepast.

In wendbare organisaties moet je experimenteren om te kunnen voldoen aan de veranderende markt behoefte. Een goed experiment kan ongelooflijk waardevol zijn, mits goed uitgevoerd. En hier zit meteen een veel voorkomend probleem: het experiment wordt niet goed afgerond. Er wordt wel een proef gedaan, maar daar zit vaak geen goede hypothese achter en de lessen worden niet of nauwelijks meegenomen. Ik heb gemerkt dat, om een hoger lerend vermogen in de organisatie te krijgen, het handig om een vaste structuur aan te houden voor experimenten.

Read more →

The Ultimate Tester: Value Creation


Once upon a time, when project managers still thought that building software was a completely manageable and predictable activity, and testers were put in a seperate team to ensure independence, the result was shitty software and frustrated people. Even though the rise of the agile way of working has improved some aspects of software development, the journey will never end. We still have a lot of work to do. Creating good software starts with the people making it, the team. As an agile tester, a tester 3.0 if you will, you are a frontrunner of this paradigm change. 

No longer do you have to sit in a seperate team, crunching requirements to make test scripts that you then manually execute, pretending to be a human computer (how silly is that!). No longer do you have to fake your belief in a Master Test Plan that your test manager urges you to honour. No longer do you have to put your defects in a defect management tool, and then wait for a couple of releases for your findings to be solved.

It is time to take matters in your own hands. It is time to start creating value from the start.Read more →