Book Report: Developing Products in Half the Time

I have an early new year resolution. It is to get some more value from books I’ve been reading. I have this habit of enjoying a book, getting to DONE (Finishing it…) but not getting to DONE DONE (Generating explicit takeaways that might affect the way I do things out of it). I decided to post book reports for some of the books I’m reading here on the blog. These reports will emphasize takeaways and suggestions I’m taking away with me that I think would be interesting to the blog readers as well. Let’s see whether this resolution will stick…

I’ll start with one of the recent books I finished. It is the first book by Reinertsen - Developing Product in Half the Time. This is a book from 1997 so it predates most of recent work on Agile and Lean product development. But as I tweeted while reading, it is quite timeless.

I find it especially useful for those in multi-disciplinary environments mixing Hardware and Software that are finding it hard to digest the more software-focused Agile concepts and frameworks. The principles and practices suggested here apply to Product Development in general. If you’re already familiar with Agile, Scrum, Kanban, you will find this book brings home some of the thinking of why the practices we use work.

“The true measure of the value of a model is whether it actually influences behavior. If people do not understand a model, they are less likely to let it influence their behavior” 

This applies to models like a Kanban system. The more you involve people in the design of the system, or even better give them some guidance but let them design their own system, the more the system will influence behaviour, and the more sticky it will be. The challenge is when you talk about an enterprise where multiple groups each have their system. How do you balance the desire for self-design with the desire for reuse and common language?

It’s a tricky area, but I believe a mix of shared living/evolving model/language which is extended by each group for their own needs is probably a good way forward. If we can take great ideas from evolving group models to evolve the shared model, or create a catalog of good design bits that can be used to build new models, it is even better. In the kanban community we keep hearing success stories where teams design their own system.

I need to make sure that this happens by design in organizations I’m helping. Just this week in a workshop with Project Managers from an enterprise implementation we had a discussion about this. We agreed that the shared model should be minimal and oriented towards the vision of flow. Any specific modeling that is necessary to deal with workarounds until that vision is achieved will be done locally.

Cost of Delay

Those familiar with Reinertsen’s later work will know he is quite a Cost of Delay aficionado, well actually the thought leader on the topic I would say. I’ve heard some remarks about how this is all hand waving and where can we see how all of these calculations are actually done. Well the search is over, the answer is - HERE. The chapters discussing the sensitivity models and how to integrate them to the product development lifecycle are great. I haven’t had the chance to use this, but I know where to go for reference when that time comes.

Communicating what the product will not do

One of the ways to improve clarity in early phases of the product/feature development and reduce surprises later on, is to be very explicit about what is NOT included in the specification. This might drive tough discussions, maybe even tough decisions about viability of the product/feature without those missing capabilities, but better be aware of them now.

Consider having a section of features in the release/product backlog that you clearly mark as “Will not be delivered”. Maybe add a section of “Will not even be easily feasible with the architecture choices we’re making”.

When extracting a minimal feature / business value increment, try to be clear about the other business value increments that are in this area, so it is very visible what is NOT part of the minimal feature. Talk about what stories are NOT included as well as what stories ARE included.

Forming and Energizing Teams

This is a sublime chapter in general. Hard to decide what to emphasize. In general, I find Reinertsen’s approach to teams and management helps me have more effective discussions with real world managers and executives about effective organizational structures.

Specifically, the Project Team Leader is a role emphasized in Lean Product Development, while being quite vague in Agile/Scrum. The Project Team Leader is more like the Toyota Chief Engineer (Shusa) than a typical Product Owner (or even Chief Product Owner). The Team Leader here really sounds like he’s the “CEO of the product”, while the Product Owner is not really in charge of execution.

I need to think how to balance these two approaches. BTW the Team Leader according to Reinertsen and Smith can come from Engineering, Marketing or other departments. The important thing is his ability to successfully lead the Project.

Next comes the team. One can find strong hints of Flow and Limited WIP here… The warning against fragmented teams with partial allocation of people to them, The fact that full-time team members have nowhere to hide and have higher connection to the project purpose, the dangers of over-specialization and how to deal with them. And also a discussion of motivation that gets to the core points popularized these days by Daniel Pink’s Drive.

Project Loading Rule

The project loading rule is something I’ve been using with clients even before reading the book - “The standard way of staffing projects is to simply take the projects that “must” be done and divide the people among them. Instead, we suggest that you rank order your projects. Then take your most important project and assign as many people to it as it can effectively engage. Next, do the same with the second project, excluding people already assigned. Continue until all people are assigned. Any remaining projects, even “must” do, do not get started until a project completes, freeing some resources”. 

I love this rule. But I want to add some more guidance on top of it. First, you want to challenge the current paradigm of how many people a project can “effectively engage”. I recommend trying to add more and more people beyond the prevailing norm of “effectively engaged”.

Then discuss what will be the systemic impediments that will reduce the effectiveness, and whether the organization wants to deal with them now, or add them to an impediment backlog, and limit the number of assigned people for now. This is a great way to set a vision for better projects flow and also have the impediments/roadblocks you’ll need to remove along the way.

Another question that might come up is what if the remaining people after a few projects have been chosen are not enough to effectively start a new project? Should we start it anyhow? Should we add those people to the previous projects even though it is less than ideal engagement? Should we skip to a smaller project?

Should we work on some impediments in the meantime? Should we keep them as slack? No best practice here, just some possible ideas. Have a discussion about it is my main recommendation…

Three essential things an Executive must do

Calculate the cost of delay and foster its use in making project decisions

Religiously control the start-up of new projects

Enable development teams to run themselves

Change Management

Attitude will follow Behavior. Therefore we need to focus on changing behaviors, organizational culture will follow. I’ve had quite an allergy to discussing organizational culture and telling organizations they need to shift their culture. So naturally the behavior first approach resonates with me. One of the challenges with a team-based agile pilot is that it doesn’t need enough day to day behaviour adjustments from the wider organization, so there is little chance for attitude to change. So when infrequently there is a need for the organization to behave in a more lean/agile way, it is not natural and not sticky. One of the approaches I’m experimenting with is to use Kanban at higher levels while running focused pilots with some of the teams. Following the Kanban Method will require a leaner more flow-oriented behavior on a day to day basis, which will start shifting the organizational attitude slowly but surely.

Assymetrical investment in the pilot. If you are going for a pilot, make sure you invest assymetrically in it. You need a strong enough dose of the lean/agile virus in order to overcome the organization’s immunization effect. If you do fail, next attempts will be harder and harder as the organization immunizes itself to this kind of change. This is one reason by the way that the Kanban Method makes a lot of sense in organizations with failed change initiatives. It is a different kind of change, and can fly in under the radar of the immunization system.

Enabling the team to move quickly 

One final quote that really resonated with me is about the shifting role of management, from a vice president at Xerox: “Management’s job is more that of a police escort than of a traffic cop”. This is a quote I intend to repeat when talking to managers, Project Managers, PMOs and the like.

[caption id="" align=“alignright” width=“300” caption=“Photo Credit: http://www.flickr.com/photos/kenjonbro/6261238739”\][/caption]

This short list of takeaways/highlights really doesn’t represent the breadth of information and examples in the book. I highly recommend anyone interested in Lean Product Development, especially in complex environments involving more than a few software teams, read this front to back.

Let me know if you found this useful, it might give me energies to do book reports more frequently…

Improving flow means fewer bottlenecks, faster feedback, and less wasted capacity. Explore flow advisory or let’s talk.