"Tealing" The Capitol using Holacracy, Lean and Scrum

Paul Takken

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!

 

Keeping dependencies up-to-date in Maven

jvanbekkum@xebia.com

Keeping your dependencies up-to-date is more important than ever in modern projects. Everything is connected to the internet and needs to be secure. New vulnerabilities in libraries are found, exploited and patched within days. We use a lot of dependencies, and due to continuous delivery some of your dependencies will need updating every day. Solid dependency management is a primary requirement for good software.

In this blog post I will describe how to keep a Maven project up-to-date with the versions plugin. Using the versions plugin has a lot of benefits and configuring it takes less than an hour. So I suggest using it for all maven projects.

 Read more

Pitch your product using the 3x3 framework

Chris Lukassen

When pitching innovative product ideas, you only get between five and fifteen minutes of attention. To make those minutes count, you should be able to define your product vision in a simple but comprehensive way. For this, I’ve found this 3x3 framework technique useful. Not only is it a pretty good format for pitching your product, but it also helps you define the vision.

 Read more

Versnel je team met Scrumban!

Pieter Rijken

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.

Patronen.....

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

Monorepos for true CI

Arjan Molenaar

On the 15th and 16th of April CITCON Europe took place in Cluj-Napoca (Transylvania). CITCON is an open spaces conference. The agenda is made up by the people attending the conference. Because of this there are always a couple of nice takeaways.

This year Ivan Moore (@ivanrmoore) made a claim that you can not do CI without using monorepos. A monorepo is simply one repository where all source code ends up. This is contrary to a setup with (for example) Git source control where you have a single repository per module. The idea of having a single (big) repository with all code seems strange. After some thorough discussion the merits of monorepos were clear to me.

 Read more

Test Masters - Robot Challenge

Xavier Viuda

The Test Masters series is created to experience testing in a fun and new way. Play games, use robots, experience new tooling and techniques to make yourself a better tester! During the meetups we organize you can try out these new tools and techniques and engage in a friendly competition with your peers. In the first serie we will dive into the Robot Challenge.

The Challenge

The Robot Challenge is a mix of feature/software/hardware testing that will make the Testers think out of the box. The Testers will work together in teams to work out the features presented by the Product Owner. When all features are worked out the teams get the chance to test the features on the presented robot. The biggest challenge will be having working software but still seeing the hardware responding differently. How will the teams handle that?

 Read more

5 ways to organize Agile teams

Daniel Burm

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

The Ultimate Tester: Curiosity

Maaike Brinkhof

In 2014 Bill Sempf posted this Tweet:

His message caused a chain reaction of awesome responses from people thinking of all the edge cases in this scenario. Among the most hilarious responses were:

 You can read the rest of the responses here.

This funny example illustrates perfectly how testers think. We think out of the box and don’t assume that some functionality will work because the developer said so and wrote some unit tests. Sure, automation in testing and scripting has its place and use (as we will discover in the next blog in this series), but it seldom proves that the application works as intended as a whole. Automated scripts are usually following a path without feeding the path new data every time. This can give a false sense of security, “we’ve covered this path”, when inputs matter more to find lingering errors.  Read more

How to achieve Ultimate Agility?

Paul Takken

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?

Generic JS Android API wrapper for React Native

Albert Brand

During a React Native project for one of our clients we added some custom Android and iOS libraries to our code and wanted to call a few exposed methods. In such a case, React Native requires you to write a wrapper class to call those public APIs. It was a small boilerplate nuisance and these wrappers would be unnecessary if we made a generic method call bridging API. Also, using such an API wrapper you can call any (obscure) available Android API that is not wrapped yet. Let's see how far we can get!

 Read more