Kurt's Blog

November 19, 2013

Book Review: The Principles of Product Development Flow

Filed under: Book Review — Tags: , , — Kurt Häusler @ 11:26 am

This will probably be a short review, as it has been some months since I have read the book. This book is really dense with information. Many people find it very difficult and suggest reading his previous book first. In fact at the Kanban Leadership Retreat we had a session called “Dumbing Down Don”. I had read his previous bookreviewed it here and heard the author Don Reinertsen speak probably 3 or 4 times at conferences before I read the book. Also his ideas were already well known to anyone in the “Kanban community”, so I felt well prepared and didn’t find the material particularly challenging. Actually challenging is the wrong word. I didn’t find the book particularly difficult to understand. It does however challenge much mainstream thinking in the area of the economics of product development management, so in that sense it is indeed challenging.


This is probably the best book I have read so far this year. It was an easy 5 stars on Amazon and Goodreads. I continually recommend it as the most important book for anyone using Kanban to read. Assuming one gets training or manages to understand the basics through experience or other sources, I might even consider it more important for Kanban practitioners than David’s book. The third Kanban core practice, Manage Flow, is one of the hardest to grasp, and this book is essentially the guide to this practice.

The biggest takeaway for me was the material on understanding the true costs of product development. Too many places I have worked at think cost is a simple matter of counting the hours a developer spends pushing buttons on a keyboard. This book helps highlight the importance of paying attention to other types of costs, particularly the costs associated with queues and the cost of delay. I also really like the way he brings things back to real numbers, as in financial numbers. That is something many in the agile community for example seem to avoid or at least overlook. In a lot of ways Don Reinertsen reminds me a lot of Tom Gilb. Another concept in the book that has occupied my thoughts lately is the asymmetry of payoff functions. This is the idea that we cannot expect every product to meet our desired expectations, and in fact often only a minority of products can be or should be fully leveraged in order to fund the less successful ones. Basically we should recognise and accept that most of our products will not be hits and kill them as soon as we have invested enough to realise that they will not be hits. The minority of hits should be successful enough to fund the investment in the non-hits. This is standard practice in the pharmaceutical industry for example. The question that haunts me, is how can software development service providers leverage what we know about the asymmetry of payoff functions. Service providers earn the same regardless of the level of success of the product. Could this be changed? Should we price software development services according to the level of success the product reaches in the market? It is a dysfunction splitting the organisation developing the product from the organisation that realises the value of it? One thing I am convinced of is that most software development service providers spend way too much time, effort and money on products that will not meet their market expectations. It still seems unintuitive for a software development service provider to kill a “project” that is not meeting its financial expectations, and this needs to change. Too much development capacity is wasted on such low-value work.

This book is definitely a must-read not just for Kanban practitioners, but anyone involved in developing products, especially at a management level.

Oh that reminds me, another thing that I really liked is that he uses the phrase “Product Developer” in places where we might expect to read “Manager”. He does this all through the book when discussing decisions that need to be made. Now in the real world the old “Taylorist” split between manager-thinkers, and worker-doers still exists. Even in software development. The idea that a e.g. Software Developer will be involved in an investment decision based on concrete financial information is still very foreign, but one that I see as a desirable and necessary future, and the language in this book assumes and hopefully reinforces this ideal future, which really appealed to me.


January 27, 2012

Book Review: Scaling Software Agility: Best Practices for Large Enterprises

Filed under: agile, Book Review — Kurt Häusler @ 7:51 am

I just finished reading this very enjoyable book. For me it is always interesting to see how others view agile, particularly in areas that I haven’t thought of much, as it provides me an opportunity to I guess evolve my ideas a step further. I wrote a lot of notes this time, so there should be plenty of material for an opinionated review. The first thing I should point out is that it was released in 2007, which doesn’t sound that long ago, but a lot has changed since then, so it is important to keep that in mind.


The book starts off by introducing agile, criticizing waterfall, and going into some more depth on specific named agile approaches. I went through this reasonably quickly as most of it wasn’t new to me. I did not know anything about DSDM though, despite living in Europe for 10 years, so it was nice to read about that.

