Roots of SCRUM - How Japanese Manufacturing Changed Global Software Development Practices

Jeff Sutherland gave a talk on the Roots of SCRUM at JAOO 05. Jeff starts by describing the influences in his background that led to the creation of SCRUM. Next Jeff refers to Takeuchi and Nonaka’s paper and their definition of 3 project management styles. Type A (NASA), the traditional waterfall model of isolated cycles of work like requirements gathering, analysis, design, implementation, and testing. Type B (Fuji-Xerox), where work is overlapping. Processes are collapsed and handoffs eliminated. Type C (Honda), an all at once process.

Then Jeff discusses Toyota’s mission in North America and how it relates to SCRUM. The mission statement focuses on the growth of community, the stability and well being of members, and on adding value to the customers.

Toyota production is based on a different way of thinking. Through knowledge creation by synthesis of contradiction, Toyota pushed the envelope to produce high quality, high variety, and low cost all at once.
Toyota uses ba, the zen of SCRUM and Japanese manufacturing. Ba involves getting the right people at the right time and in the right place so the magic happens. Team members create new points of views and resolve contradictions through dialogue. The people get together and have dynamic interactions that create a synthesis. This environment creates emerging ideas.

The Toyota Way is Learn by Doing. It includes placing the highest value on actual implementation and taking action. If one doesn’t understand then just go ahead and take action.
You realize how little you know and you face your own failures and redo it again and at the second trial you realize another mistake … so you can redo it once again.
So by constant improvement … one can rise to the higher level of practice and knowledge.

The Toyota way allows for redundancy and failures. Failure happens early and allows for rapid learning and faster evolution. Rational and efficient approaches to emergent solutions will cause train wrecks.
Jeff describes how Scrum cuts through cost, time, and functionality barriers. SRUM is adaptive, iterative, incremental, customer driven, and delivers frequent business functionality. It is extremely simple but very hard.

Next Jeff shares some statistics that show that scrum is faster (improves productivity), better (improves quality), and produces more for less.

Adopting agile involves cultural change, and breaking down command and control. Teams need to be autonomous, transcending, cross-fertilizing. Teams need to feel totally responsible and management needs to get out of the way. Every member of the team is focused on making the team successful instead of his own self interest. The more experienced members are always available to help the less experienced. Jeff gives the Google strategy example of getting management out of the way by eliminating management jobs and just having teams of engineers with rotating team leads.

In agile, managers need to become leaders and find and utilize spontaneously created ba or help generate more of it by helping the team by providing the right space, equipment, and goals. They need to fostering love, care, trust, and commitment. Similarly scrum is based on truth, transparency and commitment. Question everything you do and if there is no value in it then do not do it.

Jeff explains that we’ve been applying the wrong process to software development. Software development is empirical process as opposed to a predictable will defined process. We need to understand how to work and monitor an empirical process by continuously measuring, monitoring and adapting the process. It will not run the same every time.

Next Jeff describes the key roles and responsibilities of the ScrumMaster, Product Owner and team. The Product Owner defines and prioritizes product features, decides on release dates and content, and accepts or rejects work. The team is self organizing and cross functional and selects the iteration goal and specifies work results. The ScrumMaster ensures the team is fully functional and productive, enables close cooperation and removes barriers.

In the 1st SCRUM implemented by Jeff, GANNT charts and job titles were abandoned. XP engineering practices were used. There was a ScrumMaster and a product owner, daily meetings, sprint planning, review, demo and retrospective.
Some of the challenges to adopting agile include organizational resistance, manager apathy, inadequate training, lack of peer support, and lack of formal guidelines.
This presentation is available at InfoQ at http://www.infoq.com/presentations/The-Roots-of-Scrum

Agile Project Management Planning and Budgeting

David Hussman gave a talk at NFJS about agile Project Management Planning and Budgeting. He started it out by discussing the various agile paths (XP, SCRUM, Crystal, and Feature Driven Development) as well as the traits of agile. These include the ability to adapt to changing business requirements, allowing the business to select features, quality testing throughout, iterative development and deployment, and emphasis on continuous user feedback.

Then David discusses the current planning techniques which include creating a project plan with specific dates and tasks. This plan is a legal requirements document and changes have to come in the form of change requests. Estimates are done early and not updated. The developers are not the ones providing the estimates, and there is rarely enough time for testing. There are no feedback loops and metric to track the plan.



Next, David described the agile release cycle which consist of project, releases and iterations. Project duration is 6 to 12 months and starts out with chartering, roadmap, personas and a product back log. A retrospective is performed at the end of the project.
Releases are 4 to 8 weeks and include release planning and retrospectives. Iterations are 1 to 2 weeks and consist of plan, build and reflect loops.

Product/Project planning determines value. It involves chartering the project by defining the goals of the project, the value to the company, and the success measures. It also involves mapping the project community to define team roles, responsibilities and commitments to the project. Finally, a product backlog is setup.

Release planning involves business prioritization, estimating course grained stories and discussing risk and architectural decisions.

Iteration planning involves the design, develop, build loop. Work is continuously integrated. Information is shared daily and questions are clarified by the customer. Stories are signed off and progress is posted.

Finally, retrospective is performed at the end of each cycle whether at the iteration, release or project level. It is used to celebrate success and vent frustration and to determine what worked, what did not work, and what to add/change/or stop.

David spends some time going over a planning exercise with the audience for the design a POS retail system. Finally metrics collections are discussed. This presentation is available on InfoQ at http://www.infoq.com/presentations/Agile-planning-and-budgetting