Scaling Agile ...?
I don't like the term "Scaling Agile", but that could just be because I'm a bit thick.
Let me ramble a bit ...
First, I think it's important to distinguish between big existing companies which want to get the benefits of agile and new projects or companies which use Agile, on a small scale, and want to continue using Agile as they grow. They're very different beasts. I probably should name those ... hmmm ... how about Large-and-Adopting-to-Agile and Small-and-Growing-Agile? Too long, so I'll use Large-Adapting and Small-Growing. Is there another distinction? Not sure ... I'm making this up as I type.
Let's start with Large-Adopting. The good news for these people is that they've been doing big projects for years, but they've been doing so using daft engineering and project management approaches, so the skills are there and the potential for improvement is ENORMOUS. The bad news is that Agile sounds nuts to most of the people working in Large-Adopting organisations. The general approach I recommend (and it works, for me anyway) is to (a) focus on learning the fundamental reason why Agile works (b) be respectful for everything they already know and have achieved and (c) aim for getting better, quickly, rather than perfect.
Let me break these three things down - though I'll come back to them in later posts.
(a) Focus on learning the fundamental reasons why Agile works.
Now I'm going to be bold and say that the fundamental reason we work is that we build software up in small slices and the quality of each slice is, what I call, GETS - Good Enough To Ship. You might use a different word than slices, you may batch up the slices and ship small batches or increments or chunks or ... whatevers. I'm gonna use the word slices because I talk about "slicing and dicing" and I think that has a nice ring to it.
Another way of looking at this is that since each slice is either GETS or as close to GETS as possible, the team will have a short testing phase at the end of their project where they find very few defects. I call that phase a "proving" phase rather than a "testing" or "rework" phase.
The "proving" phase will shrink release upon release.
If you want to make it as simple as possible: we do the developing and the testing in parallel.
(b) Be respectful for everything they already know and have achieved
If you work in small-Agile in, say, a start-up you might realise this: the folk working in big organisations are quite probably older and clever than you are, They work on shitty old code which may well be older than you are and thats HARD.
Notice how disrespectful I was just then to people who work in small Agile teams? Don't do stuff like that! I was being obnoxious to make a point and I didn't mean it. But, seriously, people who work 9-5 on old code are really frickin' clever even if their code is older and wrinklier than you are!. Respect that.
(c) Aim for getting better, quickly, rather than perfect.
If you're used to working on big ugly waterfall projects, you wanna know the easiest way to get a whole lot better?
Hint: don't put up the white boards yet.
It's simple: instead of doing 1 big ugly project with loads of testing at the end, chop that project up into 4 releases - i.e. 4 smaller projects. Use release 1 to build your foundation and the most valuable features. Expect it to overrun, but don't sacrifice quality. This is your FOUNDATION and you don't want to build on a shaky foundation - we know this to be true because it's the sort of thing your Grandpa used to say, "don't build on a shaky foundation sonny boy". In release 2 you're gonna build on that foundation, adding the next most important bits. And when I say "most important bits", don't just prioritise the features, slice-and-dice 'em up a bit first then clump them together so that the releases are not just technically GETS, but commercially GETS and coherent as a whole. Use the 3rd as a change bucket and consider chucking away the 4th. Or something like that.
It might help to show this timelapse video of some chinese folk building a high-rise building realllllly quickly, to get the idea of building a foundation first then adding floors. People will tell you the metaphor sucks, but ... well, bugger 'em, at least you're in dialogue.
Yeah, yeah, yeah, I know: this is a project management solution. But that's what big stuff needs.
And how about Small-Growing?
So, you've got a small Agile team and they need to grow.
(a) Get some "adult supervision", like Google did when they bought in Eric Schmidt to manage the two-nerd-founders. You probably can't afford Mr Schmidt so call in some malleable and commercially oriented managers and project managers. It might help if they like people ...
Show them the video. Argue over the details, a bit. Don't let the PMs try to tie down scope too much. Come up with the same release-plan described above. It'll change - every knows that, but if it helps to pretend for a wee while that it won't ... that's okay.
(b) Get moving and figure out the rest as you go. Don't expect it to be easy. Expect it to be HARD. You're going to have a lot of storming and forming as the teams grow and split. You're working in an Agile way so you're deliberately pulling the pain forward, rather than leaving it until the end, but you know that so just make sure everyone else knows it.
If I'm sounding opinionated then ... well, that's because these are my opinions. I call my approach "slow and quiet" agile because I'm a bit slow and I wish everyone else would be quiet. I'm not selling a framework or my consulting services. But, seriously, this stuff is HARD but it's a lot easier if you expect it to be HARD. Who wants to do easy stuff?