Things get interesting around chapter 7. The Essence of Agile. I was impressed by the initial table about changing paradigms. It reminds us how fundamentally different the changes that need to be made are, at every level. We clearly see waterfall development on the left, and the idea is to move towards agile development on the right. My attention was immediately drawn to the row headed Management Culture. Under waterfall he writes Command & Control. Under Agile he writes Leadership/Collaborative. I am glad he did. I have been making the connection between waterfall development and command & control management before but wasn’t sure if it was quite right. Despite what many in the Kanban community think, there is a bad old management culture we are trying to move away from, and it is ok to call it command & control, and there is a better alternative that we are moving towards based on leadership and collaboration. And to me that is the fundamental context for any organization adopting agile. Agile might just be about software development, but it belongs to a larger, non-software specific packet that involves a fundamental change to the management culture. If people reject that part of it, or don’t understand it, then success will be prevented. In fact I would have almost done the diagram differently. With column headings “Command & Control” and “Leadership / Collaborative”, and had waterfall and agile as mere cells in the table next to a “software development style” row-heading. To me the management culture just seems bigger and more fundamental than the way software projects are planned and delivered. Particularly in the larger organizations that this book focuses on that probably do a lot more than just develop software.

Another thing I noticed in the table was the idea that in agile, teams bid stories. That is a concept I have not heard of before, or understand, so I intend to look into that further.

One thing he mentioned that I disagreed with was to do with the iron triangle. He wrote that waterfall fixes scope but resources and date are flexible, whereas in agile resources and date are fixed, but scope is flexible. My opinion differs in that waterfall-style (perhaps I don’t mean the theoretical waterfall model, but the approach that command & control organizations use to develop software) projects attempt to fix all three sides, whereas agile insists in at least one side being flexible. I find it perfectly acceptable that a fixed scope project is to be delivered using an agile approach, provided there is some flexibility in the delivery date, and of course costs.

Then he mentions that the heart-beat of agile is the time-boxed iteration. This would have been fine in 2007, but now we have the whole flow based development thing, and especially Kanban showing us that continuous flow can be just as, if not more agile, than iterations. A lot of the rest of the book is based on this assumption that agile implies iterations, which compromises its usefulness these days unfortunately. This is especially apparent in the section on releases. Sure meetings should always be time-boxed, but for me the concepts of cadence and flow have replaced the time-boxed iteration, providing even more flexibility and predictability.

One major premise of the book is that agile is indeed capable of “scaling to the enterprise level”. For me agile, or at least named agile approaches, have always been more appropriate for medium-sized and larger organizations as smaller ones tend not to have the problems that agile methods solve. If you are a small startup, perhaps a group of hackers working on a web based app, communicating very well informally, spending less than 10% of your time in meetings, and delivering value then you really don’t need to go throw Scrum in the mix. You already have what larger companies are looking for when they try agile. Now I wasn’t there in the beginning, but it always seemed to me that agile would be something interesting to try if I were ever in a large enough company to justify it, and from what I read a lot of the proto-agile projects where agile methods were developed were in fact in larger companies. As well as that, whenever I heard the phrase “enterprise agile” I thought of scaling complexity and focus down from the enterprise level and projects down to the story and team level. The idea of “scaling agile up” seemed contrary to the whole point, and almost an oxymoron. The misconception I had when hearing about “scaling agile up” was it is all about compromise. How can organizations get some of the benefits of true agility when they aren’t able to, or prepared to make the necessary changes. This is mostly a philosophical point, but it might be useful to explain how I was thinking as I begun reading the book.

That impression was mostly reinforced by chapter 8, and I started to worry. Not only were we talking about larger organizations (where I assumed at least the teams themselves could be small and autonomous), but teams with several hundred people. To me that is not even a team.

The next section restored my faith with the phrase “Agile is not a trivial fix, or tune-up, for what we have been doing. It is a radical change in practice and culture”. I love that for two reasons. The Kanban community, of which I consider myself a part, likes to downplay how radical it is, claiming it can in fact be done like a series of small tune ups. This might be be true for some organizations that already have a few key cultural aspects in place, but in general it is as radical a change as any other agile method. The second reason is that it is refreshing to see a word like radical in a book aimed at big serious business. I think a lot of coaches etc. try and downplay the radical nature of the changes that are about to take place, and using words like radical and observing the reaction is a good approach for seeing if key stakeholders are even ready for it.

