I don't own my team

If you know me you know that I strongly believe that the language we use shapes our thoughts. I hate the dehumanizing use of resources when we mean people, or use of 'the business' when referring to people outside of IT.

The new phrase that I'm trying to eradicate from my language is 'my team'.

Since moving back into a team lead role I've started using this phrase again and it's been making me feel increasingly uncomfortable. It does so in two regards. Firstly, it's possessive as if I own the team. Secondly, it makes me feel that I'm solely responsible for the team and their output.

In conversations with other team members, I've switched the my to an our. When talking to people outside of the team, I'm starting to refer to my own team by the team name. I also noticed that  have been referring to other teams by team leader name. This needs to stop too.

By using our I feel like we're all in it together rather than me being above the team or owning them.

Missing feedback loop. How can I serve a team member better?

In one-to-one meetings with my managers, past and present, I've asked about things I could do better. I've just realised that I've never asked the people I manage the same thing. How could I serve them better?

Some people might see this as weakness, but I see it as the opposite. If I'm not getting feedback other than top down, I'm missing a critical piece.

This shouldn't be an annual thing either, but a continual process of improvement both ways.

Of course this is going to require trust, which has to be built over time, but it's not going to stop me taking the first step.

The absurdity of 'the business'

I've often heard software development departments refer to other parts of the organisation as 'the business'. Not only is that wording divisive, but it's also completely absurd. I've often heard the same departments that we call 'the business', also calling other parts of the organisation 'the business'. We're all the business; we're not a lesser or greater part; we're all in it together

Software development career treadmill

In my last post I outlined many of the reasons why software developers are a good model for career resilience. It was based on the fact that we have to be resilient due to how quickly technology and trends move.

Several times in the past, I've been asked what one thing would I tell people considering a career in software development. I always give the same piece of advice; be prepared to continually learn.

There are downsides to this continual learning cycle though; I've dubbed this the software development treadmill. This treadmill keeps on going at a slightly uncomfortable pace and doesn't relent no matter how tired you get. This continuous pace requires you to have a passion for software development. Without that passion, it's been my experience, you'll washout or stagnate into a career deadend. Passion is critical because it will help keep you motivated to continually learn and practice, most often in your spare time.

Even those who do continually learn and practice aren't guaranteed to always be on top of new technology and trends. This is mainly because there are so many things that you could spend your time on. You end up having to pick and choose based on what interests you and your guess at where the industry is going. Sometimes you'll hitch your cart to the wrong horse and will have to leave that deadend; then scramble to catch up with what the market is actually doing.

For developers in the west, there's also the constant fear of being outsourced. This adds an extra pressure to keep up.

Eventually even lifelong learners can get tired of this unrelenting pace of change. Traditionally developers would move up into management, where their development skills don't have to be as sharp. That said, I've noticed that with the advent of self-organising teams and flatter hierarchies, there's less of a need for management and therefore less opportunities for promotion; these positions were limited before anyway. As a result we're staying in development jobs for a lot longer. This presents additional challenges. As you get older your family commitments generally increase. This means that you have less time to learn and practice on your own time.

Finally there's an unspoken darkside of being an older developer and that's that it's seen as a young person's game. There's a myth in the industry that young people are far more creative. If you want to have a long career in software development you'll need to be on top of your game.

Has this been your experience as a software developer? I'd love to know either way.

Software developers are a model for career resilience

Since the official end of the Great Recession, the private sector has pretty much rebounded. The Dow Jones has recently hit all-time highs and some companies are now posting record profits. Despite this, unemployment has remained stubbornly high. In the US there are three unemployed people for every job opening. We've also seen old business models are being disrupted and companies that can't adapt are closing their doors.

With this in mind, people are now having to become more creative and adaptable with their careers. You can no longer rely on a company to help you design a career path. It's up to you now.

In a recent conversation it struck me that software developers are naturally career resilient and, in my opinion, serve as a good model for others.

So why are we more resilient? Because we have to be.

