contact ME

Use the form on the right to contact me.

Or email me at clarke.ching@gmail.com

           

123 Street Avenue, City Town, 99999

(123) 555-6789

email@address.com

 

You can set your address, phone number, email and site description in the settings tab.
Link to read me page with more information.

photo_887_20120407.jpg

Clarke Ching's Rocks and Snowballs Blog

Life - simplified.

clarke ching

I like this, Bruce Springsteen’s preamble to “I’m going Down” during his first 2014 NZ concert. It kinda sums up life, though I’d maybe put a more positive spin and say things are crap then they get better”.

<start quote> 
It goes like this.

Everything is alright. And then … it’s not.

Everything is alright. And then … it’s not.

Has anybody experienced that?

One minute everything is fine … and then … it’s not.

Why does that happen?

Now generally the answer I get is: one minute I’m alright … and then I’m not.
<stop quote, start singing>

Most things don't matter.

clarke ching

Do you remember my post last week about "quiet" Agile and why I worry that some agile practices put introverted people off Agile?

No? 

Me neither. 

oOo

It doesn't matter.  

Most things in Agile don't matter. 

But a few do.  

oOO

Here's the one thing that matters most:  Principle 1 of the Agile Manifesto, "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software."

Just about everything else is detail or opinion. 

Quiet Agile - or "why I want my own door".

clarke ching

Every so often you read something on the internet about some "disfunctional" modern family who come down to breakfast (in a hotel, say), sit down then promptly ignore each other, their noses buried inside their tablets.  

"Disgraceful!", say the commentators, "the family should be talking, not ignoring each other.  What has the world come to?  Technology is ruining the world!"  

Well, maybe.  But maybe not.  

Imagine, instead, that this wee story took place 40 years ago, and there's no iPads, just the things it replaced.  The family comes downstairs and the Dad is carrying a newspaper which he and his wife split then share, each quietly flipping through the pages, occasionally passing comment on articles of mutual interest, while they eat their breakfast, quietly.  Meanwhile, 2 of the 3 kids play a quiet game of battleships using the portable version of the game, which they always take on holiday with them, while they eat their cornflakes.  The third kid has her nose stuck in a Lord of the Rings book which she's desperately trying to finish before they leave for the day -  reading in the car makes her feel a little sick. 

Maybe what you're seeing here is not a dysfunctional family, but a happy family which enjoys each other's company AND quiet time.  The tablet is a red herring.  Some people - extroverts - enjoy loads of chatting and interaction, while other people - introverts - enjoy quiet time spent inside their own heads.  This family might be a family of introverts, being judged by people who have different intrinsic preferences.

I'm one of the quiet people and so are many of the people I work with.

We prefer going home and spend time with my family in the evening, than going to a noisy pub where we can't half the conversations which go on.  Others are the exact opposite.

We'd rather sit at our desks typing - thinking with our fingertips - than in a meeting room drawing pictures on a wall.  Others are the exact opposite.

We prefer quiet time because that's how we recharge our batteries.  We get exhausted when there are a lot of people around.  Others are the exact opposite.

oOo

I call my approach to Agile "slow and quiet" - the quiet bit is what I want to chat about today.

The short version:

  • One-third to half of the general population - and probably more in the software development population -  are INTROVERTS.
  • We prefer quiet working environments with high-quality 121 collaboration, very few big group sessions, and lots of screen time.  
  • Most modern office environments don't work so well for us - they're too loud, they're too busy, there are too many interruptions.  We crave quiet and sometimes the best we can do is shelter behind our earphones - if we are allowed to.
  • Some Agile practices are really hard and unpleasant for us. 
  • Which causes some people to push against Agile because they don't like it.  

[Technically, I'm an "ambivert" which means I'm bang smack in the middle of the extrovert/introvert continuum.  Some say ambiverts have the best of both worlds, but I think I have the worst of both: I crave quiet AND talking with people, which gets confusing at times.]

oOo

I hope you're getting the drift, but just in case, go listen to Susan Cain's fantastic ted talk on the Power of Introverts, because, frankly, it is outstanding and awesome and (for many of us) life changing:   

That video really did change my life.  Before I watched it and read her book I thought I was just a bit odd and anti-social.  It turns out that there are a lot of people who prefer the quiet life, it's just that we don't like to talk about it ...

Here're links to her book and her website.

Is Agile extrovert biased?

I don't know if Agile is extrovert biased or not.  It is certainly more extravert friendly than software development used to be.

When I started working in software development we worked in old, ugly cubicles, with big walls around us which didn't give us our own office, but gave us our own private little working space, and if you wanted to talk to someone you generally had to stand up and go talk to them.  It was quite.  When I started working we tended to work on tasks, by ourselves, which usually took a few days or even weeks to complete.  When I started working, every so often, a bunch of us would meet up and draw away on white boards then, once we'd done enough collaborative work, we'd go off and write stuff up, which we'd usually review via email (or, yes, it's predecessor).

I think it's fair to say that, way back then, we worked in an introvert friendly environment.  

And you know what?  It used to drive me crazy.  Why?  Because, like I say, I'm an ambivert and the extrovert part of me craved conversation.  I used to drive others crazy coz I'd chat any chance I got and most of them just wanted to get on with their work, quietly.

Nowadays things are very different.  We have open-plan offices, with just a few privileged folk possessing their own door .  Many of us work on tasks (stories?) which take hours, rather than days, and are almost always done with a load of personal interaction and collaboration.  Some of us have half-day long planning meetings and longish interactive retrospectives every few weeks.  Many have daily stand-ups.  A lot of these practices require introverts to partake in noisy group activities which they often don't contribute to fully (because the like to think in their head, not on their feet AND because the extraverts to dominate (because if they don't speak up then nobody else will)) and which they almost always dislike.

