Scrum is. A framework for developing and sustaining complex products. Lightweight Simple to understand Extremely difficult to master

Transcription

1

2

3

4 Scrum is A framework for developing and sustaining complex products Example: software development Lightweight Simple to understand Extremely difficult to master

5 Scrum Is grounded in empirical process control theory. Three pillars uphold every implementation of empirical process control: transparency, inspection, and adaptation. Employs an iterative, incremental approach to optimize predictability and control risk. It is dependent on frequent inspection and adaptation to reach goals. Inspection is dependent on transparency. Scrum generates done increments of functionality using self-managing teams that are cross-functional.

6 Scrum Roles, Events, and Artifacts Roles Events Artifacts Product Owner The Sprint Product Backlog Scrum Master Sprint Planning Sprint Backlog Development Team Daily Scrum Sprint Review Sprint Retrospective The Increment (of Working Software) Note: All Events are timeboxed

7 The Scrum Framework from Scrum.org

8 Are You Doing Scrum?

9 The Scrum Test (1 of 3)

10 The Scrum Test (2 of 3) Are these created?

11 The Scrum Test (3 of 3) Do these happen each Sprint?

12 A simple measurable checklist an ordered Product Backlog Development Teams of 6+-3, self-organizing have a Product Owner who owns the backlog a Scrum Master who is responsible for process have Sprints of 1 month or less Sprints are of a fixed length a Sprint Backlog that shows Remaining Work a Sprint Backlog created at Sprint Planning working software each Sprint stakeholders who inspect the software increment Review & Retrospective at the end of each sprint

13 Scrum Adoption Profile Not Scrum Scrum High-Performance Scrum

14 The Scrum Guide Documents the Scrum framework Official rules of Scrum Maintained by Ken Schwaber and Jeff Sutherland Available at:

15

16 Nature is not Linear There are boundaries where conditions change Boundaries likely have chaotic behavior Nature is not linear, nor is software

17 Your Architecture Will Change You ll encounter boundaries Handle today s problems today and tomorrow s problems tomorrow

18 Scrum, XP and Agile started small Focused at the team level That was the problem domain when they originated We have learned a lot since then, empirically Over a decade of evolution Keeping the values and principles in place

19 Scaling is about change

20 Scaling is about integration

21 Scaling is about communicating

22 Finding new ways of organizing ourselves and our work that fit our scale We want to avoid disruptive change We want to avoid falling prey to blind spots Perhaps there isn t one right that works for all scales Plan and choose new ways that fit our scale

23

24 Why Do We Want To Scale?

25 Scaling Up You are the program manager for the next release of Macrosoft Office 10,000 story points of Product Backlog Average velocity of 10 story points per monthly sprint How many teams do you need to deliver in 10 months?

26 Non-Linear Growth Value

27 Dependencies People Domain Technology Software Implementation Culture

28 Ask some Questions First So, why scale? Can you do more with the team you have?

29

30 Professional Scrum Professional Scrum implements Scrum s mechanics, it s values and principles, and technical excellence. Professional Scrum teams are the best foundation for scaled Scrum. Professional Scrum will maximize the value delivered from scaled Scrum.

31

32 Nexus Defined Nexus noun \ˈnek-səs\ : a relationship or connection between people or things

33 The Nexus Guide Nexus is a framework that drives to the heart of scaling: cross-team dependencies and integration issues. It is an exoskeleton that rests on top of multiple Scrum Teams who work together to create an Integrated Increment. It builds on the Scrum framework and values. The result can be an effective development group of up to 100 people. For larger initiatives, there is Nexus+, a unification of more than one Nexus.

34 About Nexus TM Consists of 3 to 9 Professional Scrum Teams. Nexus is the exoskeleton of scaled Scrum. It drives to the heart of the scaling issue - continually identifying and removing dependencies created by increased complexity. It builds on the existing Scrum framework and values. The result is an effective development group of up to 100 people using best industry practices. For larger initiatives, creating product families or interoperating functional units, we create Nexus +, a unification of more than one Nexus.

