Unbalanced self-organising teams

In my experience it's very easy to disrupt the balance of a self-organising team, just change someone's status within the company. If a self-organising team is made up of peers, each person takes leadership dynamically. Even if the team has a few junior members they tend to fall into a mentee - mentor dynamic. If one person is perceived to be more important the team will look to that person for leadership. I'm not saying that self-organisation can't work with an imbalance in status, it's just that different considerations are needed.

Firstly it's up to the person in question to understand this change in dynamic and address it directly with the team. One idea is for the leader and team to come to an agreement that no one person is more important than the others. Put this agreement on the wall in the team's working area. That way they can point to it and hold the person with more perceived importance to it if necessary.

Note: Violation of that agreement, can send a message to the other team members that the leader doesn't agree with the working agreement.

What are your experiences with unbalanced self-organising teams?

Downtime and employee focus

In all places of work, there will be periods where people will have downtime. Conventional wisdom states that "idle hands are the devil's playthings". This might well be true if someone cannot channel their energies in an appropriate direction. To get around this problem many organisations try to optimize on efficiency to achieve the mythical 100% utilization. That way no-one will have downtime and be unconstructive, right? 

This might be possible for machines, but not people. We don't operate the same one day to the next and you can't predict how someone will be feeling on a specific day. Perhaps they didn't get enough sleep; perhaps they're having problems at home. In addition, organisational slack helps businesses adapt better when their market shifts and more.

Coming back to downtime, clearly a company doesn't want people sitting around doing nothing. I can understand that. If an organisation lives their values and has worked hard to engage the employee in their work, then that opens up the possibility of the employee using that downtime for the benefit of the company. The problem comes when the employee isn't engaged with their work.

Let's focus more on engaging employees rather than trying to keep them busy.

Do you agree or disagree?

Sharing bad news

If you have to give someone bad news, do it straight away. Don't draw out the conversation. Your body language will give the recipient hints that bad news is coming. The longer the lead up the more stressed they'll become and more likely they'll react badly.

Team visions

A vision is an often missing piece from software development teams. It is a powerful technique because it allows them to envision where they ultimately want to go. This allows for focus and then they can then take small steps to get there.

I've found that teams rarely know where they want to go other than a loose self organising team or high performing team. Not having a vision can stop them from making effective improvements in how they work. Small changes are made but can be scatter shot. Eventually they may become an effective self organising team, but not as quickly as they could have.

So if you don't have a vision create one in your next retrospective. It can be a lot of fun discussing what you want your team to be like in an ideal state. Just remember though, the vision should be revisited occasionally because it can change over time.

Does your team have a vision?

Team values and changes in membership

Following on from my post yesterday about changing team membership and working agreements, today I'm going to talk about values.

Most of the values a team holds are learn through osmosis. As the team works more and more together they generate a shared mental model of how the team works and interacts.

So what happens when team membership changes? The team's values might well be invalidated. Perhaps a new team member doesn't agree with the current values, but if the values aren't made explicit how would anyone know?

Getting these values out of the teams heads and talking about them is a valuable exercise. Not only does it allow the team to understand what values they each hold, but also the ones they have in common. The conversation is the most important part of this. After which they can document and display the values. This also has the added benefit of showing the surrounding company what you value and may spur more conversation.

Back to our new team member. He or she might value the same things. In that case, great. If they don't agree then there's a conversation that needs to be had. The team might still agree to keep the same values, but with buy in from the new member. They might also agree to change them.

The important things are the conversation and the buy in from all team members. Without the buy in it's hard for someone to really live those values.

Finally compare your values to that of the surrounding organization. Is there a match or mismatch? This may generate more conversation at a higher level.

Have you made your team values explicit? What do you value?

Working agreements and changes in team membership

Teams have both implicit and explicit working agreements. The ones the team does without thinking, and the ones that they've agreed on and written up. Explicit agreements can become implicit over time as the team internalizes those agreements.

What makes us think that adding or removing people from that dynamic won't affect the team?

Whether they are implicit or explicit, working agreements can be invalidated if the new team membership don't all agree. The entire team is meant to agree and not impose their rules on the new membership. The team has to find it's own path again.

Don't forget to iterate!

In the 1964 case Jacobellis v. Ohio, Justice Potter Stewart wrote that hard core pornography was hard to define, but that he'd know it when see saw it.

This also applies to product development. It's hard to define what you want, as people have a hard time envisioning the future. When someone actually has something tangible they can make better decisions about what they want. i.e. they know what they want when they see it.

One of the reasons why agile software development works is by shortening the feedback loop and adjusting a project based on the things that have been learnt over it's lifetime. This can be done in a couple of ways. Firstly by doing incremental development and secondly by doing iterative development. Unfortunately many Scrum teams focus on the former and forget about the latter. Incremental development it easy to understand and is baked into the Scrum cycle. It's expected that at the end of a sprint that we have a 'potentially shipable product increment'. I believe that this wording is partially responsible for creating a misunderstanding that we should only be incrementing.

One anti-pattern I've seen is when a team tries to develop an entire feature in a story so that they have their potentially shipable product increment. This feature is complete as far as they're concerned so they can then proceed to the next story and do the same. These stories then only get reviewed by the Product Owner (PO) in the sprint review meeting. Though there's a much shortened feedback loop compared with traditional software development projects, we've lost some of the learning. We shouldn't just learning about what features need to be developed, we should also be learning about how a feature is developed. This is where iterative development comes in. We need to getting something into the hands of the PO as quickly as possible so that they can see if it's really what they want.

I recommend doing the following:

1) Treat each feature like an experiment. Build a hypothesis about what you're trying to achieve then go about proving or disproving it.

2) Slice your feature into stories as thinly as possible. Start with the simplest possible implementation of the feature. Put things such as safety or experience factors into subsequent stories.

3) Shorten the feedback cycle. Talk to your PO throughout the sprint. Show them as the feature evolves and gather feedback. Some of this feedback will generate more stories. Others will allow us to make smaller course corrections. We're continually learning.  Also remember that your PO is meant to be a partner in this effort, a collaborator.

4) Deploy each completed story into a staging environment so that the PO or trusted end users can start playing with it. Remember that just because a story is of a potentially shipable quality, it doesn't mean it can be shipped. That decision is up to the PO.

To sum it all up, don't forget to iterate!