Essential Scrum: A Practical Guide to the Most Popular Agile Process (A Mike Cohn Signature Book)
Here is Edward Bear, coming downstairs now, bump, bump, bump, bump, on the back of his head, behind Christopher Robin. It is, as far as he knows, the only way of coming downstairs, but sometimes he feels that there is another way, if only he could stop bumping for a moment and think of it.
Incremental development is based on the age-old principle of Build some of it before you build all of it.
In Scrum, we dont work on a phase at a time; we work on a feature at a time.
In some organizations both Scrum and Kanban can be used to address the different system needs that coexist.
Iterative development acknowledges that we will probably get things wrong before we get them right and that we will do things poorly before we do them well
Of course, there is one obvious thing we could do to try to improve velocity: work longer hours. Working a lot of consecutive overtime might initially cause velocity to increase (see Overtime in Figure 7.14). Figure 7.14. The effect of overtime on velocity (based on a figure from Cook 2008) That increase will almost certainly be followed by an aggressive decline in velocity along with a simultaneous decline in quality. Even after the overtime period ends, the team will need some amount of time to recover before returning to its reasonable baseline velocity. I have seen examples of where the trough (decreased velocity area) during the recovery period is larger than the crest (increased velocity area) during the overtime period. The end result is that lots of overtime may provide some short-term benefits, but these are frequently far outweighed by the long-term consequences.
Scrum can be used for new-product development and Kanban for interrupt-driven support and maintenance.
Scrum embraces the fact that in product development, some level of variability is required in order to build something new.
Scrum is particularly well suited for operating in a complex domain. In such situations our ability to probe (explore), sense (inspect), and respond (adapt) is critical.
Scrum makes visible the dysfunctions and waste that prevent organizations from reaching their true potential.
Scrums rich history can be traced back to a 1986 Harvard Business Review article, The New New Product Development Game (Takeuchi and Nonaka 1986). This article describes how companies such as Honda, Canon, and Fuji-Xerox produced world-class results using a scalable, team-based approach to all-at-once product development. It also emphasizes the importance of empowered, self-organizing teams and outlines managements role in the development process.
So, in Scrum, we are acutely aware that finding the bottlenecks in the flow of work and focusing our efforts on eliminating them is a far more economically sensible activity than trying to keep everyone 100% busy.
The biggest drawback to incremental development is that by building in pieces, we risk missing the big picture (we see the trees but not the forest).
The sweet spots for Kanban are the software maintenance and support areas.