The autonomy and alignment experiment

Stephan van Rooden Door: Stephan van Rooden,  17-04-2015
Onderwerp: agilegames  

Recently, we hosted a small event on ‘self organisation’. This was an informal and highly interactive session. We kick started with an experiment which I think is worth sharing.

Goal of this experiment is to see how people react when given a simple task with a combination of high or low autonomy and alignment. How does this make them feel? And how do they experience this? The outcome was great! In this post I would like to share how you can re-enact this experiment.

This experiment is inspired by a small fragment from the movie about the Spotify Engineering Culture part 1. We wanted, before showing this to the audience, to have them experience what it means to have low autonomy and low alignment but still have a result expected. This is how the experiment works:

Als het kan, gebruik dan een fysiek scrumbord

Door: Hendrik-Jan van der Waal,  08-04-2015
Onderwerp: scrumbord motivatie  

Ik ben sinds maart 2014 agile coach bij Prowareness. In de jaren daarvoor heb ik een aantal teams geholpen, maar vooral zelf een transitie doorgemaakt. Van een ervaren Prince II projectmanager, ben ik scrum master geworden en uiteindelijk ging ik ook weer "gewoon" als mee doen, werkende software opleveren.

In die periode werkte we veel met een fysiek scrumbord. Klanten waar nu kom, hebben eigenlijk allemaal een digitaal scrumbord. Dat is logisch: remote teams of veel teams, digitaliseren is de enige oplossing. De overhead van een fysiek bord delen met remote teams, de dubbele administratie, het is al snel te veel. En er zijn al veel blogs geschreven over de voor en nadelen van digitale borden. Even google'n geeft al veel informatie
Maar één aspect wordt zelden benoemd. Teams lijken anders om te gaan met fysieke scrum borden. Er gebeurt iets als je werkt met stickies. Het lijkt iets te doen met de motivatie in een team. Teams houden het bord beter bij, zeker als er veel taken worden afgetikt. Maar hoe zit dat? 

Challenges with funding Agile teams

Door: Rosanne Bal,  06-04-2015
Onderwerp:

In March 2015, my adventure as an Agile Implementation Consultant at Prowareness has started. I’m very happy to write my first blog and share my knowledge and insights with you!

Last week, I talked with one of our clients about the challenge with the funding of Agile teams, in the transition to become an Agile organization. Several organizations are facing this challenge, because the traditional way of funding doesn’t suit an Agile environment and should be adapted accordingly. This raises the following question: What are important topics to keep in mind with the funding of Agile teams?

The Scrum Master as a Servant Leader

Barry Overeem Door: Barry Overeem,  06-04-2015
Onderwerp: Scrum  Servant-Leadership  

The role of a Scrum Master is one of many stances and diversity. A great Scrum Master is aware of them and knows when and how to apply them, depending on situation and context. Everything with the purpose of helping people understand and apply the Scrum framework better.

In a series of blog posts I will share the different stances I consider to be relevant for the Scrum Master. This blog post is about the Scrum Master as a servant-leader. Servant-leadership is fully in line with the Scrum values of courage, openness, respect, focus and commitment.  It's the backbone of the Scrum Master role and therefore the most obvious one to describe as first.

Product Owner on a holiday!

Stephan van Rooden Door: Stephan van Rooden,  30-03-2015
Onderwerp: Product Owner  

As a Product Owner you have one of the most challenging roles in the Scrum Framework. However, even Product Owners have a right to go on a holiday. I meet a lot of Product Owners, Development teams and managers in distress when they find out the Product Owner will not be available for the next sprint(s). Or even worst, the Product Owner is ill. The solution is surprisingly simple.

Ideally, as a Product Owner, you would like to have a couple of sprint of ‘ready’ work on the product backlog so in case you get ill or go on a holiday the development team can continue working and does not come to a complete stop. This practice covers the part where the team can still start a new sprint while you are absent. But how does it work when completing items on the sprint backlog. Who will accept these or is able to make choices on dropping items from the sprint backlog (if necessary)? Yes, ideally this is something the product owner is involved in. But when the product owner is not there the Scrum team needs to figure out another way how to handle this.

Watch left, watch right, and watch that bus!

Martijn Dehing Door: Martijn Dehing,  30-03-2015
Onderwerp: scrum  team  knowledge  sharing  single source  bus factor  

At the last Sprint Review meeting the Scrum team presented their latest product. Some features were not ready so the Development Team, together with the Product Owner, decided not to show these to the stakeholders. “What is the reason that new report we were so desperately longing for is not in?” Patricia from sales asked. “Well, the feature was not finished so we decided to leave it out” replied Neil, one of the developers. “Ok, it was the most important feature of the sprint! Was there any specific reason why it is not finished?” “Simon had some family-related issues so he was not in half of the sprint, and because he has the knowledge we were unable to finish it on time. But hey, we delivered something else instead!” Neil replied.

In traditional organizations people are pushed more to become specialists and to have focus, alone and heroically, on one tough topic. Everyone wants to feel special, and these local hero’s certainly get a lot of attention, questions and are asked for that meeting where those important decisions are made! Is this what it feels to be Superman? Is this what the organization needs?

Five Fundamental Questions to Assess your Agile Process

Barry Overeem Door: Barry Overeem,  25-03-2015
Onderwerp: Scrum  Agile  
Recently I read Mike Sutton's article in which he describes the misuse of the Scrum framework. He addresses a few relevant topics and practices that I've unfortunately also witnessed applied wrong quite often. Examples are Scrum being used as a methodology instead as a framework and all the elements of Scrum are practiced mechanically without really questioning its true purpose.

However, my intention with this post wasn't starting an in-depth discussing about the misuse of Scrum. It's the questions Mike presents to assess the quality of an organization's way of working that triggered me.

Scrum Webshop