Do you remember the TV game show The Weakest Link?
The original format features a team of contestants who take turns answering and elaborate general knowledge questions. The object of each round is to create a chain of consecutive correct answers to earn an increasing amount of money for a communal pot within a specific time limit. The number of "links" in a chain are equal to the number of the contestants at the start of the show. An incorrect answer breaks the chain and loses all the money accumulated up to that point; however, a contestant can say "bank" prior to their question being asked, the accumulated money is stored, and the chain resets to zero.
I'm not sure who started it but lately I've heard a handful of my colleagues talk about "banking" the value generated by our Agile projects by releasing several times during each project's execution. Often, but not always, that's a great way of making more money - it has the opposite effect of banking in the game show.
So, maybe the next time you're encouraging your business folk to ship often, consider reframing it as "banking" the value you've already built up.
I wish I'd thought of that ... I work with some clever people.
Perhaps a silly question* but, assuming you work in software development, is your product (a) the software you create, or is it (b) the team which produces that software?
Me? My product is the people who answer (b).
*I dont actually think this this is a silly question
Johanna Rothman is one of my Agile heroes. Her books are superb. Her blogs are always eyeopening and informative. Plus, she's a downright lovely person. Can imagine my delight when she agreed to write the foreword for Rolling Rocks Downhill?
You’ve seen this movie before. You’re on a project. You’ve been told to work faster, better, and cheaper. No more “pick two out of three.” No. You need to deliver all three out of three. Especially the faster part.
Maybe one of your teammates or someone in management has the bright idea that maybe transitioning to agile or lean will help. Maybe it does in some small way. But, it’s not enough. You’re on a death march, iteration by iteration. Or, with your board, you can see that you are making progress, but you’re not working “fast enough.”
Or, you’re not delivering what your customers need. You’re still trying to “do it all.” Why? Because it takes you forever to release anything.
You know there’s another piece to this. You just don’t know what.
You need to read Clarke Ching’s Rolling Rocks Downhill.
Clarke delivers the goods with this business novel. You can see how Steve, our hero, learns about small batches, reducing work in progress, and bottlenecks. You can see how management’s typical “motivations,” such as management by objectives, doesn’t work in a team-based complex adaptive system, such as a software project.
Learn how Steve, a middle manager, who is part of the dysfunctional system, learns about small batch sizes, work in progress, and bottlenecks. He slowly learns what they do wrong. He makes changes slowly—just as you would in real life. The teams learn how to change slowly, just as they would in real life.
His management doesn’t understand what’s going on. They alternately threaten and reinforce his efforts. I see this occur all the time. The teams are so tired of working the old way, they are ready to try anything, because they can’t stand the idea of another death march project and being blamed for failure.
And, because you see all of this, you will root for the team’s success, as I did. You’ll understand the mutiny, when the project manager pushes the team one too many times. And, if you have not seen the magic of how agile, lean and Theory of Constraints can actually work in organizations, you might be surprised when the team pulls off the “impossible.”
You might think this is impossible, or because it’s a business novel, this is fiction. It’s not. I’ve seen and coached normal people, on normal teams, working normal hours, as they transition to working in this way, complete projects again and again. Clarke shows you the secret sauce.
Do you want a way out of your insanity? Is it time for you to learn how to take control of your projects, and learn how you can release a product your customers want, when you want to release it, a product that works?
You can. Read Clarke’s Rolling Rocks Downhill. You will have many “aha” moments. You will say, “Now I get it!” This book will change how you look at projects and what you think you can do about the predicament you are in.
Use the ideas here. Don’t start another death march project. If you find yourself in another impossible project, where your management wants it “faster, better, cheaper,” use this book. You will limit your work in progress, make your chunks of work small, and find your bottlenecks (to name just three of the tools) to make your project possible, instead of impossible. You don’t need to be extraordinary. You need to be diligent.
Have fun reading. I did.
Johanna Rothman, author of Jolt Productivity award-winning Manage It! Your Guide to Modern, Pragmatic Project Management
We tend to over complicate our lives, in project land, by trying to estimate "accurately". It's better to accept two things: first, we can't estimate perfectly but, second, we can work in ways where estimating imperfectly doesn't matter and where we can get better at estimating.
Today I made myself a rather nice Italian Sausage and Tomato Soup for lunch using my rather nice Soup Making Machine. I ate about half for lunch but then when I went to put the rest in the fridge, I couldn't decide what size plastic container I should use. To out that another way, I couldn't estimate how much soup there was and what sized container it would need. If I'd done this before then I probably could have guessed more easily.
So what did I do? I erred on the side of caution and picked a container, from the many, which I hoped would be a bit big. I hoped to avoid the cost of having to unnecessarily dirty a container that was too small.
You can tell from the picture below that I got lucky. My "slam dunk" container is, actually, quite full. In Agile terms this is a bit like "under promising then over delivering, blatantly and transparently" and getting unlucky, but not too unlucky. If you worked in 3 week long sprints then maybe you finished a couple of days early and had room in your container to pull forward some work - to start your next spring early.
I'm happy I didn't spend a whole lot more time trying to pick the perfect container up front. I might still be there now doing that.
I like to think, too, that the next time I need to store soup I'll have a little history up my sleeve, having calibrated my "soup estimating brain" a little and next time I'll make an even better estimate. We will see.
Don't over-think this little picture, okay, but when I'm working with teams which are new to agile, or new to me, then I like to draw them some version of this picture.
It's a picture of the development machine and, depending on your own setup you can add different roles to the diagram as suits.
The three rules are:
1. Don't put poor quality fuel in the fuel tank - it'll just cause rework and it'll lose you productivity.
2. Try really hard to not run out of fuel
3. If you do run out of fuel, improve your system, but don't just keep people inside the engine room busy by feeding them low-value fuel.
You might draw your machine differently and you might have different rules. My intention is to show people how to think with a TOC mindset without needing to know TOC.
I asked my editor to use US, rather than UK, spelling. I'm sure I'll get hassled about it but I had to choose one and one of wee books on publishing said I should use US spelling.
So there will be more zeds in the book than expected.
But - or should I say butt? - since the book is set in the UK (in a fictional Scottish city called Watt's Bridge) I needed to stick with UK dialogue. So we've stuck with ARSE rather than ASS. I tried to write around it - ie choose a different word - but, really, if you gonna call someone an ARSEHOLE (or even an ASSHOLE) or say that something is HALF-ARSED then there just aren't any appropriate synonyms.
There's this bit in one of the episodes of The West Wing where Jed explains to his wife Abbey that, when choosing prisoners to pardon, they pick a lot of low profile cases to hide, or protect, or insulate, other prisoners who they'd prefer no one else notices. The president calls these low profile cases "Packing Peanuts".
Customers of traditional software development projects do something similar: they include a lot of low value requirements so that, come descoping time, they can descope them, look unhappy about it, say they've descoped some requirements, but protect their more valuable requirements.
I never had a name for those requirements until a couple of weeks ago. Packing peanuts!
I have a hypothetical question for y’all: imagine you’ve got a chef who is great in the kitchen but you need to teach them “front of house skills” - i.e. how to interact with customers, how to handle complaints, how to keep people happy while hiding the hussle-and-bussle in the kitchen … how would you do that?
I, and a lot of my techie friends, are good technically but we sometimes have to do “front of house” stuff, and that doesn’t come naturally to most of us. I wonder how we can get better ...
My 9 year old Alice was chatting with her lovely little friend Lucy.
Alice: What would you prefer, a bigger house with a smaller garden, or a bigger garden, with a smaller house?
Lucy: A smaller house with a bigger garden.
Alice: Me too. That way we'd have room to play in the garden and, if we got more money later, we could add on to the house
I didn't hear the following saying until last year, so I don't know if it's common:
"Cut your coat according to your cloth"
It means to make the most of the limited money/resources you've got.
It kinda sums up the fixed budget/date and variable scope way of making Agile promises.
The sentiment also applies to how you adopt and adapt agile: don't moan about your situation being imperfect for agile (old ugly code? A disengaged customer? A dispersed team? Average staff?), do make the most of what you've got ... And then make it better.
This is getting serious. I've chosen 8 potential covers for my book but I'd realllllly appreciate your help whittling them down to just 1. It should only take a couple minutes.
If you can help, please vote here: https://99designs.co.uk/book-cover-design/vote-62h77u.
Here's something I like about work: every month we have a Genius Hour.
That hour happens during a lunch break and between 20 and 30 people turn up (during their lunch break) for each session. I organise the session but it only takes me an hour or so each month.
What do we do during these hours? This month one of my workmates is presenting a "beginners guide" to the Raspberry Pi, complete with real live stuff. Last month one of our colleagues, a trained physicist, gave a talk on "Critical Thinking" - I missed it but people loved it. Before that we had a bunch of lightning talks. And before that we had a session on Introversion and the book Quiet.
This stuff is really easy to organise. It's a little different. And people like it.
Why not give it a go yourself?
I'm crowd-sourcing my book's cover using 99Designs. You should click the link to see how clever it is. I pay them £300 then a bunch of designers take the brief for my book and go off and quickly come up with a draft design. I then chose a few finalists in the "contest" and those folk polish their draft. I chose a winner.
It works for me because I get a whole lot of different ideas for a fixed price - and If I want to attract better, or more, submissions then I pay more - i.e. set a bigger prize - so that it's worth the better designers' time.
It works for the designers because, although they don't always win, their drafts don't take much time and if they're good enough they'll win some of them.
It reminds me of how Zara does product development: makes loads of stuff, try to sell it, if it sells then make more.
I decided today to practice what I preach and publish Rolling Rocks Downhill as a series.
I'll start the final edits for "RRD book 1" (the current beta) shortly, aiming to publish it early next year. Book 1 ends with a cliff-hanger.
I'll release “RRD book 2” in 2015 or 16. It'll be slightly shorter book (a novella?) and ... it will end with a cliff hanger. “RRD book 3” will follow and ... so on …
I discovered today (if you click the link, search for "cliffhanger") that this is how books were published in the old days.
So, books used to be published in an Agile way.
Apparently Dickens worked this way:
I spent a lot of time with my Dad when I was back home in New Zealand this year. He's a farmer (at heart) and I'm a computer scientist (at heart), and, honestly, we've never had anything in common work-wise, but we get along just fine.
At one stage, while sitting in his boat fishing, he asked me, "What is it you do in your job?"
I said, "Ahhh", because it's hard to enough to explain my job (or Agile) to people who work with computers, let alone a gnarly old farmer who's been semi-retired for the last 10 years and used a computer for the first time when he bought an instruction manual for rebuilding his bulldozer.
My only option, really, was an analogy, but since my dad is a very concrete person it had to be a very concrete analogy. I thought a moment ...
I said, 'You remember how, when I was little, you built your garage and we then lived in it while you helped the carpenter built our house?'
"You remember how we then moved into the house and, when I was about 10, you built on the conservatory?"
"You remember how, some time after I left home, you replaced the conservatory and extended the front room out and bought that huge telly?'
"And, you remember how, a few years ago, you extended my old room and put in your air-con and ensuite? And how Mum now wants to replace the kitchen?"
'Well, I help businesses improve themselves just like you built up your house. They can't afford to build the whole thing perfectly up front, they don't usually know what perfect even looks like, and they want to start using their improvements this year, rather than waiting 5 years, or 20."
"And that's what you do?"
"But do you do that with computers, rather than hammers and nails?"
Five minutes later and Dad said, "And when you do this, do you talk your 2nd son - the practical one - into becoming a builder so it's cheaper to keep extending your house?"
I hope this helps.