Then he defines the component team. He actually mentions that the name “component” isn’t that important, and the teams could be focused on different things. When I think of a component I think of something that isn’t that huge, and is developed once, and from then on the team is stuck maintaining that component. I much prefer the term “cross-functional team”. And I prefer to see their focus or specialization emerge, as work gets allocated to them (or selected by them) on a variety of criteria, such as capacity, speed, cost, special skills, level of competence required, perhaps a team wants to build up experience in a certain area, or avoid a knowledge silo etc. A good manager will balance the need to expose the team to new stuff that they have to learn, with the need to get things delivered by experienced teams quickly. Over time it may appear as if the team always does work from a certain set of customers, or indeed always on a group of related components, or always does the really urgent stuff, or the critical stuff or whatever. But there are a variety of approaches that could be used. It probably depends on the type of software being developed and where the requirements come from etc.

One issue I have with teams allocated to components is that I could imagine a story, or many stories, requiring changes to several components. This would require too much communication and coordination overhead between teams. Any team should be able to do most of the work itself on any story they might end up with. You don’t want to force a constraint that all stories have to be isolated to a single component, as it requires too much technical knowledge of the architecture during story splitting. In fact during story splitting it might not even be known which components are involved. The story is really just the problem from the users point of view and shouldn’t require any technical knowledge at all to estimate, prioritize, split or write acceptance criteria for.

As far as teams go, they should be cross-functional, and they should be permanent. Projects should be allocated to existing, already gelled teams, rather than forming a team around a project. (This belief was strongly reinforced by reading The Clean Coder, which I intend to review sometime.)

And yes, if such teams don’t exist, perhaps because everyone is in functional teams within functional departments, then these inter-departmental, cross functional teams, or component teams as the book calls them, would have to be created. (The book also uses the term define/build/test team, which is better than component, but kind of over specifies the degree of cross-functionalism required. In my opinion a cross functional team should cover the whole value stream. Whether that is a subset or superset of define/build/test is context dependent).

I like that mentioned that the PO should not just prioritize customer-value-stories, but also refactoring and was it infrastructure or architecture stories. However with 2012 understanding, we would know that refactoring, infrastructure, and architecture happens, and should normally only happen as part of customer value stories. I would reword it to say that the PO should prioritize the payback of technical debt “stories” alongside customer value stories. Which is the same thing basically. A pretty minor point. I almost feel pedantic bringing it up.

I thought maybe the term technical debt was not widely used back in 2007, and that a similar book today should probably have a whole chapter on it. He does actually use the term once, later in the book I believe.

Now we come on to the topic of release planning. I actually found a lot to disagree with here, but later on in the book he actually elaborates and ends up moving closer to how I view the topic of releases etc. I am not sure if teams should be involved in release planning the way it is described in the book. I think as soon as everyone gets together and allocates specific features to specific release dates in the future there is too much pressure to stick with it. Stakeholders with a poorer understanding of agile might interpret as a promise, or might judge the team unfairly every time the plan is updated. Teams may feel under pressure to stick to the release dates no matter what, and get everything in, burning out and compromising on quality etc. I actually go so far as to not specify release dates at all. Just have a product backlog, and teams should be focused on the current iteration, and regular backlog grooming where stories for maybe the next 1 or 2 iterations can be split, estimated, and have acceptance criteria written for them.

Release planning, at least in Scrum, should be something the PO does almost in secret, by looking at the backlog, and the very roughly estimated, and not yet split stories, and combining that with the velocity to get an extremely vague idea about which stories may be finished in which iteration. If this is communicated to stakeholders, that vagueness has to be emphasized! I don’t think this is a weakness of Scrum, but for those looking for more predictability, then I recommend using Kanban, where we can use actual measurements rather than estimates. And no way should the team be expected to delivering certain features by certain dates, especially at the release level. It is hard enough to commit to an iteration, which is why the Scrum Guide has actually removed the concept of commitment and I believe replaced it with the concept of forecast.

I was always the black sheep that refused to commit to delivering the selected stories when we used Scrum at my previous employer. We didn’t use story points or velocity, work was allocated by available man-hours, and we never completed all selected SBIs. In fact “done” required testing by people outside the team, and usually occurred 2 sprints later! I claimed it would have been unprofessional for me to commit to anything given these factors, but everyone else was like “don’t be a dick, commit just means commit to give it a go and do your best, it is not a promise or anything”. I refused to use a word as strong as commitment for something so wishy-washy as “giving it a good go”.

