Agile Fundamentals Workshop

 

Glenn Waters

LinkedIn

Github

Details about These Slides

The Content

This deck primarily covers the Scrum roles and activities.

Feedback

Comments and improvements gratefully accepted! Find me on LinkedIn.

Usage

Feel free to use the material, as long as you follow the Creative Commons license.

Help Navigating

Press “?” to see list of keyboard shortcuts.

Other

The deck is built using the reveal.js framework and Jekyll.

Self organize…

Organize yourselves in response to each of the following questions:

  1. How long have you worked here?
  2. How familiar are you with Agile (Scrum, XP, etc.)?
  3. When was your last major life event?

Agile Flavours

Project Success Rates

The Basis for Agile

  1. Agile is built around the notion that change is normal
    • Requirements are not and cannot be fully known up front
    • That existing requirements will change
    • That the team will learn as they go through development
  2. Up-front work is a liability
    • Invest in too many details that are wrong, forgotten, …
    • Complexity not discoverable up front

Punch Card  (CC BY 2.0)  by Pete Birkinshaw

Defined Process

  • Defined process requires that every piece of work be completely understood
    • Not bad for known activity
    • i.e.: Reliably repeatable
  • Waterfall tries to be a Defined Process

Empirical Process

em·pir·i·cal [em-pir-i-kuhl]
adjective

Derived from or guided by experience or experiment.

Control through frequent inspection and adaptation

For work that is imperfectly defined and generates unpredictable and/or unrepeatable outputs.

Why Agile Helps

Agile Myths

  • It’s a silver bullet
  • A cookbook that you can follow and be successful
  • Easy to do
  • That there is no:
    • Documentation
    • Architecture
    • Modeling
    • Budgets
    • Planning
    • Testing
  • “I can see how it would work, but it will never work here!”
  • Tool focused – using an agile tool does not make you agile

Kaizen

Kaizen: a Japanese philosophy that focuses on continuous improvement throughout all aspects of life

Avoiding complacency and acting aggressively requires “Kaizen mind”

Inspect and Adapt Opportunities

It’s Iterative and Incremental


Embrace Uncertainty  (used with permission)  by Jeff Patton

Scrum Roles

Team


From John Katzenbach and Douglas Smith, McKinsey & Company, The Wisdom of Teams,  Harvard Business School Press, 1993

Characteristics of a Team

  • Cross functional
    • So that the team can own building the thing
  • Co located
    • To facilitate high levels of communication & collaboration
  • No titles
    • To encourage self organization and building skills
  • 5-9 people
    • To facilitate high collaboration
  • Values / principles based
    • To encourage (continuous) improvement and self organization
  • Shared leadership
  • Self organizing
    • So they own can own getting the work done
  • Long lived
    • To build shared knowledge and experience so they can go faster
  • Shared purpose / goals
    • So people helps each other achieve the goals
  • Dedicated
    • So that they can plan and commit to work together
    • To reduce multi-tasking
  • Mutually accountable
    • To encourage ownership of work

Tuckman Team Development Model

Product Owner (PO)

  • Responsible to the return on investment for the product
  • Decides what to build (not how to build it)
  • Is the single person who orders the Product Backlog
  • Accepts working software
  • Gathers requirements from the stakeholders
  • Oversees the product vision
  • Is highly available to the Team (ideally co-located)

ScrumMaster

  • Scrum guide
    • Helps the organization live the Scrum values and practices
  • Coach
    • Teaches and guides people on agile
  • Protects the team
    • From overcommiting, interruptions, complancency
    • From internal and external influences
  • Influencer
    • From a position without authority
  • Facilitator
  • See that impediments are improved upon

ScrumMaster should not…

  • Do the team’s work
  • Manage the project (Scrum does not have a project manager)
  • Manage the team
  • Book and maintain all the meetings
  • Take minutes for the team
  • Remove impediments

ScrumMaster should…

  • Share techniques for effective Product Backlog management
  • Teach how to create clear and concise Product Backlog items
  • Help PO understand long-term product planning in an empirical environment
  • Help organization understand and practice agility
  • Facilitate Scrum events as requested or needed
  • Coach the Team in self-organization and cross-functionality
  • Teach the Team to create high value products
  • Remind team of experiements they were going to run
  • See that impediments are improved upon
  • Coach the Team in organizational environments in which Scrum is not yet fully adopted and understood
  • Lead and coach the organization in its Scrum adoption
  • Plan Scrum implementations within the organization
  • Work with other ScrumMasters to increase the effectiveness of the application of Scrum
  • Cause change that increases effectiveness of the organization

Scrum Events

The Sprint

  • Up to one calendar month in length
    • Smaller is better: learn more quicker
    • 2 weeks most popular length
    • Recommend no longer than 2 weeks
  • Sprints limit risk to cost of the length of Sprint
  • Sprint length does not vary from Sprint to Sprint
  • Sprint has a goal: a short description of what the team plans on acheiving during the Sprint
  • Outcome of the Sprint is Potentially Releasable Product Increment

Sprint Cadence

  • All activities timeboxed (strict outer time limit)
  • Timeboxes shown are for a 2 week Sprint

Sprint Planning

Product Backlog Refinement

  • The activity of getting the Prodcut Backlog ready for upcoming Sprints
  • Activities include: Clarifying, splitting, adding, deleting, and estimating Product Backlog Items
  • Representation from the Three Amigos: Business, Programmers, Testers
  • About 90% of the time spent on about next two upcoming Sprints of work; remaining 10% on rest of the backlog

Daily Scrum

  • 15 minutes every day
  • A planning activity for each person on the team to share:
    1. What did I accomplish yesterday?
    2. What will I accomplish today?
    3. What is slowing me down?
  • All Team members must attend, SM & PO should attend, others may attend and only listen
  • The meeting is for the team, not for management and not for status

What to Watch for at Daily Scrum

Watch for Better behavior
Only speaking to the ScrumMaster Speak to the Team
Arrive late Show up on time; respect the team and their time
Rambling Focus on 3 questions and committments you will make
Getting off topic Respect the team’s time
Trying to solve a problem “Take it offline”
Team is being directed Let the team self organize
Not talking about work on the board Point to item on board

Sprint Review (The “Demo”)

  • Attendees include the Scrum Team and key stakeholders invited by the Product Owner
  • The work that has been completed is demonstrated (by PO, Team, or others)
  • Feedback received may cause Product Backlog to change (reordered/new/deleted/changed items)
  • Avoid PowerPoint demos - show working product

Sprint Retrospective

“Here comes Edward Bear now, down the stairs behind Christopher Robin. Bump! Bump! Bump! on the back of his head. It is, as far as he knows, the only way of coming down stairs. He is sure that there must be a better way, if only he could stop bumping for a moment to think of it.”


From A. A. Milne, Winnie the Pooh, 1926

Sprint Retrospective

  • Improvement of how the team works is the main topic
  • All team members must attend
  • Facilitated by the ScrumMaster
  • Problems are prioritized and team discusses solutions
  • Don’t look to fix everything at once – build your experience
    • Keep a backlog of impediments and improvements

Sprint Retrospective Framework

  • Set the stage
  • Gather data
  • Analyze data and generate insights
  • Decide what to do
  • Conclude
Westboro Systems Creative Commons License
Agile Training by Glenn Waters is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.