Elastic Team Leadership in Software

Should you grow even a short-term consultant in your team?

Roy Osherove — Sun, 06 May 2012 13:17:05 +0000

What if you have a short-term consultant on your team? What if you're the team lead for

just this project, and there will be a new team lead in the next project?

Should you work on growing people even in those situations?

My answer is an unequivocal yes. (unless we're in chaos mode).

People who come across my path , even for a short time, will get the same

amount of respect, expectations and challenge from me, as if they were there forever.

I will try to always leave people who I've led, better off than they were, in terms

of new skills and challenges.

It is in my personal integrity to do so. If you conduct yourself this way,

you'll find that people will want to work more with you, and will remember you

even years later, no matter how short the project was.

You never know when you're going to meet those people again, and

you may find hidden treasures are laying down in your future path, just because

a few years back, you did the "right thing" with people who didn't expect you to.

Show a personal example that even in the short term, you do not give up

on quality (of people, of leadership).

Elastic Leadership course in Amsterdam - July

Roy Osherove — Sun, 06 May 2012 13:01:06 +0000

Join me this July for two days of elastic team leadership workshop. Learn new skills, get out of your comfort zone, and learn to lead better.

We can tackle all the hard questions together.

I'm also looking for a venue to host the course in - so if your company is willing, you can get a couple of free tickets! Ping me.

On time, with quality - why is this mostly failing?

Roy Osherove — Sun, 06 May 2012 11:50:23 +0000

Everyone in the software industry seems to be talking about the quality mantra lately. Agile, XP and kanban brought this issue to full front, but I see many team leads failing with the quality part.

Many of us keep chasing quality and never achieving it, because we don't know how to make time. We don't have any time to learn/teach the team and practice true quality code (unit testing, tdd, acceptance and automation to start with) because we're in chaos and we are addicted to it.

Our lack of time makes our decision to focus on "getting things out the door" more frequent, and so we have more quality issues and even less time, because we just have more and more fires to put out.

To break this pattern, true leadership from us, the team leaders at the bottom, is needed. It's about taking a risk and breaking the cycle. It's about making time to learn.

Want to ship on time with quality? remove some of the commitments you have, make time to learn, practices, and build quality into the code you're writing. You can't get better at what you do if you don't have time to get better. and You don't have time because you keep chasing your tails.

So you have to break away and make time by removing some existing commitments. That's scary, but it's your job, remember? Here's your manifesto again.

Middle Management or puppet management?

Roy Osherove — Sun, 06 May 2012 11:19:00 +0000

Most team leaders I've seen in lead roles usually feel quite helpless. Someone put them in their position, and no one taught them how to do their jobs. So they are mostly developers who are just trying to keep the status-quo.

They either don't want to, or not sure how to lead the team, and what's their role in the team.

They don't feel like leaders, and they mostly act as puppets for upper management for setting (sometimes) impossible goals and chasing them.

If you're that team leader, you should realize that your job is to lead people to do the right things, and to do the right things the way you believe is right(for everyone involved). That's your job. That's why they pay you more.

Management, done right, is a very tough job. That's why you get paid more.

But maybe no one ever told you this. I'm telling you this now. Your job is to make your own decisions, and find your own voice. and to lead.

Your job is to build value, and knowledge in the company. Your job is to grow your team to become the best bloody team they could be.

This is your manifesto.

Scared? Great. Means you're about to start learning new skills, and get out of your comfort zone.

If you're looking for a QA to automate your tests, you've started to fail

Roy Osherove — Sun, 06 May 2012 10:44:20 +0000

If you are looking for someone to join the QA team to automate tests, the failure is in the way the system is built. Your *developers* should be proficient (or start learning how to) in automating the tests, creating automated tests, and overall be able to automate the hell out of everything.

Having a separate QA department is a fail in that, there is an explicitly delegation of all those "things QA folks do" to that other department, so that devs can focus on the other things.

at the very least start with each team having a QA in the team, that is part of the team. then spread the knowledge of the QA dude to the rest of the team.

By looking for someone to do all that "other work" is keeping the system in fail state. instead of starting to grow your devs to be able to become better, and do that work so it's part of their work. *it is*.

Steps I'd take(assuming the team is in the learning phase):

Start getting each dev/team into automation thinking mode
Having small goals to automate more and more things, as we write them
doing code reviews with an "automation" theme
Having "automation week" a the team level

Different ways to view organizational change

Roy Osherove — Fri, 04 May 2012 13:21:44 +0000

I've written about how to change your organization in a couple of places, but I also highly suggest you read this very interesting blog post referencing different models, some of which I've only had a glipse at uptil now.

It helped clear the picture on the "language" related side of things. Think of it as "design patterns" for organizational change.

Of those models, where do you think this post belongs?

Chapter four - commitment language - is online

Roy Osherove — Wed, 02 May 2012 15:32:24 +0000

I've just released a new chapter to my team leader book. Chapter 4 is about commitment language, as the first step as part of the learning stage.

It's about bringing your team closer into Integrity thinking, and an important tool in later challenging people to master new and hard-to-earn skills.

Get the incremental book here.

What should a good code review look and feel like?

Roy Osherove — Wed, 02 May 2012 11:06:56 +0000

The way I see code reviews, is that they are a great cover for learning, mentoring _and_ finding interesting quality issues in your code. If our main goal as leaders is to grow our teams, then code reviews are a great way to grow team members, by helping them gain many skills: how to mentor others, how to communicate better, Not being shy about asking questions, stopping hoarding knowledge and much more.

You should leave a code review either feeling like you've learned something new, or that you've shared something new, or that you've caught something stupid, or too smart, and you're more proud of the codebase.

To achieve all these great benefits there are some important points you can't neglect:

To increase learning on many levels from each other, code reviews are always between at least two people (sometimes a third person can join in to learn how to review), sitting side by side. Not in different work stations, not in different offices and not in different buildings. Those learnings can be as simple as "how did you do that with the keyboard?" to "why would you even do that?" to "I didn't even imagine that's something you could do"
To increase code quality and remove the chance of forgetting to implement them, code review comments are taken care of either _during_ or right after the code review has ended
To increase focus and energy, code reviews should be short. 30 min. is almost too long. 5-15 min. is good. To do that you'll need to make sure that code reviews cover smaller parts of the codebase. One way to achieve that is by reviewing on every check-in, so that the batches to review are smaller.
To increase overall team proficiency and share knowledge, code reviews are done by all members of the team to all other members. At least, that's the long term goal (within 2 months it's possible to achieve for a team of 10).