I was very glad when the commitment was removed from the Scrum Guide. Bob Martin actually talks about the difference between an estimate and a commitment, and I agree with it 100%. A commitment is a promise. It is something that will happen. The most I think a professional developer can commit to is beginning, or working on a task. Not completing it, unless it is a small well understood task. Everything else is an estimate or a forecast. Throwing around commitment like a used tissue is just unprofessional, and reduces trust.

Needless to say. I do not support teams “committing” to delivering certain features in certain releases. We shouldn’t forget it is a PO or management responsibility to ensure that the best possible product is delivered by a certain date, and this happens automatically when the backlog is well groomed and prioritized.

I can’t remember who mentioned this, but I heard once that releases are not technical events but marketing ones. The development teams shouldn’t care less when marketing decides to take a snapshot of the currently releasable software and label it a release, perhaps in response to some market event or need. They are too busy focused on the current iteration. But the book comes back to this view later on, which is cool.

Then he started talking about estimating tasks, and assigning them to people, and I realized he was using a fairly old, and inferior, version of Scrum, where things happen in a different order. Some people, like Ron Jeffries don’t even break stories into tasks, in fact, the Scrum Guide has removed the concept of Sprint Backlog Items! It is actually the PBIs that get estimated, during backlog grooming. In the first part of sprint planning the highest priority ones are selected for the sprint according to velocity, and then the team begins to think about the solution in the second part of the planning meeting. Please use the better version of Scrum as defined in the latest Scrum Guide, it is much better than the old version, which has some problems, as described in the book.

The book doesn’t mention backlog grooming, which I consider an omission. In fact backlog grooming should have more time spent on it than any other Scrum meeting. I would say for a larger enterprise, even more time should be spent on backlog grooming, as the initial stories are likely to be larger, and require more splitting etc. The Scrum guide says no more than 10% of a teams time should be spent on backlog grooming. I would use that 10% as a good guideline for an enterprise Scrum team. That is a half-day per week, or a whole day for a 2 week sprint.

One interesting part compared a waterfall scenario with an agile one. In the waterfall scenario everything is planned years in advance, so a salesman is forced to say “no” to an important customer who needed a quick turnaround time. This was contrasted with the agile team who were able to shuffle things around and deliver the important parts on time. What I thought funny was that the salesman was actually professional enough to say “no” to an important customer. In my experience, the salesman always says “yes”, pockets the commission, and uses pressure to force the team to deliver the software in full, on time, without affecting the existing plans.

I would almost be happy to work for a waterfall organization where the salesmen knew enough about the capacity of the team, and were professional enough to say “no”.

We really don’t say “no” often enough in software development.

He mentions that agile requires forced prioritization. Well I think that has changed too. Scrum now only requires ordering, and with Kanban we don’t even order. We simply select the most important thing to do next during queue replenishment.

Another thing I disagreed with was his suggested that for new teams, “individuals work out their expected velocities” and then combine them to get an initial estimated team velocity. That is total nonsense. What is the velocity of a BA? Of a tester? How much working tested software can they deliver as individuals? It is a team measure. It can only be measured, and not estimated. If you want to do some release planning that requires velocity, you have to do one iteration first, measure velocity, then you can do an initial release planning.

A minor quibble I had was his combining Agile/Scrum Master and Team Leader in a single role. I think these are totally different roles. A team leader, assuming you need one, which is a big assumption, might allocate a task to a junior member, a Scrum Master wouldn’t. A team leader might have some authority that the SM doesn’t have. A SM is busy removing impediments to the team, and spreading agility throughout the organization. The team leader is busy developing software.

He has a “requirements pyramid” where he divides the problem domain and solution domain. For him Needs, are in the problem domain, whereas Features and Requirements are in the solution domain. I disagree with this, although it might be a minor philosophical point without consequence. For me all three are in the problem domain. For me we only start to cross into the solution domain when the team begins to discuss the solution in the planning meeting. We are only fully in the solution domain when we have actual written code.

