The Gorilla argues, rework is faster

“What do you mean you’re throwing the prototype away?”


Wally nodded, “Yeah, we’re done with it. Time to start on the production design.”


“Are you crazy?” I squeaked. “We’re a month behind schedule and you’re going to start over? Has everyone lost their senses around here?” I pointed at the prototype, sitting on my desk. “You’ve got a working model right there. You take it back to your mad scientist lab and you make that work. Sales set up a big demo with a customer next week.”


I watched Wally sulk out of my office, the prototype clutched in his sweaty hands. “Seriously,” I said to the ceiling, “what part of move fast doesn’t anyone understand? Rework the whole hardware design from scratch? What next, we’re going to rearchitect the database.”

“Probably wouldn’t be a bad idea,” a deep voice said. “It was built seven years ago for a product that didn’t have half the technology we do today.”


“Go away Hogarth,” I said without looking down from my ceiling tiles. Staring at acoustical tile can be so relaxing. Especially when the alternative is to talk to the gorilla in the room.


I could hear him shuffling across the floor (do gorillas generate static electricity when they shuffle?). “Seriously, old Wally has the right idea, you know that?”


I dropped my eyes to give Hogarth a baleful stare. “Right…. And I’ve got some great property to sell you on the moon.”


Hogarth shrugged, “hasn’t been a primate on a space mission since the 70’s. Wally is just trying to build a better product.”


I waved my hand dismissively. “Maybe, but if its late it won’t matter how good it is. He’d be redoing a ton of work if he tossed out the prototype.”


Hogarth nodded, “and by starting over, he could make the unit more efficient, more stable and more reliable. With the prototype he’s got to work around the initial mistakes. Kind of like using suction cups to put a luggage rack on a car instead of having rails built into the car to start with. It will never be the same.”


“Hogarth…” I was getting annoyed with his argument. I had real work to do.


He dropped into the chair across from me, “Or how about house painting?” My total confusion at his non- sequitur gave him a chance to continue. “To do it right, you paint more than one coat. If you try and paint just one, really thick coat, it ends up not working and will start pealing before too long.”


“Why are you hear anyway?” I snapped. “If you’re here to pester me about the prototype, forget it. It works and we just need to tweak it to make it ready to ship.”


“Oh, right,” Hogarth said. He laid a sheaf of papers on my desk. I don’t know where he produced them from and I’m pretty certain I didn’t want to know. “I’ve been writing book and I wanted you to look at it.” He held up a massive hand, “Sorry, it’s in long hand. You ever tried to use a human keyboard with fingers this big?”


“A book?”


Hogarth nodded, “Yep, ‘Conversations With The Gorilla In the Room.


I took the stack of papers from him and started to look them over. My eyes were instantly assaulted by a riot of writing. The regular paragraph structure was all but invisible underneath a multitude of struck out words, overwritten corrections, whole sentences inserted in the margins, and lines moving words, sentences and even a whole paragraph around the page. I never made it past the first page.


Looking up from the papers I looked across a Hogarth. His face was eagerly looking at me for reaction (note- Gorilla eager looks a lot like “I’m going to eat you”). “Hogarth, this is a mess, I can’t read it.” I held the page in front of him and pointed to the first paragraph. “You’ve got two sentences crossed out and three new ones hand written in. We won’t even go into the grammar issues you’ve introduced into this.”


Hogarth looked at the paper, “Yeah, well I really didn’t want to write it all over again. You can still read it, right?”


I boggled at him for a moment. “Well, yes, I can follow it. But that’s not the point. It’s like you took spit and bailing wire to your writing. It’s haphazard and inconsistent. I’ve bloody got to turn the page sideways to read this added stuff.”


“Rewriting it would have taken too much time though,” protested Hogarth.


“Hogarth,” I slipped into my professor voice. “Rewriting is part of the process. Not only does it make your work better, it makes it easier for others to follow it.”


Hogarth’s eye lit up, “Oh you mean it will work better? Kind of like the carpentry maxim of ‘Measure twice, cut once’?”


All but standing up in my chair, I replied, “Yes, precisely!…” And then I stopped dead. Looking Hogarth straight in the eyes I said “You did it to me again, didn’t you?”


Hogarth pulled a fichus branch from somewhere and began to merrily nibble at it. “Uh huh, I did.”


Hoisted on my own gorilla, again.





“Go slow to go fast.” I’ve heard that motto since I first got into project management.


Agile and Lean development practices recommend the use of rapid prototyping. In essence, build something, see how it works and then build it again, even better the next time. This is more like “Go fast, to go even faster.”


It’s no wonder then, that Big Design Up Front (Waterfall) schools of development rail against this concept. They don’t see this as incremental improvements. In their mindset it is like tossing out the baby with the bath water. You’ve got a perfectly working “product” (software, hardware, lifecycle, whatever), so why start over? This is even more insane than going into existing code and “cleaning it up.” At least with refactoring existing code you aren’t tossing out the original work.


One of traditional project managements all time favorite fables is the “Tortoise and the Hare.” We love to quote this fable. We also love the old maxim of “eight hours of planning will save eight weeks of work.” Even years into my Agile/Lean journey I  have trouble letting go of this fable.