I think it's fair to say that, nowadays, we work in an extravert friendly environment.  

And I think that's one of the reasons why Agile sometimes doesn't stick: a lot of the practices are really unpleasant for introverts.  And that probably accounts for more than half our software development population.

What I'd like.

I prefer a introvert-friendly approach to Agile.

Which is also extravert-friendly too.

If we go for just one or the other then roughly half the office is going to be unhappy.  But this doesn't have to be an either/or choice - a zero sum game - because we can do a few things a little differently which means that both populations are a bit happier AND we still collaborate.  

I've got a few suggestions below.

But first here's some more reading

Here's a iCloud keynote presentation a colleague, Karin, and I put together for one of our lunch time "genius hour"s.  You'll find some generic hints and tips there for surviving, as an introvert, in a noisy modern office. One thing that's not in there, which is so obvious that it's invisible, is that the extroverts in your office have no understanding or empathy of why their way of working just doesn't work for you.  They're not being mean, it's that they assume most people are like them and like what they like.

So, here's some things you could do differently, to get a quieter version of Agile

  • I prefer to collect the input for retrospectives BEFORE THE meeting, via email. This gives everyone a chance to "think with their fingertips", at their own pace. It reduces the need for people to think on their feet and to share their thoughts out loud in front of a big group. It also speeds up meetings and frees up time to solve the problems, rather than just list them. I don't always do this but I find it especially useful when we need to dig a little deeper than usual.  
  • I sometimes do daily stand-ups less frequently (say 2 or 3 times each week) and, instead, I do a lot of the coordinating work by popping along to people's desks and having a quiet conversation. You know: "how's it going?", "do you need any help", "how much longer do you think it'll take, roughly?" - the same sorts of questions that happen in a stand-up, just 121, and usually sitting down.
  • I like it when people write stuff down. It's not the writing that's important, it's having quiet time to "think and rethink with your fingertips". Folk still need to talk about the ideas in the documents, review them, tweak them, and so on, but a lot of the work can be done quietly, sitting at a PC, or in 121 conversations.

Finally, this isn't my idea, but the folk who put together Agile came up with the Cave and Commons pattern: http://c2.com/cgi/wiki?CaveAndCommons. It's the idea that in your workspace you need a quiet work area (your cave) but you also need a work area where you can collaborate. Worth reading.

oOo

Susan Cain's book and TED talk opened my eye's up and made me realise I'd been pretending I was an Extravert, which is, frankly, exhausting.  I spoke to others and discovered I wasn't alone.  

Scaling Agile ...?

clarke ching

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.  

  oOo

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?

That's not a cake.

clarke ching

Saturday's times revealed (subscription required) that trendy wealthy folk now have two kitchens in their big houses. One kitchen is manned by a professional chef (or chefs) and provides professional quality meals for the owners and their guests. The other is for the the owners to do their own cooking - like normal people do. I expect that both kitchens look and operate very differently, even if the cooking follows the same fundamental principles.  Thing is, though, you'd recognise them both as kitchens if you saw them. 

In unrelated news, the telegraph revealed that bite-sized snoballs (a Scottish delicacy, apparently) are in fact a CAKE not a delicacy, and therefore not liable to value-added-tax. TWO judges applied a number of quite practical tests (including eating them and other cakes) before making their ruling.  The inland revenue folk had preciously decided snoballs weren't a cake but the makers claimed they were and it was worth £2m in tax. You'd think it'd be quite clear what a cake is, and what a cake is not, but, well, it's not.  

"A Snowball looks like a cake. It is not out of place on a plate full of cakes. A Snowball has the mouth feel of a cake", [ond judge] added. 

image.jpg

oOo

So: many kitchens, many cakes.  

Likewise, IMHO, there are many types of Agile. Some big; some small. Some programmer centric; some pm centric; some business centric.  Some good, some bad. Some using new technology, many not. 

Likewise two people may look at the same "agile" development team and one will see an agile team while the other won't.  If you got judges in to compare the two teams the judges would see many similarities and many differences but how would they know whether one is Agile or not?  They'd be wrong, IMHO, to try to apply a cake-test because agile isn't binary.   

Why am I sharing this?  Because I've chosen to do Agile in businesses that look a whole lot less Agile than the case studies you see at conference and in text books.  As I reveal more about how I "do agile" you're bound to react, occasionally, "but that's not agile" and you'll be right and wrong at the same time.  

I'm just giving you a heads-up, is all.  

oOo

Earlier this year, for instance, a very large consulting company reviewed one of the large "agile" projects I have worked with and they said it wasn't very agile.   They were right - if you campare it with a small XP start-up - and they were wrong - when you compare it with what the project looked like a year (or even 3 months) earlier. Part of my job, which I'd kicked off a year earlier is to reframe agile as a "getting better" process where better means we are shipping important, valuable, high-quality software often, so my colleagues agreed with the consultants assessment, albeit with context. 

A big part of what I do is frame Agile as a process of getting better, rather than a bunch of technical practices. Loads of agile folk so that but I just want to point out that, for me, it is enormously important. Otherwise people get dispirited, they lose interest, abandon Agile - saying it doesn't work. 

If Agile doesn't stick the it isn't very Agile ...