One of the twelve Agile principles is working with self-organising, cross-functional development teams. Self-organisation is possibly one of the most difficult Agile principles to implement. It sounds easy enough, but is often misunderstood and underestimated how difficult it can be to create self-organising teams.
Luckily there are methods to stimulate self-organisation, one of which I will elaborate on in this article.
Yay, we are self-organising
Self-organisation in context of Scrum means that the Development Team is responsible for organising your own activities and its results. All activities required to reach the Sprint Goal, as well as dealing with impediments are within the responsibilities of the Development Team.
Outsiders unfamiliar with Scrum might interpret this as “developers can do whatever they want”, but that’s far from the truth. With self-organisation the developers have the responsibility to make a commitment on the work the accept and to deliver value. They are committed to deliver on promises made to their product owner, adhere to their level of quality and deal with outside influences that impact their success.
Leading away from Self-Organisation
Too often I encounter Product Owners that consider themselves “customer” of the Scrum team. Sometimes this comes from the previous role and hierarchical placement of the person who acts as Product Owner or sometimes simply due to existing culture and governance of the organisation.
It’s important to emphasise that there is no hierarchical relation between the Product Owner and the Development Team; they obviously have different roles and responsibilities, but they are part of the same team and they have the same goal.
The pitfall of a Product Owner to act as a ‘leader’ of the team is that you frustrate self-organisation. To lead people is to make them follow, with all its downsides; when there is strong control on the team there is little room for initiative, reflection and self-sufficiency. The result is that you change professionals into trained monkeys.
Self-organising is not self-evident
Even without the force of leadership becoming self-organising can be challenging for teams. Especially teams that work in hierarchical organisations with a corporate culture have learned to follow orders. An overflowing Product Backlog contributes to the idea that developers should just work harder and don’t take the time to think how to work smarter instead.
To give self-organisation a fighting chance it might be prudent to make provisions that help change this ‘following’ behaviour.
Implement Happiness
One method I employ myself to stimulate self-organisation is implementing Happiness in my teams. Happiness is a time-budget (percentage of the team velocity) that is agreed upon with the Product Owner, which the team can allocate at its discretion. Think of it as a mini-hackathon within the context of a Sprint.
The rules for the team to use Happiness are:
- The team determines together how to spend Happiness; it can be spend individually, but there must be consensus on its use;
- During the Sprint Review the team must present how they spend their Happiness, their motivation and the result, preferably in a demo.
The deliverable from Happiness are different every time, but they always benefit the team. I’ve seen team develop solutions to frequently occurring outages and defects, create a proof of concept for the use of new tools or technology, make the next step towards continuous delivery, and so on.
Happiness motivates
The true result of using Happiness is a shift in realisation of both the development team and the product owner.
By applying Happiness Development Teams have learned:
- to create time in the sprints to implement improvements to their own workflow;
- to take responsibility over how they spend their time as a team, through coordination and making decisions;
- that self-organisation makes your job more interesting and fun.
There are insights the Product Owners gains as well:
- he learns to trust Development Teams to organise their work effectively without endangering the outcome;
- he understands that Development Teams will organise to improve quality of the deliverables;
- he sees the productivity (velocity) of the team increase over time.
Allow your team Happiness
There is evidence abound that self-organising teams will end up being more productive and happier with their work. They will take the time to negotiate on stories for the backlog which are important for them and the product.
Ultimately Happiness are training wheels for self-organisation. When your Development Team starts to actively negotiate their own interests with the Product Owner you can consider to let go of the budget and have them fight for a spot on the Product Backlog like any other stakeholder, provided the Product Owner regards them as such.