Our field is always in a state of flux. Programming languages, frameworks and technologies go in and out of fashion. It's very easy to get caught out by focusing on one language and suddenly finding that the industry has moved on; leaving you behind. This is hard to come back from. If you don't continually keep on top of new technologies and learn new skills, you'll stagnate and be stuck.

Another reason you can get stuck is due to skill related pay. When you have a skill that's in demand you get paid a premium for that. When the market moves and you don't, you can struggle finding a new job that pays as much as the previous because that skill is no longer in demand. This might not be completely obvious until you try to make a move.

Another wrinkle is that technology choice can be geographical. For example, working in London in the late nineties - early 2000s most web application shops used Perl. When I moved to Houston there were very few companies that were looking for Perl developers. I ended up finding a job at one of the few Perl shops in Houston, but the local industry moved to .NET so I did the same.

Software development contractors are even more resilient than their fulltime counterparts.They are able to shift from position to position; only looking for the next position a week or so before the current one ends.

How resilient is your career?

For more information about increasing your career resilience, I recommend reading the following article by Michele Martin:

Career Resilience: The Four Patterns that Should Guide All Your Career Moves

Let's break our dependence on being told what to do

The 20th century model of work was one of hierarchy, one where your superiors you told you what to do.

Many people are still stuck in this mindset. It's easy to do. When you're not being told what to do you feel uncomfortable and unsure what to do. I've fallen into this at times in the past too.

The problem is, if you are dependant on being told what to do, you become less creative, adaptable and resilient. If you find yourself in an uncertain situation, you're more likely to fall back on things you've done in the past rather than looking for something new.

Right now, the future of work is uncertain. We're currently going through a time of rapid technological innovation. Organisations are able to do more with less people. Companies that don't innovate are going out of business as new ones disrupt legacy business models. This amongst other things, is causing unemployment to rise. Hundreds of people are competing for a handful of jobs.

As existing jobs are automated we're going to need to find new problems to solve, which means people to be able to think for themselves.

I believe that we should create organisations that have a culture of innovation, where all employees can use their own creativity and ingenuity to solve problems. Not only will this help companies become more adaptable and resilient, but by doing this we can help people break the dependency on being told what to do. This in turn, will help them find their own ideas to tackle and ways to thrive in this uncertain future.

Say no to degree discrimination

I'm going to come straight out and say it. If you're hiring for a position that doesn't require a degree, yet you're requiring one, you're discriminating plain and simple. Plus you could be missing out on a potentially good candidate.

I'm frustrated after reading an article from the New York Times about the increasing number of companies in the US requiring a batchelors degree for all open positions. This growing trend really concerns me because it's an artificial barrier that not everyone can get over.

Hold on James, are you worried about this because you don't have a degree? Damn Skippy I am, but there are plenty others out there too that don't deserve to be discriminated against.

So here's one of the reasons I'm frustrated. Within the first few paragraphs of the article I came across this quote:

"College graduates are just more career-oriented," said Adam Slipakoff, the firm's managing partner. "Going to college means they are making a real commitment to their futures. They're not just looking for a paycheck."

