Agile/Scrum blog

Onderwerp: Agile Coaches

Needs of High Performing Teams

Alex van der Star Door: Alex van der Star,  20-05-2016
Onderwerp: Agile Management   agile  Agile Coaches  Agile Coach  Agile Teams  Culture  Development Team  High Performing Teams  Scrum  Scrum Teams  Team Happiness  Team morale  What motivates people  zelfsturende teams  

The needs that High Performing Teams have

In my previous blogpost, I wrote about the characteristics of High Performing Teams. To come to these characteristics I did a small literature review. For this part, I will establish the needs that need to be filled in in order to enable teams to become high performing.

Remember, I am still talking about a team of knowledge workers developing and maintaining a software product.

Characteristics of High Performing Teams

Alex van der Star Door: Alex van der Star,  14-04-2016
Onderwerp: Agile Management   agile  Agile Coaches  Agile Coach  Agile Teams  Culture  Development Team  High Performing Teams  Scrum  Scrum Teams  Team Happiness  Team morale  What motivates people  zelfsturende teams  

How to create high performing teams

This is the first blogpost in a mini-series of three in which I explore actions that Agile coaches or Agile managers can take to create high performing teams. I focus on high performing teams that consist of knowledge workers creating a software product.

It looks like we are in the middle of a social revolution equal to the scale of the Industrial Revolution of the 18th and 19th century. We’re seeing more and more self-organizing teams that make their own decisions within boundaries set by organisational direction, strategy and/or vision. The benefits seem clear, teams that take ownership simply perform better. But what is exactly the mechanism behind this? Is setting a certain corporate direction and giving freedom to self-organising teams enough to end up with high performing teams?

Agile Transition Bingo

Stephan van Rooden Door: Stephan van Rooden,  15-08-2014
Onderwerp: agile  Agile Coaches  CD  agilegames  

A few weeks ago at Prowareness HQ in Delft we had a very interesting discussion on how to add more fun to your work. Especially the things that are hard to do or are actually no fun to do at all. Very soon we were talking about gamification which is the use of game thinking and game mechanics in non-game contexts. And this triggered me to add some fun to a very large and important transition we are working on at one of our partners.

Groups & Scrum: Setting goals

Stephan van Rooden Door: Stephan van Rooden,  23-04-2014
Onderwerp: Groups  Agile Management   Agile Teams  Agile Coaches  

 “To win, you’re dependent on others. To improve, you depend on yourself!”

Last week, I had a very interesting session with some fellow coaches on how to assess an organizational department who has started the transition to Agile a few months back. From that moment we started measuring some boundary conditions. Those things you really need to have in place to enable a faster adoption of Scrum and preparing the path towards agility.

Groups & Scrum: How to stop a team?

Stephan van Rooden Door: Stephan van Rooden,  25-03-2014
Onderwerp: Groups  Retrospectives  Scrum Teams  Agile Coaches  

This is the fourth post in a series of blogs on groups and scrum. In the first three posts, I focused primarily on explaining the benefits of groups from a social psychological view. This post will take a more practical point of view.  So based on what I described in the previous posts it shouldn’t come as a surprise that this collection of individuals which we call a team, eventually becomes a real team! Hurray! But what if the team has to stop?

Backlog refinement

Henk Jan Huizer Door: Henk Jan Huizer,  16-09-2013
Onderwerp: Agile Coaches  Scrum Teams  

Bij de introductie van Scrum krijg ik steevast de vraag waar de ontwerpfase in Scrum terug is te vinden. Dat is een begrijpelijke vraag, omdat we aangeleerd hebben om vooraf goed na te denken, alternatieve oplossingen naast elkaar te zetten, en de keuzes vast te leggen op papier voordat we gaan programmeren. Bij de introductie van een iteratieve aanpak verdwijnt deze fasering en worden de activiteiten uit alle fasen in elke iteratie tegelijk uitgevoerd. Het ontwerp gebeurt dus incrementeel, gelijktijdig met de realisatie. Goed invulling geven aan incrementeel design is best lastig en in de praktijk zie ik teams in twee uitersten terecht komen.

Teveel voorwerk

Aan de ene kant zie ik teams vasthouden aan het paradigma dat alle ontwerpkeuzes vooraf gemaakt zijn. Pas als alle details zijn ingevuld dan mag er gebouwd gaan worden. Deze teams werken vaak met een Product Owner of analisten die vooraf gedetailleerde documentatie opstellen. Voordat de sprint begint wordt het resultaat van dit denkwerk overdragen aan de bouwers en testers. Op het moment dat dan tijdens de bouw er ondanks alle voorbereiding toch nog onverwachte keuzes gemaakt moeten worden is de reactie: volgende keer nog meer tijd stoppen in de werkvoorbereiding. De onderliggende denkfout hier is hoe kunnen we voortschrijdend inzicht voorkomen.