Actually it is more than philosophical. If you think about software development, it is the process of solving problems with software solutions. His pyramid suggests that the problems are actually solved long before they get to the development team. That whoever breaks down a need into a list of features is solving the problem, and that solution is merely being thrown down the chain for the coders to type in. It is a demotivating model. The problem is a problem, right up until the team solves it. They might split the problem into smaller chunks, but they are just smaller problems not solutions.

He also has a solution continuum, where he presents a choice between a minimum solution that “provides minimum benefit but is easiest to implement” and “fully featured solution that delivers additional value”. This doesn’t make sense to me either, and indicates a poorly groomed story. The developer should always implement the simplest possible solution that satisfies the acceptance criteria, and no more. Of course the team may discuss which of a selection of implementation choices is in fact the simplest, but the amount of value that can delivered should be fixed.

There is a great section on decoupling releases from development, which I think could replace the earlier section on releases and release planning.

The “Changing the Organization” section is probably the best and most important. I had not heard of the Zen concept of “Ba” before. I think learning more about it, and discussing it with senior management and observing their reaction is a great idea to predict the level of success with agile to expect. “Creative Chaos” is another such term mentioned in this section. Any manager than smiles and nods at such terms rather than recoiling away has potential to make the most of what agile can provide.

I like the idea of management being organized into teams as well, with their own impediment backlogs. The idea of giving an aptitude test at the beginning to discover if the right attitudes to change are in place also makes sense. The book suggests more training too, in areas like product development and engineering. I would add general modern management training to the list.

Although often hiring or promoting already trained people is a good option. After all one principle I believe in, is you have to trust people to work in the way they see fit. If you hire a traditionalist manager, you have to allow him to work in a traditionalist way. Training him up in agile and expecting him to work in a way he doesn’t believe in is demotivating and disrespectful. It would be as bad as shipping me off to MS-Project training and expecting me to do waterfall planning. Most organizations have people hidden away in teams that already have the right attitude and skills, and are eager to get a chance to put them into practice. Many developers have learned a lot about agile management as a side effect of their interest in agile technical practices. I would rather promote them to a management role than try and train a traditionalist manager to work in a way he finds uncomfortable.

The section on measurement wasn’t as bad as I thought it might be. A lot of useful suggestions, and nothing too harmful.

So to conclude we have a great recipe book. I would hope people don’t apply all the recipes in advance. It is mostly fodder for chefs to consider while developing their own recipes custom made for their organization. I actually think most standard agile approaches like Scrum and Kanban are perfectly fine to start with and allow an organization of any size to discover what particular changes should be made to handles issues of scale. This book, or an updated version of it, could be a useful companion in that process. I certainly wouldn’t go picking and choosing and implementing wholesale the actual methods inside, in advance, because a big enterprise thinks they will need it. The book actually mentions as much towards the end which was good. It could do with an update though, addressing all the points I mentioned above.

January 11, 2012

Book Review: Freedom from Command & Control

Filed under: Book Review, lean — Kurt Häusler @ 7:54 pm

I read this book by John Seddon several months ago so I hope I remember everything I wanted to say about it. The subtitle is “A better way to make the work work … the Toyota system for service organisations”.

Freedom from Command and Control Cover

It is important to know what he meant by Command & Control, as the term gets thrown around a bit, and there seems to be three main usages of the term.

  • The way I have always interpreted it and used it as a negative term for basically traditional management cultures that exhibit the best known aspect of Taylorism: Intelligent managers, remote from the work, do all the thinking, and decide not only what is to be done, but exactly how and dumb, replaceable workers that repeat the physical steps determined by the manager without question. In this case the managers are both issuing commands to the workers, and controlling how they do it. This seems to be how the term is used colloquially by most of the people that I hear use it, as a kind of umbrella term for all the dysfunction-exhibiting types of culture that are at the opposite end of the spectrum from what we are trying to achieve with more modern management ideas.
  • If you look the term up in Wikipedia, it refers to the usage of the term in the military. Here command and control are divested in separate roles. Staff of senior rank issue commands in the form of strategic objectives, while those of junior rank exhibit tactical control in order to achieve those objectives. This is more of a neutral usage of the term.
  • It is also apparently part of a theoretical model devised by Henri Fayol, which I recently read about on the kanbandev mailing list, but have not yet had a chance to learn much about.