This is a gross generalisation if I've ever heard one. A degree doesn't mean anyone is more career orientated (or is better learner, but that's a subject for another post). Perhaps they can't afford to go to university, which is an increasing problem as costs rise. Perhaps university isn't the best place for them to learn. Perhaps they're just tired the education mill by the time they graduate from high school.

What happened to the people without degrees that started in the mailroom and worked their way up to CEO? Isn't that part of the American dream? Are these people not career oriented?
Hint: they're still out there.

I've met plenty of people with degrees that haven't a clue what type of career they want, and I've met plenty of people without degrees that are very career focused. In fact some of the most talented software developers I know don't have a degree. One thing that they do have is a love of learning.

As I mentioned I don't hold a degree myself, yet I've had a sucessful career as a software developer and software development manager. When I started my career as a software developer, I actually had to unlearn what I was taught in formal education on that topic. For me, university just wasn't the right learning environment for me. I learn best by doing. 

If someone has a passion, they don't have to have a degree they will learn what they need as they go along.

Obviously there are some careers that definitely require higher education, but a lot can be taught on the job.

This brings me to my next point. A few paragraphs later I came to this quote:

"When you get 800 résumés for every job ad, you need to weed them out somehow," said Suzanne Manzagol, executive recruiter at Cardinal Recruiting Group

If you're filtering on something that's irrelevant to the job, why stop there. Are you going to filter on gender, age or race? No because there are laws preventing that. What would you do if the government said you couldn't filter needlessly? When I hire, I put my money where my mouth is. I don't discriminate on any of the above.

Degrees also become even more irrelevant as a person progresses through their career. What if you have a candidate that has far more experience, but no degree?

I have an idea. Let's filter out candidates on something important, whether or not they can do the job and whether they have a passion for learning. If you have too many people applying for a position, that's s good thing.

I think I've made my point. I'll leave you with some rampant elitism:

"Besides the promotional pipelines it creates, setting a floor of college attainment also creates more office camaraderie, said Mr. Slipakoff, who handles most of the firm’s hiring and is especially partial to his fellow University of Florida graduates. There is a lot of trash-talking of each other’s college football teams"

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!

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?

Do not fear your Product Owner

The role of Product Owner (PO) is an essential one, but is also one that teams often fear. I've felt that fear myself in some environments.

Perhaps they are higher up in the org chart, but what does that matter?

Your PO is not your parent and you shouldn't assume a parent/child relationship. They are your team member in producing high quality software. Sure they might have different responsibilities, but you're all professionals and experts in your own domains. Treat each other as such.

• Don't be afraid to ask them questions. 
• Don't be afraid of making mistakes or taking risks
• Don't be afraid of challenging them. 
• Don't be afraid of telling them when they aren't doing what they need to be doing to help the team. 
• Don't be afraid to tell them if their actions are detrimental to the team.

Try not to be afraid. If you are, recognise it and then push through. Work together as professionals.

What do Kung fu and ScrumMasters have in common?

I look at being a ScrumMaster a bit like Caine from Kung fu, but without so much ass kicking.

Instead of going from town to town we go from team to team. We teach them, coach them, guide them and leave them when we're no longer needed.

This isn't the type of ScrumMastering that you're going to learn from a woefully inadequate 2 - 3 day certification course. This is what you're going to learn from practice, self improvement and others experienced in the field. That said, even if you're new to this, it's important to understand where your journey is going to lead you.

Firstly though we need to look at the primary roles of a ScrumMaster a little differently.

These are the ones I perform.

1) Guide the team towards self-organization.
2) Continually challenge the status quo and help the organization improve.
3) Help other ScrumMasters improve their practice.

Ultimately a self-organizing team will no longer need you. That's when you can walk away, head held high and say "My work here is done".

ScrumMasters and impediments

One of the roles of the ScrumMaster is to help the team resolve impediments. i.e. things that are stopping the team or a team member from making forward progress with their story or stories. The keyword above is help. Do not necessarily do it for them. If a team member can resolve an issue, let them. Sure a SM can help have the difficult conversation or chase some hardware that's required, but we should understand why they can't resolve it by themselves. Perhaps they shy away from conflict and they are to scared to have the difficult conversation. Perhaps the hardware requisition is distracting them from coding. After understanding why the impediment cannot be resolved by the team, work with them to resolve it together. Build up their confidence to do so. The SM is the teams coach and should be helping them self-organize. By resolving all impediments you're increasing the teams reliance on you and decreasing their ability to self-organize.

How do you see the role of the ScrumMaster for removing impediments?

This is who I am

I am:
Not content with business as usual
Continually improving
Building my own opportunities
Following the value not my career ambition
Following my passion
Continually learning
Dedicated to my family
Doing what I think is right
Working across white space not in silos
Doing what needs to be done
Not asking permission but asking for forgiveness
Working regular hours

Some of the things I need to improve at.

All of the above and...

Handling conflict
Obsoleting myself
Standing up for myself
Listening to others
Putting myself in other people's shoes
Helping others
Taking care of myself

and much much more.

Who are you?