Rolling Rocks Downhill
Clarke Ching: Rolling Rocks Downhill ISBN:1505446511 Takes Eli Goldratt business-fiction approach to pitching Iterative Agile Software Development for a new product being created by a mature company. Heavy emphasis on bottleneck thinking.
Excerpts
Foreword: Johanna Rothman, (death-march framing)
CHAPTER ONE
"She was poached by Chaste Group, Steve, to go work on a no-frills version of our FPP."
"She doesn't know we're running late ..." I let him process a little more. "Chaste will beat us to market."
CHAPTER TWO
Wyxcomb Group had invested heavily in FPP. No one said it out loud, but it was one of those bet-the-farm investments you hear about; it was high risk, but if it paid off it was supposed to save our subsidiary.
I then opened the latest management-eyes-only update, which stated we were tracking towards a launch well after April, probably around October or November.
CHAPTER THREE
CHAPTER FOUR
My mom had lived with me and my two girls ever since my wife, Fran, passed away two-and-a-half years earlier.
CHAPTER FIVE
I dialed my other boss—my dotted-line boss—Norbert Billings, the Wyxcomb Group CIO.
Then Norbert blindsided me. "Now, tell me, did you ever contact Craig Lally?"
Total Customer Quality).
CHAPTER SIX
Catherine was a star.
CHAPTER SEVEN
CHAPTER EIGHT
Lally, and his job title was "Flow Master."
CHAPTER NINE
CHAPTER TEN
CHAPTER ELEVEN
If it's aggressive then it's no slam dunk. We should expect it to run late, right?" My jaw fell open just a little. I didn't know it at the time, but I was experiencing a stress reaction called cognitive dissonance,
CHAPTER TWELVE
CHAPTER THIRTEEN
met Craig Lally on Tuesday morning,
"There's one tool—a simple diagram—I need to show you. It's a thinking tool.
"The hand boxes represent conflicting options or choices."
"Each shoulder represents the weights we carry on our shoulders. The concerns or needs—the things that are threatened or jeopardized by choosing one option over the other."
"The top box represents your highest level needs and goals: the needs of the head, the heart, or the gut."
We'll start with D and D-prime—the two hands,
move up a level to the C box.
We need to find a short sentence
"We find that sentence by listing
wrote More control over development in the C box.
"Let's move to the B box."
"Note that D and D' conflict but B and C do not."
hunt for the mutual purpose,
"Now, it's your turn."
CHAPTER FOURTEEN
tell him off the top of my head, as quickly as I could, what the problem was.
step two was to fill out the D box by answering the question What action do I find myself complaining about?
I wrote Shipping a poor quality, inadequately featured product on February 1st in the D box.
"Our third step is to fill in the D-prime box by answering this question: What is your desired, opposite action of D?"
fill out the C box by answering What need is satisfied by the action in D-prime?
"Figuring out B and C can sometimes be tricky. If you're stuck, then try asking this question instead: What is jeopardized by doing D?"
I saw the enemy. It wasn't Chaste. It wasn't Hal or Eleanor, and it wasn't the Group. "We can't win as long as this cloud exists."
CHAPTER FIFTEEN
"Quality is just one of my three main things: Quality, Lean Thinking and the Theory of Constraints."
I suspect the die is cast for FPP—you've been working on it for many months now, after all. All you can do is wait and see what numbers come up. What we can do with FPP is use it to prevent the next FPP."
which business is your showcase?"
"The cafeteria?"
CHAPTER SIXTEEN
until about three years ago our food was barely fit for human consumption. You wouldn't feed it to a dog.
with only one change in staff and no changes in our food suppliers, we were soon cooking food our customers liked.
After a month, we were serving nearly twice as many customers as before, our average costs dropped way down, and the threat to replace us disappeared.
CHAPTER SEVENTEEN
staffs' jobs had been dumbed-down and standardized to the point where they were meant to be idiot-proof."
our soup often tasted horrible.
"No one ever tasted it before serving it."
"Can you guess what the first change was?" That wasn't hard. "Did you start tasting your food before you served it?"
in-process inspections meant for us when cooking soup. It meant we checked the ingredients were up to standards before using them.
"Within two weeks, we'd transformed the quality of our food.
"my staff already does extensive in-process inspections
Craig said, "These inspections, are they like looking at the soup or like tasting it?"
You spend thirty percent of your time fixing broken stuff?”
CHAPTER EIGHTEEN
“So which of the two processes—developing the recipe or cooking it— does your software development process resemble most?”
"To me, speaking as an outsider, your industry's core problem seems to be that you build software based on a model that is applicable to manufacturing, or cooking, but you don't do manufacturing. You do development.
CHAPTER NINETEEN
You have a mutiny on your hands."
"Launch FPP on time. Or find a new job."
CHAPTER TWENTY
"Gregor cancelled everyone's holidays—holidays
"I didn't say FPP wasn't important, Steve. I said it was futile.
Point is, none of us believe we'll make February 1st.
"And now Gregor asks us to work compulsory OverTime.
"There's a huge difference between staying late when I feel I can make a difference and working late in order to cover some manager's butt. And that's all this is."
CHAPTER TWENTY-ONE
Declan prided himself on speaking plainly. "Your Gregor has righteously messed this one up."
Although I respected his intentions, he seemed to think his job was to protect my staff from me and I didn't like that about him.
Chaste International just announced they're launching their new product on February 1st," he panted. Good thing he had switched to those orange cigars. "No way." "And worse, Hal has just issued a press release announcing that we're launching our product for sale on December 1st."
CHAPTER TWENTY-TWO
CHAPTER TWENTY-THREE
CHAPTER TWENTY-FOUR
CHAPTER TWENTY-FIVE
"We call the next step our French Revelation, which is short for French Fry Revelation.
"Our revelation helped solve two problems. First, we cooked much of our food long before we served it. So even though it tasted good fresh from the kitchen, it didn't taste so good when it hit the customer's plate."
"Our second problem was that on some days, especially rainy days, we didn't produce enough food and the staff complained. But other days we produced too much, and we chucked a lot of it."
CHAPTER TWENTY-SIX
"Do you cook in larger batches, based on demand?"
"By the end of the first month, we were serving thirty percent more customers,
"That's why we didn't change everything at once.
They thinned their menu of all but their most popular dishes.
CHAPTER TWENTY-SEVEN
since you're desperate, we will skip the debates, skip the formal process, and instead figure out whether we can apply the lessons from Cheryl's kitchen to your type of work.
CHAPTER TWENTY-EIGHT
"Does your FPP project have a forecasting problem,
"Mark and Hal kicked off FPP based on forecasts of how well it will sell when it hits the marketplace.
"Tell me, do FPP's features match your future potential customers' needs?" "I hope so, but like I said, that's beyond my control."
"Your requirements document acts like a contract then?" He glanced at the bottom of the page. "A three hundred and twelve-page contract between you and your customers?"
things you call requirements—I don't think that word means what you think it means."
"If they were genuinely required"—he made little quote marks with his fingers—"then that implies they were mandatory. And if they were mandatory, then how could your customers descope them?
When your team wrote this document, it was in fact a forecast,
Things changed; you adapted. That's good. My question is, why did you build stuff that you then had to descope?"
You can blame yourselves when your forecasted requirements are wrong, or you can change the way you work so it matters less.
How can we build software if we can't define it clearly and unambiguously up front?" He shook his head. "That's for you to figure out."
"So you'll deliver one third of the original requirements? Wow."
"But it is the most important third."
CHAPTER TWENTY-NINE
"But why on earth would she require that feature in the first place if they're not all that valuable?"
"IT resource is a scarce resource. I've got a four-year-long backlog of projects waiting to be started. Whenever a new project starts, the project's customers know that they'll only ever get one shot at getting the project right, that it will be years until they get another wedge of IT resource to enhance it, so what do they do? They ask us to build every feature they can possibly think of—even if they don't think they'll ever use it."
why haven't you stopped your customers hoarding? Surely everyone knows it happens?"
what's the equivalent of underproduction?" It only took me a moment to figure it out. "Change requests."
I will give you some homework and then meet you here very early tomorrow morning to review it.
can you draw a conflict cloud for change requests?"
"How does this help me? I can't approve any change requests in FPP."
"The only thing the FPP team will be doing between now and December is finding and fixing defects.
"The sad picture you've just painted is what you were going to do before we started talking. But things are different now. You have the pieces of the jigsaw puzzle
here's one piece of the jigsaw you might not figure out because it's counterintuitive: Sacrificing quality almost always slows things down."
"You've already identified your first two slightly smaller batches."
"My first batch ends on December 1st!" —he nodded, my eyes widened—"And … the second starts immediately afterwards!"
"Your homework—draw the overproduction cloud; review the cloud you drew when we first met; draw more clouds, if it helps.
Once you've done your clouds, then think about small batches."
CHAPTER THIRTY
Mom served up the food.
she asked me, "How much faith do you have in this Craig fellow?"
I want you to follow Norbert's direction and consider your other options, while the timing is right.
CHAPTER THIRTY-ONE
Build the best product and deliver to the best schedule. I decided the head of the cloud should be A Successful Business.
I noticed how closely this conflict resembled those on the change request cloud—the
In both cases we wanted the best product and the best schedule. But because we had set out to build a big product with no real idea of how long it would take, we had achieved neither.
I'd skipped listing the pros and cons and jumped straight to the conflict's shoulders, so I decided to go back
That was a gap-filling approach: Build something, ship it, figure out what the important gaps were, then fill them in phase two.
But the odds of actually getting a phase two? Very low.
"There is a natural priority within our customers' requirements. They only say everything is top priority because they feel compelled to hoard."
"There must be a way to get our customers to prioritize. If I can do that, then I can break the vicious circle and break this conflict."
So, since we sell features and our customers buy features, the first con of reducing features was that our products would be harder to sell.
must be possible to invalidate.
Other things in the house had plenty of extra features I never used.
I thought of Chaste again: They didn't sell feature-loaded products; they sold simple products with just enough features that were easy to understand and easy to use and easy to buy. Their products sold to eighty percent of customers, even though they only had twenty percent of the features.
CHAPTER THIRTY-TWO
Some requirements were required, but some were optional and some were guesses.
it didn't make sense to call them optional requirements. That was an oxymoron, wasn't it?
decided to call them features.
If we could get our customers to prioritize honestly, then we could reduce hoarding significantly and free up scarce IT capacity. If we created more IT capacity, we'd be able to create space that would reduce the need to hoard. I guess we'd call that a virtuous circle.
In fact, if we could just guarantee that each project had a phase two, then we'd be halfway there. But, of course, what customer in their right mind would believe that guarantee?
We also had some non-functional requirements—that
paying for different performance level.
Another word for non-functional requirements was qualities, which was short for qualities of service.
we could build a smallish version of the solution, just big enough that we could comfortably deliver it before the delivery date and within budget. Then, if we had time and budget left over, we could add on their next highest features. That sounded a lot like cooking up a medium sized batch
A small batch was a small project in which we delivered a small selection of features; not just a small selection, but a small selection of the most important features.
Would they behave differently if, instead of asking them to set in stone twelve months of work, we asked them to tell us what features they needed in the first month?
CHAPTER THIRTY-THREE
"Catherine. Could you have told us what FPP's minimum viable solution was—the bare bones solution from the War Room—way back at the start of the project?
"Can you roll forward to December, after FPP is live? Can you tell me what we should be working on next?"
"Could you have given me that list back when FPP was first kicked off?"
"You've learned a lot about the product since we started, then?"
How was Ron Mc Knight able to reschedule his CORETRAN work to suit FPP's new release date so easily? That was easy: Ron was flexible because he kept his list #2—the requests currently being worked on—nice and short and he never made commitments about the work on his list #1—the work not yet started—until he could reasonably do so.
the clever way reporters wrote articles. They put the most important stuff at the top, and then the next most important and then the next. It gave them and their editors huge flexibility.
"What are you looking for?" "A book."
"It's called Made to Stick. It's got a story in it about the telegraph system."
Ron's team works on lots of little projects. He ships new software several times each month. He's got three lists, each made up of different requests—bug fixes, small and medium sized enhancements—and they deliver a constant stream of filled requests. Every few days, bam! Another request shipped. Start the next one. Then a few days later—bam!—another one."
Sometimes they release just one request at a time,
my own French Fry Revelation. Except it was probably more geographically accurate to call it my Egyptian Revelation.
"There it is: the inverted pyramid."
CHAPTER THIRTY-FOUR
Catherine wore a paper hat with CSR written on it in thick black pen. CSR stood for Customer Service Representative.
She had just keyed her first customer application form into the software, and we watched and waited for the dialog box confirming that the transaction had completed successfully.
Three weeks earlier, I'd met Craig for a very early breakfast and explained my Egyptian Revelation—the
"Why the hell, then, did you commit to us to deliver the entire project on February 1st if you can't even tell me how long it will take you to deliver that one little feature?
"Realistically, it is more likely that the messaging technology will blow up in our face," Phil said.
We start the testing phase today, with those features as our first small batch.
"way back in the nineteenth century, journalists invented a new way of writing newspaper articles. It's called the inverted pyramid.
then the telegraph arrived. Reporters could transmit their story in hours rather than weeks, and today's news would feature in tomorrow's newspapers. The telegraph was faster, but it was unreliable for long messages.
"I want us to invert FPP by delivering the most important paragraph first,
Catherine didn't look happy. She waved her hand at the sticky-covered wall. "So, you're reneging on your promise you made at the end of the War Room. Is this just another way of descoping?"
"Yes, it is a severe descoping now, rather than later.
"But you can't tell me exactly what I'll get on December 1st?" "Nope. But if we don't change, it's probable you'll get nothing."
we'd better decide what features go in this chunk, and then in the following ones," Catherine said.
I must prioritize the features to ensure we get the best possible product within the time available." Gregor said, "You've already prioritized the stickies.
She went to the wall and grabbed one of the top three high-risk features, the one that needed CORETRAN work, and stuck it on the far right of the wall. "This is high risk, but it's far lower value than other features. I'd rather increase my odds of having the others and find a manual work-around for this one."
"We've still got budget for this project until April 1st,
"So we can keep working this way, after we go live in December?"
"In that case," she said, picking up another bunch of sticky notes and moving them to the right a bit, "I don't need these until shortly after we go live."
Three weeks later, Phil's concerns about our messaging system having come true, we finally delivered our first chunk.
CHAPTER THIRTY-FIVE
Catherine clicked Okay, dismissing the dialog box, and swapped her "CSR" hat for one that said "CUSTOMER."
"But," said Catherine, no longer smiling, "this chunk took three weeks, when we predicted it would take one or two.
"The next chunk will be hard work too, but I think we will soon be running a lot faster." "You think?"
"Can you track those two percentages, over time?
CHAPTER THIRTY-SIX
We were about to demonstrate our third chunk of potentially shippable software to Eleanor. Ten days had passed since we had finally demonstrated the first, four days since our second.
"And FPP is currently technically, but not commercially, GETS. Correct?"
Many of my analysts, and developers too, disliked doing testing—especially long runs of it.
"But anyway, that doesn't matter so much now. FPP, like we're doing it now, is different than other projects I've worked on.
This is the first time since I've been working here that analysts, developers and testers have worked together as a team."
"We have figured out a very cheap, simple way to find bugs in the software without actually testing it."
CHAPTER THIRTY-SEVEN
After a bit of chat, we realized we could have found many of these bugs without Sharon actually doing any testing. And that's what we do now. We three talk about how we expect the software to behave, before we test it, and if we disagree on how we think the software should behave then that means the requirements I wrote were probably ambiguous and Brian has probably built something different than what I intended."
I explained that ambiguous and vague specifications were very common causes of rework in software projects all around the world,
The pages were covered in red circles, maybe two or three per page. "This was something we worked on yesterday. Every red circle is a potential defect we found when Brian, Sharon and I disagreed about how we expected the software to behave."
"What I simply do not understand," she barked at me, "is why you did not have these conversations months ago, before you built the software!"
"Honestly, best practice is to keep developers and testers separate. That way, testers find more defects."
"When we work independently, we come to the software with fresh eyes and we do tend to find more bugs."
"Wouldn't you be better off using your fresh eyes to prevent defects rather than finding them?" Sharon nodded cautiously. "Though we still couldn't prevent all defects—maybe only half of them."
CHAPTER THIRTY-EIGHT
Eleanor slammed her fist down on the table. "Will you two deliver FPP on December 1st? Yes or No?"
under different … circumstances, I'd be delighted."
"Halifax and I have made a very big promise to some very important people. We cannot keep our promise unless real customers are buying FPP on December 1st."
Gregor said, "You know, Steve, if we come back with a maybe, and I think we will, then Eleanor's going to be very unhappy."
"We could easily slip back to plan A—lower our quality standards and stop producing GETS software. Then we'll hit our date, no problem.
CHAPTER THIRTY-NINE
What did Craig say about all this?" I looked down and mumbled, "I haven't spoken to him."
Craig had emailed me. Where is FPP's bottleneck?
I want you to read The Goal and follow its instructions.
Ask Cheryl to show you her bottleneck.
CHAPTER FORTY
"Soon after Craig visited, we got so busy with new customers we couldn't keep up. You could say our success was a disaster.
"We all know the secret to life is focus. But that only works if you know where to focus: your bottleneck."
"We didn't have enough clean plates during peak hours to serve all our new customers."
"Our bottleneck was caused because our dishwashers worked in big batches.
"The thing about bottlenecks is that once you get rid of one, another eventually takes its place.
"We used to be a disliked cost center, you know. Nowadays we are a much-liked profit center.
CHAPTER FORTY-ONE
He wore a T-shirt that read "I wish I could change the world, but they won't give me the source code."
that leaves the developers or the testers."
Now we're fixing defects at about the same rate we can find them.
Our regression effort is about to explode. Testing is about to become our bottleneck."
"Are you willing to let your developers do testing?"
Maybe they can automate some things that make the testers more productive."
Phil also thought we could reduce testers' waiting time by doing code builds more frequently. The build schedule was set up to minimize his developers' downtime, but his team could change things so the testers' downtime was minimized instead,
CHAPTER FORTY-TWO
"Mark told me December 1st has to be a slam dunk, or otherwise there will be consequences.
CHAPTER FORTY-THREE
CHAPTER FORTY-FOUR
"Gregor filtered my copy of your spreadsheet to highlight work with the highest test effort."
"These are all of the test scenarios needed for the Search screen.
decided I only need one search field.
CHAPTER FORTY-FIVE
we will stop our developers from batching up their fixes.
we should temporarily disband FPP's automated testing team."
"Surely we need more automated testing now, not less?" "Yes, but right now, we're doing the wrong sort of automated testing.
I've got my four most skilled and knowledgeable testers working full-time fixing broken test scripts. I'd rather we abandon the tests temporarily, since they're basically useless, then fix them later, when the UI stabilizes."
We want to pair each freed-up tester with a developer and use the synergy of their combined tester and developer brain power.
pair up another tester and developer and automate the testing of FPP's calculation engine."
"The calcs are stable, the user interface isn't.
"We never knew we had a bottleneck before, so previously we tried to keep both our teams running as fast as they could.
"We need to get ourselves some coxswains."
now that the teams are multi-functional and collaborate much more, we need someone in each team who coordinates the work of the team."
I decided to steal Craig Lally's job title and call them flowmasters.
CHAPTER FORTY-SIX
launched without the statement feature in place, but delivered it by early January? Our first statement run is mid-January."
"We have four Day Two scenarios
For the first time in my career, one of my customers had requested we work to a fixed budget, variable scope promise. Who'd have thought?
"Mark suggests we segment the product to allow us to launch FPP to fewer customer segments, provided we add others later.
"We could save a lot of pre-December work if we only take on existing Wyx-group customers.
CHAPTER FORTY-SEVEN
CHAPTER FORTY-EIGHT
CHAPTER FORTY-NINE
Do you understand the financial implications of delivering FPP in December?"
CHAPTER FIFTY
I took the kids (and my laptop and a backlog of ebooks) to the Canary Islands for a couple of weeks' sunshine.
flowmasters had created their own simple three-list systems on whiteboards, one per team,
A strangely technical email query from Eleanor.
How on FPP do you really know that your software really is GETS, considering you haven't shipped anything yet?
CHAPTER FIFTY-ONE
"While you were away, she and Norbert asked me to run an independent assessment of FPP's health."
You should have asked for help earlier."
CHAPTER FIFTY-TWO
figure out how to actually ship rather than just potentially ship.
"Mark and I want to launch FPP with basic web app functionality.
I am simply reprioritizing our list."
I know that when you add this feature I'll lose some lower priority request from my must-have list.
CHAPTER FIFTY-THREE
"The FPP web app?"
"I want one of your teams to build it. Incrementally.
Mark cancels some of his own, less important, web projects and then moves the people working on them onto FPP.
List #1 was like one of those huge, multi-page menus you get in some Chinese restaurants.
Another twenty minutes later we had a draft plan for Drop #1.
"You've inverted something from scratch."
"We just inverted our projects list?"
CHAPTER FIFTY-FOUR
Our infamous messaging system,
would not work on our production systems.
you need to initiate Plan B today."
In Plan B we reverted to the old tried-and-tested technology that the messaging system was supposed to replace.
CHAPTER FIFTY-FIVE
"I am drowning, Steve. And, just so you know, it's your stupid fault." I blinked. What now? "No one ever expected you to launch your software on time, Steve. And if Mark and I had known you would pull off your little miracle then we would have started our rollout work much sooner."
Unless I do something drastic, it's very unlikely we'll be ready to go live on December 1st."
not going to like this—if we were desperate, we could go live with the GETS features we already have under our belts."
CHAPTER FIFTY-SIX
"I need to invert my branch list then rollout to the branches incrementally."
"Mark and I want to launch in only one branch, the Watt's Bridge branch, on December 1st,
"I want a dedicated FPP sub team primed and ready, like a Formula One pit crew, to action change requests as quickly as they can based on what we learn from launching in the branch."
"Look, if our messaging system bug didn't get fixed until, say, January, could you cope with your manual systems?"
CHAPTER FIFTY-SEVEN
Two weeks later, on Friday the 17th of November, we launched FPP internally,
she demonstrated the customer level income feature, explaining how Chaste's product definitely did not have this feature.
"Mr. Steve Abernethy is in fact our seventeenth live customer. Live."
"FPP is alive and kicking two weeks ahead of schedule!"
CHAPTER FIFTY-EIGHT
"Why this timid drip-drip-drip rollout? What are you afraid of, Mark?"
"There are two excellent reasons, which my colleague Catherine will now explain."
WALK BEFORE YOU RUN. "We chose to rollout incrementally,
"The second advantage of our incremental rollout—and
that although our product is already live, we've not yet finished developing it."
"We're using the staggered rollout to test our real, live product with real, live staff and real, live customers. We want to see who buys the product and who doesn't, why they do and why they don't."
"And when is the best time for us as a business to learn and adapt like this? When it's easy and cheap, with minimum impact to staff and customers.
CHAPTER FIFTY-NINE
When Group agreed to this bet, they made it clear that if the new Future Perfect product is not a significant commercial success, then we will get sold to the highest bidder."
now that FPP is now live, Norbert wants you, come January, to work full-time for him in a new job, helping others across the group invert their projects.
"We'd prefer you stay," Eleanor said, and her serious tone made me wary.
We'd just like you to delay accepting that new job until August next year.
CHAPTER SIXTY
I was sick of the travel. Bacon can't solve every problem.
CHAPTER SIXTY-ONE
how did you manage to get this promotion but not travel?"
“I brokered a deal between Norbert, Eleanor and Halifax.
they can fork out for the airfares and fly to me.
concepts and principles I learned from Eli Goldratt and the many members of the Theory of Constraints community. I also thank Ken Schwaber, Mary Poppendieck, Tom Poppendieck, Johanna Rothman, Tom Gilb and David J. Anderson, who got me into Agile and Lean Software.
Edited: | Tweet this! | Search Twitter for discussion