Seddon writes in the prologue a paragraph ending in “these are the principles and practices that constitute command-and-control management”. He specifically mentions the following:

  • Top-down hierarchies
  • Separation of decision making and work
  • Managers making decisions with measures like budgets, standards, and targets.
  • Managers learn that their jobs are to manage people and budgets

He also mentions that “our organisational norms are based on command-and-control thinking” and “The separation of decision-making from work, the cornerstone of command-and-control thinking, has its roots in Taylorism…”. So we can assume that Seddon is using the commonly accepted, popular definition of command-and-control.

He compares it directly to systems-thinking, in a table similar to the one on this blog post (where he compares it to “Vanguard’s System Thinking”).

Seddon targets his wisdom mostly towards service organisations, such as local authorities maintaining public flats, that have to react to customer requests in a timely efficient manner. He is inspired by Deming, and the work of Taiichi Ohno who invented the Toyota production system, the root of lean thinking, so I am not surprised to find a close correlation between the ideas in this book and the ideas expressed by the lean software development and Kanban communities. (Although lately it seems many in the Kanban community wish to place it as being a viable option for control cultures, probably for marketing reasons.)

In fact as I was reading the book, I was helping my employer, a typical command and control type company, work with Kanban. As I was reading this book I was thinking, man, if only our managers read this before attempting Kanban, we wouldn’t be struggling so much. As it happens Kanban requires a culture of high collaboration between workers and managers (managers who might not see themselves as part of a software development process but rather a larger business process of which software development is only a small part, so they felt that Kanban was only of limited relevance to them), a sense of ownership of the process amongst workers (completely different to the fear that most non-managers exhibited when Kanban expected them to go idle, or engage in process improvement) and a flow-based rather than batch-based process.

Note I said Kanban requires those things in order to work. Some people believe Kanban can actually cause those things to magically appear, as if a command-and-control manager would suddenly change his mindset after looking at a CFD. It is my experience that a collaborative culture, and a worker owned process is not a result of Kanban, but a prerequisite. But I digress, as usual.

The book provides a gentle introduction to lean and systems thinking in short easy to read chapters full of concrete, real-world examples rather than appeals to academic models and theory. Although many of the examples refer to things like call centers, and plumbing service providers, it is not hard to see how the principles apply to other domains, such as software development. Particularly anyone who has worked with service-orientation or Kanban in the software sector will easily be able to relate to the material. I did notice a lot of overlap with Reinertsen’s Managing the Design Factory, which is not about providing services nor developing and maintaining software, but rather product development, which just goes to show that the basic principles are fairly universal.

I really love the emphasis on learning, learning to think, learning to learn, learning to lead, developing people.

I love that Seddon is not afraid to attack typical sacred cows like targets, certifications and tools. I feel like a lot of people out there involved in process improvement lack some of Seddon’s guts. They fear criticizing obvious dysfunction, claiming it might be disrespecting whoever introduced the dysfunction in the first place, or continues to work in a way that perpetuates the dysfunction. Some people claim that because people gain a sense of self-worth from being really good at working in a dysfunctional way, it is wrong to correct that way because someone loses their self worth. It is a fallacy of course, it assumes the dysfunctions are the “fault” of individuals rather than the system, and also assumes that people would rather not learn new things and perpetuate dysfunction than help improve the system. I can’t imagine Seddon tacitly endorsing dysfunction to spare someone’s ego, and I can’t imagine ever deciding to adopt that approach either.

Heck it seems disrespectful to me to allow someone to keep working in a dysfunctional way rather than help them improve the system.

Anyway it is dinner time so I better wrap this review up.

I loved it, it was one the best books I have ever read, because it felt like it was directly speaking to many of the issues I was facing while reading it, and it helped give me both the courage and practical tips to help fight the causes of the problems we were facing. I consider this book, or perhaps a book similar to it as essential reading for any manager thinking about attempting Kanban. If you aren’t prepared to help fight against command-and-control by following the advice in this book then you will find Kanban rather uncomfortable, and could save yourself and your employees a lot of stress by reconsidering.

I would also recommend it to anyone working outside of software, who hopes to reach the same levels of effectiveness that those in the software development world have been moving towards with the ideas from the lean and agile communities.

Create a free website or blog at WordPress.com.

%d bloggers like this: