8. The Rule
Roles Events Artifacts
Product Owner The Sprint Product Backlog
Scrum Master Sprint Planning Sprint Backlog
The Team Daily Scrum Remaining Work
Sprint Review Working Software
Sprint Retrospective
The Product Owner is responsible for maximizing the value of the product and the work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals. The Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog management includes: Clearly expressing Product Backlog items; Ordering the items in the Product Backlog to best achieve goals and missions; Ensuring the value of the work the Development Team performs; Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and, Ensuring the Development Team understands items in the Product Backlog to the level needed. The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable. The Product Owner is one person, not a committee. The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a backlog item’s priority must convince the Product Owner. For the Product Owner to succeed, the entire organization must respect his or her decisions. The Product Owner’s decisions are visible in the content and prioritization of the Product Backlog. No one is allowed to tell the Development Team to work from a different set of priorities, and the Development Team isn’t allowed to act on what anyone else says.
The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint. Only members of the Development Team create the Increment. Development Teams are structured and empowered by the organization to organize and manage their own work. The resulting synergy optimizes the Development Team’s overall efficiency and effectiveness. Development Teams have the following characteristics: They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality; Development Teams are cross-functional, with all of the skills as a team necessary to create a product Increment; Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule; Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole; Development Teams do not contain sub-teams dedicated to particular domains like testing or business analysis.
The Scrum Master is responsible for ensuring Scrum is understood and enacted. Scrum Masters do this by ensuring that the Scrum Team adheres to Scrum theory, practices, and rules. The Scrum Master is a servant-leader for the Scrum Team. The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team. Scrum Master Service to the Product Owner The Scrum Master serves the Product Owner in several ways, including: Finding techniques for effective Product Backlog management; Clearly communicating vision, goals, and Product Backlog items to the Development Team; Teaching the Development Team to create clear and concise Product Backlog items; Understanding long-term product planning in an empirical environment; Understanding and practicing agility; and, Facilitating Scrum events as requested or needed. Scrum Master Service to the Development Team The Scrum Master serves the Development Team in several ways, including: Coaching the Development Team in self-organization and cross-functionality; Teaching and leading the Development Team to create high-value products; Removing impediments to the Development Team’s progress; Facilitating Scrum events as requested or needed; and, Coaching the Development Team in organizational environments in which Scrum is not yet fully adopted and understood. Scrum Master Service to the Organization The Scrum Master serves the organization in several ways, including: Leading and coaching the organization in its Scrum adoption; Planning Scrum implementations within the organization; Helping employees and stakeholders understand and enact Scrum and empirical product development; Causing change that increases the productivity of the Scrum Team; and, Working with other Scrum Masters to increase the effectiveness of the application of Scrum in the organization.
Notes:Talk about:How ARIC (Accountable, Responsible, Consults and Informed) relates to ScrumCommitted (pig) is the equivalent of A(ccountable) and R(esponsible)Involved (chicken) is the equivalent of C(onsults) and I(nformed)http://henriklarsson.wordpress.com/2009/09/27/daily-scrum-is-for-pigs/ for more…Poka-yokeMontessori MethodAgile IT has concepts like continuous integration, test automation and tracing and loggingAll three are learning procesesStandard feedback loop: Plan -> Do -> Check -> Act Ken Schwaber introduced the concept of chickens and pigs with the daily scrum. Each attendee is either a chicken or a pig. The metaphor comes from the idea of a project to make breakfast of bacon and eggs. In such a project, the pig is said to be committed but the chicken is merely involved. Committed and involved could be mapped to the ARCI (Accountable, Responsible, Consults and Informed) designations for roles and responsibilities. This might help to map an agile process into a more formal or traditional organization. This CI or pig and chicken designation removes the problem of command and control by merging the doing, with the giving of orders. Committed designation allows for empowerment and its alter-ego self-organization. Committed allows for shared responsibility (in the common sense) and shared ownership. Everyone on the team, doing the work is committed and they are all jointly accountable. Those that are only Involved (chickens) are allowed to attend the Scrum meetings, but they are there only as observers. Doing the right thing, the right way at the right time Let people figure out the right thing to do, and then do it while letting them be creative. This is at the core of the “Toyota Way” as referenced by the Harvard Business Review article. It was an interesting case study on what happens when teams are empowered (and made accountable) for delivering results. In contrast, the American way (UAW) had been that individuals were responsible for individual components such as bumpers and engines where the Toyota teams were responsible for the final product. This yielded a faster-built of greater quality. This may sound very easy, but is hard to implement. Over time it will lead to improved productivity and work will actually become a pleasure! The Toyota philosophy knows the concept of Poka-yoke, ‘mistake proofing a device by preventing, correcting, or drawing attention to human errors as they occur’. Poka-yoke is a means of building quality into the device since it prevents making mistakes. It doesn’t only have an effect downstream. In combination with ‘stop the line’ (stopping production and finding the root cause of defects) this also works upstream. Maria Montessori, the inventor of the (child education), uses the same concept. The Montessori Material has a build in ‘control of error’. The children work with the material but don’t need the teachers assistance to check their own work. The check is build in. to build quality within the development process and within the IT solution. Guessing whether the solution works is not necessary, nor a lengthy manual testing phase. You get instant feedback on the quality of the solution. (Of course test automation does have it’s price). When the solution has gone into production, build in tracing and logging helps locating and fixing problems.All three cases share the concept of ‘quality build in’, but that’s not the true connection. The true advantage of ‘quality build in’ lies in increasing the learning capacity. The effectiveness of the learning process is greatly influenced by the feedback cycle. We need feedback to determine if what we do is right. The shorter the feedback cycle, the better. Building quality into the process and product shortens the feedback cycle substantially. The true connection between the Montessori Method, The Toyota Way and Agile IT is that all three are learning processes.
