Double click anywhere & add an idea
ScrumFluenca
"Scrum was started for software teams at Easel Corporation in 1994 where I was VP of Object Technology. We built the first object-oriented design and analysis tool that incorporated round-trip engineering in the initial SCRUM."
[Jeff Sutherland: "Retrospective on SCRUM and it's Implementation in Five Companies" July 8, 2001] 
"In 1993, at Easel Corporation in 1993, we we first applied the Scrum process to software development teams when we built the first object-oriented design and analysis (OOAD) tool that incorporated round-trip engineering." 
[Jeff Sutherland: "Agile Development: Lessons learned from the first SCRUM" October 2004] 
"The first Scrum incubated at Easel Corporation in 1993 and was influenced by the birth of IROBOT's first robot, Genghis Khan. ... On this fertile ground, the Takeuchi and Nonaka paper in Harvard Business Review provided a name, a metaphor, and a proof point for product development, the Coplien paper on the Borland Quattro Product kicked the team into daily meetings, and daily meetings combined with time boxing and reality based input (real software that works) started the process working. The team kicked into a hyperproductive state (only after daily meetings started), and Scrum was born." 
[Jeff Sutherland: "Native Scene: How Scrum was Born!" December 2004] 
[Jeff Sutherland: "The First Scrum: Was it Scrum or Lean?" August 10, 2008]  
"Scrum is not a direct descendant of Lean. It derives from complex adaptive systems with an indirect linkage to Lean through Takeuchi and Nonaka." 
"The Mythical Man Month"
"No Silver Bullet" 
(Frederick Brooks)
AgileFluenca
Influenced from Mark Lombardi:
www.AgileFluenca.org
info@AgileFluenca.org

jens.korte@syndato.com
1961 - 1965
Manager for Development of IBM's 
System/360 and OS/360


 "It is a very humbling experience to make a multi-million-dollar mistake, but it is also very memorable." 
"Adding manpower to a late software project makes it later". 
Brooks Law
No Silver Bullet for the 
Monsters
„Of all the monsters that fill the nightmares of our folklore, none terrify more than werewolves, because they transform unexpectedly from the familiar into horrors. For these, one seeks bullets of silver that can magically lay them to rest.“
Costs
Deadlines
Quality (Bugs)
"There is no single development, in either technology or management technique, which by itself promises even one order of magnitude [tenfold] improvement within a decade in productivity, in reliability, in simplicity."
 "we cannot expect ever to see two-fold gains every two years" in software development, like there is in hardware development.
Adressing the essential part of the software development process!
[Jeff Sutherland: "Retrospective on SCRUM and it's Implementation in Five Companies" July 8, 2001] 
"There were some key factors that influenced the introduction of Scrum at Easel Corporation. The book “Wicked Problems, Righteous Solutions” (DeGrace and Stahl 1990) reviewed the reasons why the waterfall approach to software development does not work for software development today. Requirements are not fully understood before the project begins. The user knows what they want only after they see an initial version of the software. Requirements change during the software construction process. And new tools and technologies make implementation strategies unpredictable. DeGrace and Stahl reviewed “All-at-Once” models of software development which uniquely fit object-oriented implementation of software. The team based “All-at-Once” model was based on the Japanese approach to new product development, Sashimi and Scrum. We were already using production prototyping to build software. It was implemented in slices (Sashimi) where an entire piece of fully integrated functionality worked at the end of an iteration. What intrigued us was Takeuchi and Nonaka’s description of the team building process in setting up and managing a Scrum (Takeuchi and Nonaka 1986). The idea of building a self-empowered team where everyone had the global view of the product being built seemed like the right idea. The approach to managing the team which had been so successful at Honda, Canon, and Fujitsu resonated with the systems thinking approach being promoted by Senge at MIT (Senge 1990)." 
"Frederick Brooks has documented a variant of this approach (“all-at-once” model in "Whicked Problems, Righteous Solutions") called the “surgical team,” which IBM has shown to be its most productive software development process. "
[Jeff Sutherland: "Agile Development: Lessons learned from the first SCRUM" October 2004] 
"Much of present-day software-acquisition procedure rests upon the assumption that one can specify a satisfactory system in advance, get bids for its construction, have it built, and install it. I think this assumption is fundamentally wrong, and that many software-acquisition problems spring from that fallacy. Hence, they cannot be fixed without fundamental revision--revision that provides for iterative development and specification of prototypes and products.

Incremental development--grow, don't build, software. I still remember the jolt I felt in 1958 when I first heard a friend talk about building a program, as opposed to writing one. In a flash he broadened my whole view of the software process. The metaphor shift was powerful, and accurate. Today we understand how like other building processes the construction of software is, and we freely use other elements of the metaphor, such as specifications, assembly of components, and scaffolding. The building metaphor has outlived its usefulness. It is time to change again. If, as I believe, the conceptual structures we construct today are too complicated to be specified accurately in advance, and too complex to be built faultlessly, then we must take a radically different approach.

Let us turn nature and study complexity in living things, instead of just the dead works of man. Here we find constructs whose complexities thrill us with awe. The brain alone is intricate beyond mapping, powerful beyond imitation, rich in diversity, self-protecting, and selfrenewing. The secret is that it is grown, not built. So it must be with our software-systems. Some years ago Harlan Mills proposed that any software system should be grown by incremental development. [10] That is, the system should first be made to run, even if it does nothing useful except call the proper set of dummy subprograms. Then, bit by bit, it should be fleshed out, with the subprograms in turn being developed--into actions or calls to empty stubs in the level below. I have seen most dramatic results since I began urging this technique on the project builders in my Software Engineering Laboratory class. Nothing in the past decade has so radically changed my own practice, or its effectiveness. The approach necessitates top-down design, for it is a top-down growing of the software. It allows easy backtracking. It lends itself to early prototypes. Each added function and new provision for more complex data or circumstances grows organically out of what is already there. The morale effects are startling. Enthusiasm jumps when there is a running system, even a simple one. Efforts redouble when the first picture from a new graphics software system appears on the screen, even if it is only a rectangle. One always has, at every stage in the process, a working system. I find that teams can grow much more complex entities in four months than they can build."

