Dead Zone Streamline requirements flow in distributed projects by Sergey Prokhorenko @ Agile Pizza

Presentation
  • Whoami
    • http://ua.linkedin.com/in/sergeyprokhorenko
    • Head of head of Agile Practice at Luxsoft
      • Since 2005
      • 15+ customers
      • 50+ ongoing projects
      • 700+ Agile practitioners
      • 100+ Certified Scrum Masters
      • 15+ internal Agile Coaches
  • Agile as a silver bullet
    • Agile Providers vs Client problem
      • Business value driven prioritization to deal with Always late with the things we really need
      • Pay for DONE to deal with Paying for the wrong things
      • Change without penalty to deal with Too expensive to make even little changes
      • Client is in full control of the project to deal with Difficult to understand where we are right now
    • Actual use of requested features
      • Always 7%
      • Often 13%
      • Sometimes 16%
      • Rarely 19%
      • Never 45%
      • Source: The CHAOS Manifesto, The Standish Group, 2011
    • Simple rules
      • RUP Referece and certification guide - 289 pages
      • SCRUM Guide - 16 pages
      • presentation slide 4
    • Scrum is a game of chess - simple rules - but endless combinations
    • idealized role of PO in a company
      • Responsible for maximizing the value of the product and the work of the Development Team
      • Sole person responsible for managing the Product Backlog
        • Power
        • Expertise
        • Dedication
      • Does Sprint Planning and PBR with the Development Team
      • Tracks total work remaining at least every Sprint Review
    • Real life PO example - a team of PO
      • presentation slide 7
      • End users / stakeholders - Product vision team - prototypes - PO - pPOs for teams.
      • several PO - customer side PO, user side PO, intermediate pPO.
      • customers are on the "other side"
      • there are different time zones - 8hrs turnaround to get a solution
      • product owner is involved either in business, or in PO activities.
    • SCRUM becomes a cargo cult - doing SCRUM for SCRUM sake - no results.
      • things don't happen
    • How did we end like this? presentation slide 10
  • Sprint level visualization
    • SCUM rules - describe moves & technics, but not the strategy.
      • What to do on the higher level to sync teams is left in the "grey", "dead" zone
        • Management
          • Are we on track to deliver scope on time?
          • When release epics will be ready and what is the current status?
          • What are PO (BA, pPO) doing? Do they have blockers?
          • How many stories are ready for the next sprint?
          • Are we ready for the next release planning?
        • Developers
          • What is the goal of the current release?
          • Are we on the track to deliver on time?
          • What are other teams doing?
          • Are there any dependencies on a project level?
          • Does PO and BA have enough requirements? - what would we do, when this sprint ends?
  • What can we do about it?
    • People and interactions!
      • Who is PO?
        • man from business - no time for team - BETTER - can at least explain something.
        • man from IT - no time for business.
      • Clear roles and Responsibilities of dedicated PO on/from customer side
        • Prioritization - only PO can do. If PO can't do - SCRUM wont live on
        • Expertise - we can live with it. At least PO will understand business globally and get priorities.
          • we can get external experts to help with
        • Communication
          • first in a list to save time on.
          • least important - can gather once in a week to work.
    • Processes and tools
      • Use Kanban on high level at Project (program) level (presentation slide 18)
        • Goals / epics
        • Analysis ongoing
        • Ready for Development
        • Next 20 stories to pick
        • InDev
        • Acceptance OnGoing
        • Ready for production
      • High level flow
        • Request from stakeholders
        • Backlog prioritization
        • Backlog refinement
        • Ready for development
        • Sprint
        • Ready for release
      • Value stream mapping
        • Request from business sponsors
        • Program initiation <- involve / add team here!!!
        • Project chartering
        • Epics breakdown
        • User story drafting
        • User story grooming <- if team joins here - you will get waterfall
        • Ready for spring
        • In development
        • Ready for demo
        • Ready for UAT
        • in UAT
        • Ready for release.

        • Backog prioretization
        • +Addons
        • sign off
        • release publishing
    • DoD Agreements (Definitions of Ready) (Analysis phases)
      get more detailed on each phase
      • Do not build a formal contract, but rather visualize as much as possible for sprint.
      • Finishing of ready. (FoR)
      • Program initiation
        • PID is shared with BAs
        • Project charter is drafted and shared with business sponsors and BAs
      • Project chartering
        • Charter is approved by business sponsors
        • Final charter is reviewed with BAs in a meeting
      • Epics breakdown
        • Charter breakdown into epics is approved by PO
        • All epics are described in Confluence with:
          • Business context
          • Problem statement
          • High-level acceptance criteria
        • All epics are presented to the team(s)
        • Epics are included into backlog and prioritized
        • Business contacts identified
      • User story drafting
        • User story is well-analyzed by BA and conform to INVEST criteria
          • https://en.wikipedia.org/wiki/INVEST_%28mnemonic%29
        • Detailed BDD scenarios are created
        • Mockups are created (where applicable)
        • Data requirements specified (if any)
        • Business logic is specified (if any)
        • US reviewed with business SME
        • Acceptance criteria are reviewed by business SME
        • US is prioritized in backlog and priority approved by PO
      • User story grooming
        • Team reviewed and agreed that US conforms to INVEST criteria
        • BDD acceptance scenarios are well understood by team and approved by business
        • All research spikes identified and completed
        • US breakdown is approved by team (and re-approved by business if any changes)
        • Business contacts are shared with the team
        • Design is approved
      • DoD for last analysis phase = DoR for sprint
    • Limit WIP for BAs - not more than one Epic. Only 30% value added as they work on several projects
    • Backlog grooming Ground Rules
      • Regular
        • At lease once a week, scheduled with PO
        • Started upfront (at least a week before planning)
      • Timeboxed
        • 15-20 min per story
        • If timebox isn't enough - go offline and prepare for next session
      • Includes the whole team
        • All team members ask questions upfront
        • Team members (not only PO/pPO) describe story value and scenarios
      • Strict DoD
        • If artifact doesn’t follow agreed DoD it isn’t moved to the next phase
    • Effective collaboration
      • Feature team US - Scrum of Scrums - Feature team UA
      • Scrum of Scrums
      • Cross-functional teams
      • Single backlog with unified estimates
      • Single Product Owner for the whole backlog.
      • Proxy Product Owners for each location #TBD - feedback loop
      • Joint release planning
    • SCRUM of SCRUMs = Big picture of the project
      • Anything depends on everything. SCRUM as a mirror of the processes.
      • also as a feedback to management
      • Inspect and adapt
  • Product vision and goals. Sprint Zero Workshop
    • Who needs it most?
      • Scrum Team
      • Product owner
      • Scrum Master
      • Gathered all together in the same place
    • How long it takes?
      • one - two weeks
    • What do we get from it?
      • Synchronize product vision - get same language
      • Establish long term goals
      • Get Shared understanding of business
      • A common training and common language for the team
    • How do we do it?
      • Synchronize the product vision between the stakeholders (business canvas)
        • why do we need this product?
        • what problem does it solve?
        • who are the users - what are their problems?
        • what this product can do you can't do with other tools?
        • if you automatise something existing- how better the life would be with this product?
        • The goal is to get to a point, where team get a first hands on the product vision
        • Business model canvas as a tool
      • Obtain Goals
        • Create middle-term goals for the close half year. Some examples are:
          • get userbase
          • get to some minimal functionality
          • if it is an internal product - create SMART (measurable) goals (70% of manual activity to automatize)
          • get to understand - how do we measure success/failure
      • Create user personas for story mapping
      • Go for Story mapping.
        • Story mapping is created from the system users (persona's) point of view
        • Create a separate storymap for each user
          • as a user ... (persona from previous step)
          • I would like to do ...
          • so I would achieve ...
        • Use different coloured stickers for different personas - the one who needs the story - gets it
        • We must create complete story
          • either for one user
          • or for single process
      • Storymap becomes first backlog draft
      • Add weight for each story (can use fibonacci numbers as indicative weight) - affinity estimation
        • if some stories are over some measure in points - they are key target for splitting or lower priority
      • Slice user stories
      • Establish DoD (definition of done), Acceptance criteria
        • unit tests
        • introduction
        • testing
      • Set Priorities
      • Formulate Sprint 1 from stories (half sprint or quarter - better as they tend to grow ;)
      • Agree on working agreements (DoD partially, DoR (definition of ready) for requirements, Sprint pulse (timings)
  • Recommended literature
    • Implementing Lean software development
    • Lean from the trenches
    • Scaling lean and agile development
    • Practices for Scaling lean and agile development

No comments:

Post a Comment