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!

Agile Cambridge session: Questions not Stories: Build a business-value oriented team

The last session I attended today was run by Adrian Howard. Going into it I thought that the session was going to be about replacing user stories, but this wasn't entirely the case. Essentially it was about starting with a user story and then conducting an experiment.

Adrian used the following example:

As a potential customer I want to be able to signup with my Twitter account so that I don't have to fill out a registration form.

The first step is to turn the story into a question.

As a potential customer I want to be able to sign up with my Twitter account so that I don't have to fill out a registration form?

The next step is to ask why the story is needed. Too many times we just assume that there are good reasons for it and don't question. After finding out the main reason why, we should design a hypothesis to validate that assumption and then conduct an experiment to prove or disprove it.

Adrian's team wanted to validate that a percentage of new users would want to signup using twitter.

To do this they put a fake Twitter link page which logged how many people clicked on it. The user was then redirected to a page saying that the Twitter signup was currently offline and redirected them to the normal registration page.

After the experiment was over they found that very few people actually clicked on the link, so they didn't build the feature. Traditionally the team would have just built it and no one would validate if it was ever used after being deployed.

This has potential to be a catalyst for turning an organization into one of experimentation.

I'm still mulling this over, but I think it has great potential.

What do you think?

Sleep, creativity and culture

Note: The following is a brain dump of what I currently understand and what I'm trying to understand.

I've been thinking a lot about time recently and how we're dominated by the clock. It controls every aspect of our lives, even during sleep. The following are my thoughts based on information that I've read and my own life experiences.

Due to the pressure of modern life, most of us function with less than the recommended eight hours. This is mainly because of our culture. The dominant work culture frowns on sleep, especially around the topic of entrepreneurship and leadership. Sleep is for the weak. There's time for sleep when you're dead. These are just some of the phrases that are indicative of that culture. There's an increasing amount of information about why we should get more sleep and we know that we should but we don't.

Sleep is extremely important for our overall health and especially for our brains. During sleep the brain basically reorganizes itself, choosing which connections to make and what to discard. Sleep also improves our creativity. It's also been shown that one of the times we're most creative is when we're sleepy. This is because you tend to make more connections between disparate thoughts at this time. To harness this creativity it's recommended that we ease into our day, not rush out the door. For example, I spend the first 15 minutes after I wake up just mulling over what ever comes to mind. I also take a leisurely walk to the station each morning in which I do the same thing. Those times are when I tend to have some of my most creative thoughts and I'm not a morning person.

Perhaps our sleep cycle is a result of our modern lifestyles. I've been reading a few articles recently which have found that eight hours of straight sleep isn't necessarily our natural sleep cycle. It appears that information is coming to light that historically humans would sleep in two parts. We would enter what has been called first sleep, or little sleep, wake up for a few hours and then enter a second deeper sleep. The single eight hour sleep cycle appears to have been a relatively recent occurrence in the grand scheme of things. This might account for people who often wake up in the middle of the night for several hours. Unfortunately because we are dominated by the clock this time awake. It also matches the sleep cycle of some children with autism. My son for instance will wake for several hours a few nights a week. He'll generally be content to quietly play or talk to himself for a few hours (though that wasn't always the case), before returning to sleep.

Waking up in the middle of the night can cause undue stress for some. We worry about not having enough sleep for work the next day which decreases the likelihood of getting back to sleep. This worry is caused by the the work culture I mentioned above and our lives being dominated by the clock.

So why do we stress about when we get into work? This is something I've never really understood for knowledge workers. If you have a meeting then it's a sign of respect to the other participants that you be there on time. Being late sends an implicit message that your time is more important than other peoples. Getting into work at some arbitrary time which doesn't seem to add any value and causes stress. If I've had a bad night sleep isn't it better for the company that I get in later so that I can perform better? Being exhausted at work does no one any good. We're all adults and should be trusted to put in the hours the company requires of us without having to stress when you're arriving or leaving. How many times have you sat at work at the end of the day, but you're too tired to do anything, especially late in the week? What happens is that people make themselves look busy. Wouldn't it be better for that person just to head home early and recharge?

Another idea is for companies to let people nap during the day. Several studies have shown that taking a nap, where you achieve a deep sleep, improves creativity.

All of the above mainly applies to people in creative jobs. We tend to need large blocks of time to concentrate and achieve flow. This is different from managers who generally work in smaller hour blocks. Getting these large blocks of time might require being on a different schedule from managers. For example, working late in the evening because there are less distractions.

We need to change our work culture and habits to help improve the creativity of knowledge workers rather than ruling by the clock.

What do you think?