Brooks, Frederick P., "No Silver Bullet: Essence and Accidents of Software Engineering," Computer, Vol. 20, No. 4 (April 1987) pp. 10-19. 
[Jeff Sutherland: "No Silver Bullet: Essence and Accidence of Software Engineering" 26 June 2006] 
"State of the Art" in Programming
Waterfall Model and the problems with it
"All-in-Once" Model: Team Approach - Sashimi and Scrum 
... others
"I have used Microsoft Project on numerous OO projects over the years. It does the job barely, and with a lot of overhead, because it is the wrong metaphor. For a good overview of Smalltalk project management, one of the best papers to read is: Pittman, Matthew (1993) Lessons Learned in Managing Object-Oriented Development. IEEE Software, Jan 1993, pp. 43-53." 
[Jeff Sutherland: "SCRUM messages from comp.lang.smalltalk and comp.object" December 21 1994 - May 12 1995] 
"Object-oriented development is best suited to an iterative and incremental style of development."
"We set out to apply existing projekt-management skills and techniques to object-oriented development. With a little common sense and some adjustment, most conventional wisdom in project-management can be applied to an object-oriented development."
"We were prodded into setting up the first Scrum meeting after reading Coplien’s paper on Borland’s development of Quattro Pro for Windows (Coplien 1994). The Quattro team delivered one million lines of C++ code in 31 months with a 4 person staff growing to 8 people later in the project. This was about a 1000 lines of deliverable code per person per week, probably the most productive project ever documented. The team attained this level of productivity by intensive interaction in daily meetings with project management, product management, developers, documenters, and quality assurance staff."
[Jeff Sutherland: "Retrospective on SCRUM and it's Implementation in Five Companies" July 8, 2001] 
small, intensly interactive organization
...more even distribution of effort across roles...
Project Manager and Product Manager are tightly coupled, central roles...
Quality Assurance is tightly coupled and a central role

Original: Wiener Schnitzel
Copy: Tonkatsu
Original: Leica I
Copy: Kwannon
Kwannon / Kannon: 
Goddess of Mercy
(Buddhism)
Continuous Improvment
Striving for Perfection
(Japanese Culture)
The Toyota Way has two main pillars: continuous improvement and respect for people. Respect is necessary to work with people. By "people" we mean employees, supply partners, and customers. ...We don't mean just the end customer; on the assembly line the person at the next workstation is also your customer. That leads to teamwork. If you adopt that principle, you'll also keep analyzing what you do in order to see if you're doing things perfectly, so you're not troubling your costomer. That nurtures your ability to identify problems, and if you closely observe things, it will lead to kaizen - continuou improvement. The root of the Toyota Way is to be dissatisfied with the status quo; you have to ask constantly, "Why are we doing this?"
Toyota CEO Katsuaki Watanabe (from "Scaling Lean and Agile Development")
grew up a nerd in Australia
build 1st computer with 10
build his version of Walther Grey's Machina speculatrix
moved to Standford AI Lab
build Genghis
Grey Walter
http://www.ai.mit.edu/projects/humanoid-robotics-group/retired-robots/retired-robots.html
http://www.stanford.edu/~learnest/cart.htm
The Fifth Discipline: The Art and Practice of the Learning Organization (Senge 1990) is a book by Peter Senge (a senior lecturer at MIT) focusing on group problem solving using the systems thinking method in order to convert companies into learning organizations. The five disciplines represent approaches (theories and methods) for developing three core learning capabilities: fostering aspiration, developing reflective conversation, and understanding complexity.

[http://en.wikipedia.org/wiki/The_Fifth_Discipline]
"The journey is the reward"
Subsumption Architecture
"You cannot make a plan of reality because there are to many datapoints, to many interactions, and to many unforseen side effects."
"The best way to build this (cognition) box, I decided, was to eliminate it. No cognition. Just sensing and action. That is all I would build, and completely leave out what traditionally was thought of as the intelligence of an artificial intelligence."

decomposing complicated intelligent behaviour into many "simple" behaviour modules, which are in turn organized into layers.
e.g. move foreward layer is subsumed by the eat food layer
Buttom up design
The key to optimization is to look for bottlenecks. What is getting in the way? Remove the obvious bottleneck and throughput will increase. Then the next bottleneck with appear. By adopting a strategy of eliminating bottlenecks one by one, the system will evolve into radically improved throughput. This is why the third key question in a SCRUM every day is, "What is blocking progress?" The primary responsibility of management is not managing a SCRUM. It is removing bottlenecks identified by the SCRUM. 
[Jeff Sutherland: "SCRUM: Removing bottlenecks is a core systems design principle" January 22, 2003] 
The story of Microsoft Word and the secret developer toolbox
"It was released years later than desired. Why? Because managers tried to follow the original schedule and pushed developers to meet it"
[Source: Craig Larman, Bas Vodde "Scaling Lean & Agile Development"]
Stanford Artificial Intelligence Laboratory
Common Cause: Noise, Natural Pattern
Special Cause: Signal, Unnatural Pattern
Control Chart
"The Japanese learned from Deming's 1950 lectures how to use Statistical Process Control as an aid to make the cheapest, most consistent, and best qualitiy products."
Juran's 1954 lectures influenced Japan's direction from emphasis on Statistical Process Control to managing for quality and on company-wide quality control.

"...the statistical tools are sometimes necessary, and often usfull. But they are never sufficient."