Only this concept isn’t as full proof as I once thought it was. If you spend a year planning without any doing , you’ve got a year farther from being done and a year farther from when you validated (we hope) your requirements with your customer. In his book, The Lean Startup, Eric Ries successfully shows that rapid prototyping can be successful. He demonstrates how doing this can allow you to succeed even when the final product looks nothing like what you started with.


Yes planning is important. Planning though is not the plan. Planning is communication. Planning is making sure everyone is on board and moving in the same direction.  Only planning without doing is like trying to teach dancing by talking over the phone. If you can’t see what you’ve built, you can’t know if your plans are any good.


Like Hogarth and carpenters for centuries have said. “Measure twice, cut once.”


Let me modify that.


“Build twice, ship once.”



The Gorilla Product Owner: It takes a village

“Bob,” Jake’s tone was almost plaintive. “You’re killing me here. I thought we had this all sorted out. Didn’t we just spend three days doing ideation work?”

Bob looked pained, he wasn’t happy and it showed. “We did and I thought we were sorted as well.” He gave a shrug, “Sales got wind of the requirements and threw a royal fit that we weren’t addressing performance on the OutDate hardware.”

“They do realize it’s a fifteen year old platform?”

Bob nodded, “And they insist it’s a must have to support ‘key’ customers.”

Jake grumbled, “fine, that explains that. What about this other stuff?”

Bob winced, “My boss isn’t happy with the strategy, he wants to alter course.”

I glanced over the new proposal. I made a note to talk to Bob about the concept of the word ‘alter.’ This plan was nearly a 180 from the previous one.

Jake threw his hands up in the air, “I give up. Every time I think we’re settled and I can start planning, the entire model changes again. Who the hell is in charge of the business plan?”

I could see Bob stiffen at that one. He didn’t respond, even though I could see he was rankled by the comment. I think he didn’t respond because he knew he really wasn’t in charge, even if his job description said that he was in charge. He had tried to put together a business plan and now, every time he turned around, someone was sticking a hand in and changing it.

“Sounds like you need to start the project before you start the project?”

“What is it this time, Hogarth,” I asked with no small amount of dread. Turning to face him I continued, “I’ve got Bob fully engaged with development, they’ve been meeting regularly. I’ve got an honest to goodness PO led product backlog for the first time ever.” I waved at the business plan on the screen, “and it’s all been tossed out the window. What’s the point? We are halfway through development and this is a huge shift in direction.”

Hogarth nodded, “Which is why you need a project before the project.”

I blinked, “Wait, what? That’s Big Design Up Front! We’re agile here!”

Hogarth gave me a huge, ivory filled yawn. “We covered this already, remember? Garbage in, Garbage out?”

I pointed a finger at Hogarth, “look here, I did that. Bob went through the whole process. We even brought in Jake and his team to look at some of the requirements. Our backlog was built on real requirements this time!”

Hogarth nodded, “And who else helped?”


Hogarth gave a long stretched before fixing me with his dark gaze again. “You wouldn’t design the features without the agile development team, why design the business plan without an agile business team.”

Blink, blink. Well dang…


 A Product Owner is Not an Island

Experienced agilists will of course be saying “duh” right about now. Product owners are supposed to work with the team and collaborate towards a final product. This is good and effective, and the PO can still be an island if they do this. He just has seven other cast-aways, from his three hour cruise, on the island with him.

Beyond even the question of “how do you prioritize the business value of the backlog,” are questions like “what’s the business model,” “what’s the product concept,” and “where does the product owner get his requirements from in the first place?”

The product owner is not an island. He doesn’t sit in some ivory tower and imagine great ideas, which he then transports to the development team in a puff of smoke smelling faintly of brimstone. Our product owner, still called a product manager by many companies, instead is sometimes reduced to nearly the level of a scribe collecting all the inputs from other parties and trying to justify how to have the product be “fast”, “ultra-secure” and “cheep.” The product owner must work and take inputs from a wide variety of sources in an often dizzying array of inputs and conflicting priorities. When every organization is clamoring for their little slice of the feature pie, you can end up with a product that looks more like Frankenstein’s monster than Brad Pitt.

 That’s just the way it is, you can’t expect that to change.

 It can if you make a village.

In Garbage In, Gorilla Out I propose a new model for the early stage of a product. In what most lifecylces would call the Concept and Planning Phases I propose an iterative, agile driven, style that takes you from product ideation (vision) all the way to a well ordered backlog that the agile development teams can plan their iterations from. While I don’t speak to this in the GiGo blog, in essence, what I am espousing is an agile project where the finished product is a product or release backlog. So if GiGo is an agile project, where is the team?

In GiGo I briefly touch on the idea of the GiGo project team. It is not just the product owner that moves through the GiGo project. With her on the journey are representatives from her key stakeholders. This is not a fixed team and will vary from company to company. Ideally it won’t be more than seven, plus or minus two people which may require some team members to then go off and work with an SME team of their own. For example a representative from Technical Support might have their own Support GiGo team where they review and bring back final “product” to the primary GiGo team.

Who should be on the team? Other than the product owner, again it depends. Below is a list of common team members based on the most common roles to contribute to traditional requirements documents.

Product Sponsor Customer  (or voice of the customer)
Related product managers Technical Support
Technical Architect* Marketing
Agile coach or Facilitator Sales

While the product owner is the final decision maker, she is not the only person to have input into the creation process. When the PO works with a village, they prevent the customer, sponsor and team from getting PO’d at them.

Do you have your village?