Slides for "Leading software teams well"

Why you can scale agile with the right attitudes

The more I work with teams, the more I think agile at any scale lives or dies based on attitudes of people in the organisation, rather than the scale at which you are attempting to do it.

Software development is hard, and it’s harder the greater the scale as Rachel’s post eloquently argues. However, I don’t think the scale is always the limiting factor here.

I’ve seen small teams with such a lack of trust that they burden themselves with suffocating process, and larger organisations with so much trust that they’re able to operate at the speed of organisations a quarter of their size.

As organisations get bigger, the trust required gets greater. If the trust exists, teams are able to remain independent and don’t get burdened with process.

If you need to work at one thing to make your large organisation more agile, work on building trust between teams, and between teams and management. Try small wins, quick feedback, and constant celebration. Decentralise decisions, give people ownership in their areas, and act like they’re as good as you know they are.

If middle and upper management could be persuaded to give up control and provide leadership instead, your scale matters much less than you might think.

How to give BDD a chance

Adopting BDD is hard.

It’s not that the tools are difficult to use: they’re already great on many platforms and fast improving in others.

It’s not that the technology is unproven: there are many examples of successful projects implemented using BDD.

Adopting BDD is hard because people aren’t perfect.

Everyone has their own agenda, and their own priorities. The product managers must write stories. The project managers must deliver stories. The devs must add features as quickly as possible. The QA’s must find as many bugs as possible.

Wait, what?

What we measure defines us

Our ultimate goal is to deliver working software that does what a customer asks. But often individuals are judged on quite different metrics.

If a developer is implicitly judged on their ability to add features quickly then anything that causes them to slow down whilst they learn new testing skills will naturally fall to the bottom of their priority list.

If a QA’s personal goals are all about the number of test cases they check for, then they’re unlikely to be able to make the analyst switch and drive the quality of the project from the front.

If we’re not helping our team look good with a suggestion, then we are going to have to work much harder to win them over. If the team is the atomic unit of success then we stand much more of a chance of being heard.

I wish I was the project lead!

It’s common for team members to wish they could become the lead on their team, because then they’d be able to change things and do it properly! Right?

Let me burst the bubble: leads have no more intrinsic ability to drive adoption than the rest of us. In fact, it’s worse for them, because everything they suggest is viewed with added scrutiny as a potential fad.

Sure, a lead could try and mandate a switch to BDD, but that’s not going to work. Here’s a newsflash: the only people we can control are ourselves.

If leads try to control people in the switch to BDD, at worst they’ll get a flat out rebellion. At best, they’ll get “mannequin BDD”: a team that goes through the motions but loses its soul, and delivers none of the benefits. We’ve all seen how that worked out for mandatory large-scale Agile switchovers.

How to give BDD a chance

Adopting BDD is hard. To give it the best chance on your team, try the following:

• Make your team look good. If we make our case in a way that devalues other team members (“look! BDD will mean we don’t need QA’s anymore!”) then it’s unlikely to garner wide acceptance. “Saving people’s time” is a good benefit, and eventually it will happen in practice, but “finding more bugs” and “shipping better software” focuses on making our team look good, rather than making them feel superfluous.

• Prove it. Show your team that it works. They won’t want to invest their time in something that they can’t trust. If we are able to demonstrably prove success at a small scale on our own work, then our peers are more likely to attempt to learn it.

• Get out of the way. Sometimes we’re working with people who are difficult to approach with new ideas if they haven’t thought of them themselves. In these cases, we’ll need to tread softly. We might not get to take the credit, and we might need to humbly reconcile ourselves to that. After all, we’re trying to introduce BDD to make our project better, not for personal praise and glory. Right?

Have you been through a BDD adoption process? How did you find it? What helped the practices take root in your team?

Delegated tasks are a team anti-pattern

“Jane, I’d like you to phone up the recruiter, and tell them we need a new agency person. Don’t use Jim from Acme Recruitment again, you didn’t get very far with him last time. Make sure you book whoever it is in for a week to work with us as a trial, like last time. That worked well.”

“Jane, can you find us a great developer for the new website we mentioned in standup last week? Let me know if you need help.”

Which is better?

Goals, not tasks

How about we give our team goals, not tasks? Let them shoot for something, and work out their own tasks, rather than giving them a simple list of things to do. Goals allow people to apply their own creativity and their own flair to a solution, and the end result will be stamped with their individuality.

When learning a new skill, people need direction and tasks to follow. Matt Wynne recently re-iterated the classic Su-Ha-Ri model of learning, where we start with very clear forms to follow, then break those forms as we try new things, then advanced to a place where we no longer need the forms at all. At first, we need to work closely with people, and show them the tasks we perform to get something done. Note that this is quite different to giving people a long list of tasks to complete to ‘learn something.’

Whenever we give something away, there’s a risk that it won’t be done in quite the way that we would like. The simple fact is: no, it won’t. But assuming we’ve not overstretched someone, there’s a good chance they’ll get the job done at least 80% as well as we could have. And good people will cope with being stretched much further than we think.

There’s delegation, then there’s abdication

When we take goal setting too far, we just tend to stop giving people goals altogether and let them figure out their own jobs. This is dangerous: the best people don’t need managing, but they do need leading. Our role as a leader is to paint an exciting vision of the future, and then let our team figure out how to get there.

Micromanagement has many levels

It’s quite possible to micro-manage without realising it. We might think we’re not micro-managing because we’re not telling people exactly how to do something. However if we’re leaving little room for doubt in our own minds, and creativity in theirs, then our team will feel less able to apply their own skills and talents to the problem. They’ll get up feeling discouraged and insignificant.

Ultimately it comes down to trust, and fear. How much do we trust our people to get the job done? How much do we fear losing control?

The first step to fighting a task-oriented tendency is to realise it’s probably not a problem with our team members, but with us.

Your Code Is A Liability

Every chunk of code you commit is more for someone else to read, digest and understand.

Every complex “clever” expression requires another few minutes of effort for each of your team. They must now interpret what you wrote and why you wrote it.

Every line you add limits your project’s responsiveness to change.

Your code is a liability. Never forget this.

A new adventure

Since I wrote last month, I’ve been doing a lot more thinking about the future and have finally decided what’s next for me.