Tag Archives: org

Poppendieck: implementing lean software development

notes from implementing lean sw dev, from concept to cash (amazon.co.uk) , by Poppendieck, ch 2 on infoq
(my emphasis)

Principles are underlying truths that don’t change over time or space, while practices are the application of principles to a particular situation. Practices can and should differ as you move from one environment to the next, and they also change as a situation evolves.

Principle 1: Eliminate Waste

A big form of waste in software development is “churn.” … we’ve often encountered “requirements churn” in the 30 percent to 50 percent range, and we’ve seen many test-and-fix cycles that take twice as long as the initial development time. We’ve found that software development churn is always associated with large inventories of partially done work. When requirements are specified long before coding, of course they change. When testing occurs long after coding, test-and-fix churn is inevitable. Unfortunately, these types of churn are often just a precursor to the ever larger churn created by delayed (aka big-bang) integration.
But far and away the biggest source of waste in software development is extra features.

Myth: Early Specification Reduces Waste ….

Principle 2: Build Quality In ….

Myth: The Job of Testing Is to Find Defects ….

Principle 3: Create Knowledge ….

MacCormack has identified four practices that lead to successful software development:
1. Early release of a minimum feature set to customers for evaluation and feedback
2. Daily builds and rapid feedback from integration tests
3. A team and/or leader with the experience and instincts to make good decisions
4. A modular architecture that supports the ability to easily add new features

Myth: Predictions Create Predictability

Predictable outcomes are one of the key expectations that the marketplace imposes on companies and their senior management, and these expectations eventually flow down to software development. Unfortunately, software development has a notorious reputation for being unpredictable, so there is a great deal of pressure to make it more predictable. The paradox is that in our zeal to improve the predictability of software development, we have institutionalized practices that have had the opposite effect. We create a plan, and then we act on that plan as if it embodies an accurate prediction of the future. Because we assume that our predictions are fact, we tend to make early decisions that lock us into a course of action that is difficult to change. Thus, we lose our capability to respond to change when our predictions turn out to be inaccurate. The solution to this problem, it would seem, is to make more accurate predictions.

We forget that the predictions of the future are always going to be inaccurate if they are 1) complex, 2) detailed, 3) about the distant future, or 4) about an uncertain environment. No amount of trying to make these kinds of predictions more accurate is going to do much good. There are, however, well-proven ways to create reliable outcomes even if we cannot start with accurate predictions. The idea is to stop acting as if our predictions of the future are fact rather than forecast. Instead, we need to reduce our response time so we can respond correctly to events as they unfold. In order to increase the predictability of outcomes, we need to decrease the amount of speculation that goes into making decisions. Decisions that are based on facts, rather than forecasts, produce the most predictable results.

Principle 4: Defer Commitment ….

Myth: Planning Is Commitment

…. But in the commercial world, wise businesses (such as Toyota) realize that sticking to a detailed plan is not healthy, and measuring process capability against ones ability to do so is measuring the wrong thing. Let’s not succumb to the myth that planning is the same thing as making a commitment. We should plan thoughtfully and commit sparingly.

Principle 5: Deliver Fast

Myth: Haste Makes Waste

…. Caution: Don’t equate high speed with hacking. They are worlds apart. A fast-moving development team must have excellent reflexes and a disciplined, stop-the-line culture. The reason for this is clear: You can’t sustain high speed unless you build quality in.

…. There are two ways to achieve high quality. You can slow down and be careful, or you can develop people who continually improve their processes, build quality into their product, and develop the capability to repeatedly and reliably respond to their customers many times faster than their competitors.

Principle 6: Respect People ….

Myth: There Is One Best Way ….

Principle 7: Optimize the Whole

…. Vicious Circle No. 1 (of course, this would never happen at your company):

  • A customer wants some new features, “yesterday.”
  • Developers hear: Get it done fast, at all costs!
  • Result: Sloppy changes are made to the code base.
  • Result: Complexity of the code base increases.
  • Result: Number of defects in the code base increases.
  • Result: There is an exponential increase in time to add features.

….  outsourced call centers working under the traditional revenue model have no incentive to find and resolve the causes of customer problems.
Crossing organizational boundaries is expensive.  ….

Myth: Optimize By Decomposition

…. People have a tendency to decompose complex situations into small pieces, probably a legacy from the efficiency experts who divided jobs into miniscule tasks. After decomposition, each piece is measured and each measurement is optimized. You would expect that when all of the individual measurements are optimized, then the overall system would be optimized too. But you would be wrong. If you break a value stream into silos and optimize them separately, experience has shown that the overall system will almost certainly be suboptimized.
We can’t measure everything ….


the open-office trap

from www.newyorker.com/business/currency/the-open-office-trap

the open office, flourishes: some seventy per cent of all offices now have an open floor plan.

…. a growing body of evidence suggests that the open office undermines the very things that it was designed to achieve.

…. In 2011, the organizational psychologist Matthew Davis reviewed more than a hundred studies about office environments. He found that, though open offices often fostered a symbolic sense of organizational mission, making employees feel like part of a more laid-back, innovative enterprise, they were damaging to the workers’ attention spans, productivity, creative thinking, and satisfaction. Compared with standard offices, employees experienced more uncontrolled interactions, higher levels of stress, and lower levels of concentration and motivation.

….Physical barriers have been closely linked to psychological privacy, and a sense of privacy boosts job performance.

….the ability to control the environment had a significant effect on team cohesion and satisfaction.

….An open environment may even have a negative impact on our health.

….noise has been repeatedlytied to reduced cognitive performance. The psychologist Nick Perham, who studies the effect of sound on how we think, has found that office commotion impairs workers’ ability to recall information, and even to do basic arithmetic. Listening to music to block out the office intrusion doesn’t help: even that, Perham found, impairs our mental acuity.

….it seems that the more frantically you multitask, the worse you become at blocking out distractions.


work with culture through storytelling

from Nancy Duarte: Strengthen and Sustain Culture with Storytelling

stories are more than content for marketing campaigns. They’re the fuel that feeds and sustains a strong corporate culture.

good stories remind employees and customers about the values of an organization.

tell if your company has a truly story-driven culture:

Information delivery reflects a balance of analytical and emotional content

…. anecdotes or narratives that explain their origin

….high value on activities that foster understanding between people and invests in training to build communication skills