35 The Nexus Framework from Scrum.org

36 Nexus Roles, Events and Artifacts Roles Events Artifacts Development Teams The Sprint Product Backlog Nexus Integration Team* Nexus Sprint Planning* Nexus Sprint Backlog* Product Owner Sprint Planning Sprint Backlog Scrum Master Nexus Daily Scrum* Integrated Increment Daily Scrum Nexus Sprint Review* Sprint Review Nexus Sprint Retrospective* *Nexus specific

37 Nexus Sprint Planning Purpose To coordinate the activities of all the Scrum teams in a Nexus for a single Sprint Creating plan(s) for the next Sprint Identify In-Sprint dependencies

38 Nexus Sprint Planning All Scrum Team members are involved Teams share a common Nexus goal & create an individual Sprint goal Product Backlog items are not shared between teams Each team is responsible for their own Sprint Planning and forecast

39 One Product Backlog The Product Backlog is still the Product Backlog 1 Product = 1 Product Backlog

40 The Product Owner The job requirements remain largely the same, but the method for fulfilling those requirements must evolve with the needs of the product Establish a solid vision Involve development team in design (empowerment) Only get involved in specific decisions if team needs help Build the ability to do your work into the product so you can scale with product growth

41 Multiple Product Owners One Product Owner at the highest level of development is responsible for the vision, clarification, ordering, and ultimate value delivered by the software This Product Owner can have other Product Owners reporting to him/her who own further decomposition of the Product Backlog Multiple Product Owners may be required due to Inadequate domain knowledge on teams Complex dependencies Limited availability

42 Nexus Sprint Backlog A mechanism to view all the Product Backlog items included in a Sprint Visualize cross-team dependencies Updated at least daily

43 Nexus Daily Scrum Focus on each team s impact on the integrated increment Confirm the previous day s work was successfully integrated The Nexus Sprint Backlog can be used to highlight dependencies The output of the Nexus Daily Scrum serves as input to the individual Daily Scrums

44 Nexus Sprint Review Get feedback on the Increment The integrated Increment represents the effort of multiple teams Use practices to ensure that the right information is presented to your audience Replaces the Scrum Team Review

45 The Nexus Integration Team Accountable for a successfully Integrated Increment A Scrum Team with full or part-time members Membership in the Nexus Integration Team takes precedence Composition may change between Sprints

46 The Purpose of the Nexus Integration Team The Scrum Teams will do the integration work; however, the Nexus Integration Team remains accountable Activities include Helping to coordinate work between the teams Raise awareness of dependencies as early as possible Ensure integration tools and practices are known and used Serve as consultants, coaches, and communication links Sometimes even assist with the work Facilitate shared architecture/infrastructure

47 Nexus Sprint Retrospective Allows for shared challenges to be raised and addressed by individual teams 3 parts: 1. Representatives from each Scrum Team meet to identify shared challenges 2. Scrum Team Retrospective 3. Representatives from each Scrum Team meet to discuss any actions needed for shared challenges

48 The Nexus: Recap Scaled Scrum is still Scrum New Nexus artifacts, roles, and events help ensure a successfully-integrated Increment is developed The Nexus Integration Team is accountable for integration Integration is more than just technical integration The Nexus Sprint Retrospective is an opportunity for improvement for each team as well as the Nexus

49

50 The Challenge of Large Scale Development We have found that the self-organization of a selfcontained Scrum group of teams starts to fray and create confusion at around people and a maximum of 9 teams We have experienced this across a range of companies and industries Dependencies and integration issues are magnified Successful large scale initiatives have mastered the practices needed at a smaller scale

51 Large Scale Development Nexus+ Scale horizontally Integration must be continuous

52 Nexus+ There is no guaranteed recipe at this scale you are unique

53 Want more? Scaled Professional Scrum Workshop 2 days Scaled Professional Scrum consists of the Nexus Framework and approximately 40 practices which cause the Nexus and your scaling initiative to operate predictably. Learn and apply the practices of Scaled Professional Scrum using the Nexus framework.

54 Thank You!