Managing Agile Software Development Teams Using Scrum AKA: Wrangling Developers for Fun and Profit!

Peter Mourfield Director of Software Engineering

It’s Tax Season

Overview What is Scrum? Why use Scrum?

What is Scrum? A framework for Agile software development A set of rules (as defined in the Scrum Guide) Easy to learn Difficult to master

Scrum is a Framework Framework An incomplete structure which accommodates other practices, techniques, and tools while providing an overarching process. Methodology A complete set of prescribed and interrelated principles, tools and practices working together to achieve a particular goal.

Scrum Artifacts Product Backlog Sprint Backlog Increment

Product Backlog The Single Source of Truth An ordered list of everything the product needs Contains one item for every change to be made Each items minimally has a description, order, and an effort estimate Owned by the Product Owner Ordering considers risk, value, effort, need Constantly changing and alive

Sprint Backlog The set of Product Backlog items selected for the Sprint + a plan for turning them into a product increment Remaining work is summed at least daily Makes visible all of the work necessary to meet the Sprint Goal Belongs to the Development Team. No one else! Changes frequently as understanding emerges in the Sprint

Increment The deliverable at the end of the Sprint Product Owner determines what to do with it Does not include any unfinished work

Scrum Roles Product Owner Development Team Scrum Master

Product Owner Single point of accountability for product (ideally P&L) Defines the features of the Product Prioritized features Is a single person

Development Team Creates each product increment Self Organizing – Selects the work and chooses how to do it Cross Functional – Has all skills to deliver a done increment in size

Scrum Master Responsible for enacting Scrum values and practices Ensures that the team is fully functional and productive Removes impediments Facilitates team meetings Shields the team from external interferences

Scrum Events Sprint Sprint Planning Daily Scrum Sprint Review Sprint Retrospective

Sprint Is 30 days or less Limits Risk Creates focus Realistic planning horizon

Sprint Planning Time-boxed at 2 hours per week of the Sprint Scrum Team attends Requires an ordered Product Backlog Creates a Spring Backlog and Goal Forecasts the work of the Sprint Starts each Sprint

Daily Scrum Development Team creates a plan for the day What did you do yesterday? What are you going to do today? What is keeping you from getting work done? Inspect and adapt the Sprint Backlog 15 minute time-box Same time, same place each day

Sprint Review Time-boxed at 1 hour per week of the Sprint Scrum Team + everyone who cares to see Team demonstrates the Increment Team asks “What do you think?” Records feedback in the Product Backlog

Sprint Retrospective Entire Scrum Team attends Scrum Master facilitates Inspect and adapt the Scrum Team Reflect on the Sprint Create an improvement plan Commit to new behaviors or standards

Visualizing the Process

Scrum Rules Product Backlog Rules Development Team Rules Product Owner Rules Scrum Master Rules

Product Backlog Rules Visible to all who care to see it The work at the top of the Product Backlog is sized and understood by the Development Team and Product Owner Product Backlog items brought to Sprint Planning have: Effort Estimate Enough detail for Development Team to begin work Sized and scoped to fit within a single Sprint or less If Product Backlog isn’t ready, Sprint Planning is cancelled

Development Team Rules Work remaining is tracked at least daily Responsible for enacting the Daily Scrum Manages its own progress Composition remains constant throughout a Sprint Productivity is recorded each Sprint as Velocity

Product Owner Rules Maximize value of the product and work done on it Product Owner is always accountable for the management of the Product Backlog, but may delegate management activities Ensures the Product Backlog is ordered for Sprint Planning

Scrum Master Rules May facilitate any Scrum event Decides nothing about what work to do Coaches the Development Team to higher levels of quality

Why use Scrum? Software Developers are notoriously bad at estimating Software Developers are notoriously bad at communication

Software Developers are notoriously bad at estimating Time boxing Cone of uncertainty Iterative planning

Time Boxing Provides a maximum duration Acts as a container for self-organization Focuses participants on the best result possible in the time allowed

Cone of Uncertainty

Iterative

Software Developers are notoriously bad at communication Everything is open and visible Participation in Scrum Events is mandatory

Questions?