If you want to get started with code reviews, and read how I'd recommend teaching everyone to review each other's code, I expand on those things here.

What about all those code review tools out there? I don't use them and never have. If you use them, you're missing out on the most important part of code reviews, the interactino with other people to learn and teach something. Remove that interaction, and you're left with a dead, boring feeling of having to look through someone elese's list of boring things they think you got wrong. Who has time for that?

Do new startup leaders need to grow their teams?

Roy Osherove — Tue, 01 May 2012 09:44:28 +0000

I've been involved with several small startups. My feeling is that in the first few weeks or months of a startup's life, your main goal is to make sure you're running in the right direction. You're about to release something as quickly as possible (minimum delightful product) to the market to see if you're on the right track.

That means that, you're mostly in chaos. you don't have time to learn new skills. You hire the best people and pay them well so you don't have to worry about teaching anything. It's about running as quickly as possible and wasting little money in the process.

That means that to me, the learning phase only happens after the startup has matured enough to be in the right direction. after the second funding phase, probably, it has time to worry about things like quality, and growing the people.

That's why I would not recommend TDD either when you're just trying to gauge people's reaction to something you might throw away in two weeks.

I think that's also the reason why in many established companies who started as startups, the code base is so crappy - because the initial idea was to get something out there. It's fixing the code base that considered part of the "learning phase". But unfortunately, many companies continue to exist in chaos even after initial startup phase, and don't give enough time for skills and practices to be learned by the team.

But that's a whole 'nother story.

Grow your "feature teams" into just "teams"

Roy Osherove — Tue, 01 May 2012 09:36:33 +0000

A feature team, as I see it, is a team consisting of all the people needed to accomplish a released specific feature. So on such a team you might have an architect, a DBA, a coder, a UI guy, a frontend guy etc..

In that case it's important to notice that a team consisting of different specialists is also a team with a very bad bus factor. The team can stop being productive as soon as even one person on the team gets sick for a couple of days. Knowledge is not shared.

That's why, in the learning phase, it's important to have a goal to turn feature teams into just "teams" of people who work together, each with the minimal skills to do the work of the others. It takes a lot of time, but growing people, taking them out of their comfort zone, and teaching them new skills, is part of your job as a team leader.

As a team leader, you should view feature teams of different specialists as something to grow out of. To be left with only teams of people who can self organize and do the work and have the skills needed to overcome problems such as a person on the team missing. Most organizations don't even have feature teams yet, but as a leader, your vision should strive to have "feature teams" be just a mid-point on the way to teams that share knowledge.