353xy SCRUM + scalled

stefan January 31, 2020 0 Comments

The framework (NOT a methodology, process, technique) that gets you from
SCRUM to “Done” (DoD = Definition of Done = usable for end-users = potentially shippable = potentially releasable [but release when it make sense])
using rules of Empiricism (Transparency, Inspection, Adaptation).
It can be used to develop new products or maintain/sustain existing ones in various industries.

ST = Scrum Team  – self organising, cross-functional (The ST model is designed to optimise flexibility, creativity, and productivity.)

SS = Scrum Sprint – what they do [1-4w]. The heart of Scrum, a time-box of one month or less during which a “Done”, useable, and potentially releasable product Increment is created. A new Sprint starts immediately after the conclusion of the previous Sprint.
The Sprint is over when the timeboxed duration is over or the PO cancels it.

SG = Sprint Goal    – the functionality forecast by DT obtained by completing the PBIs from SB. When the SG becomes obsolete the Sprint can be cancelled by the PO. A good Sprint Goal has three characteristics: focus, flexibility, and purpose.

3 Roles¹

  1. PO = Product Owner          []
    1. manages PBI = Product Backlog Items
    2. orders PBI by
      1. value
      2. priority
      3. dependencies
      4. risk
    3. measure the performance of the project
  2. DT = Development Team [3-9members]
    1. working at a constant pace daily
    2. make additions and changes to the DoD
    3. resolve internal team conflicts
  3. SM = Scrum Master           [focused on the context, not content]
    1. servant of others in their job by
      1. learn
      2. convince
      3. change
    2. helps the organization implement SCRUM

The Development Team is accountable for creating releasable Increments.
The Product Owner         is accountable for maximizing the value of the work.
The Scrum Master           is accountable for the understanding and application of Scrum

5 Events¹

  1. SP = Sprint Planning²          [1-8h]          – answers to 2 questions:
    1. What can be delivered in the PI resulting from upcoming SS.
    2. How will the work needed to deliver the PI be achieved? Forecast progress
      1. burn-down
      2. burn-ups
      3. cumulative flows
  2. DS  = Daily Scrum                [always 15min] – DT talks, anyone can watch; not a status meeting
    1. Done?                 = What did you do yesterday?
    2. Planned?           = What will you do today?
    3. Impediments? = Is there any impediment?
  3. DW = Development Work   [at constant pace]
  4. SW  = Sprint Review             [1-4h] allows outsiders
  5. SR   = Sprint Retrospective³ [¾-3h] using 3I (inspect, identify, improve) for
    1. People
    2. Relationships
    3. Processes
    4. To

¹All but DW are “formal opportunities for inspecting and adapting”, and are considered “feedback loops”. Note that “formal opportunity” means “serious opportunity” or “important opportunity”. There not “formal meeting”, which means a meeting where people approve something and exchange signatures.

²When the PB has complicate to forecast items, and the SP it’s blocked. It‘s fine! Just pick a number of items. If it’s not enough, you can pick more later. If it’s too many, you will just deliver as many as you can. Nothing bad happens if you don’t deliver all items in the Sprint Backlog. The goal is to generate value, not to develop all items in the backlog.

³While we talk about the way we refine PB, we do not refine it here, but all the time. We discuss about the composition of the team. About the way work was done and finding ways to improve it next time; this is mainly about lessons learned.

3 Artifacts

  1. PB¹ = Product Backlog which lists PBIs (If PBI is what, the task is how). PBIs have Description, Order, Estimate, Value and refers to:
    1. Features
    2. Functions
    3. Requirements
    4. Enhancements
    5. Fixes
  2. SB² = Sprint Backlog is owned by the DT, contains tasks, what can be done and how to do it
  3. PI³ = Product Increment

¹PBR = PB Refinement is done ONGOING (<10% of DT time) by the ST. PB is never complete. It’s always evolving in adaptive methods.

²At least one high-priority process improvement item exists in each SB. There are two elements in the Sprint Backlog: items selected from the Product Backlog and tasks created by decomposing those items.
Tasks are always changing, and therefore, we can’t say that Sprint Backlog doesn’t change during the Sprint.
The old-fashioned approach is to keep the items fixed, to avoid distractions, but Scrum.org doesn’t believe in that anymore, so it’s fine for them to change the items too.
Only a few tasks are defined in the Sprint Planning meeting and the rest will be created during the Sprint.

³PI is done by integrating daily DW with the rest of the code, multiple times a day = continuous integration in Agile.

x Useful concepts but not required/ mandatory

  1. SCRUM values:
    1. Courage
    2. Focus
    3. Commitment
    4. Respect
    5. Openness
  2. Velocity is a complementary practice that provides an indication of the average amount of Product Backlog turned into a “Done” Increment during a Sprint by a Development Team. It is tracked by the Development Team for use within the Scrum Team. When historical data is gathered over time, a Scrum Team gains an understanding of the rate at which work has been completed and then can use this knowledge to forecast future work (i.e., to select PBIs for the Sprint Backlog).
    Focus on velocity inhibits agility
    Velocity is not:

    1. A performance measure of the Development Team
    2. A promise of what will be delivered in the future
    3. A way to compare Scrum Teams or Development Teams
    4. A way to compare individuals on a Development Team
    5. An indication of “how hard” a Development Team is working
  3. Budgeting which is done every sprint to ensure value is being delivered.
  4. Refactoring is the activity of changing the inner design without changing the outer behavior of the system.
  5. A User Story is a placeholder for a conversation about a User need, which is about outer behaviour.
  6. PMO = Project Management Office – Manages portfolios and programs and facilitates the application of techniques that complement Scrum.
  7. burn down chart shows how much work is remaining to be done in the project, whereas
  8. A burn up chart shows how much work has been completed, and the total amount of work.
  9. WIP = Work in Progress limit of 2 for the “In Progress” column of its Scrum Board
  10. Kanban (n) – a strategy for optimizing the flow of stakeholder value through a process that uses a visual, work-in-progress limited pull system.
  11. TDD = Test-Driven Development, in which automated unit tests are created before the code is written to drive the design of the software and force decoupling of dependencies.
  12. CD = Continuous Delivery
  13. DevOps = DevOps breaks down barriers between operations and development in pursuit of increased agility.

y Anti-patterns and Dysfunctions. Unacceptable concepts but still out there

  1. DoR = Definition of “Ready”¹ – PBR ought to de-risk SP. Enough refinement will therefore have been done when a team can plan it into their Sprint Backlog as part of their achievable forecast of work. The acid test of that condition can be brutally simple. If work has been refined to the point that a team can estimate it, and it is thought small enough to be planned into a Sprint without being broken down further, then that might well be enough. It is “Ready”.
  2. WBS and Gantt Chart are mainly used in planning predictive (plan-based) projects rather than adaptive (Agile) ones.
  3. Sprint 0: The term Sprint 0 is often applied to project setup and initiation, during which the release of any value is deferred. As such it is not a sprint at all.
  4. Hardening Sprint: If a team’s definition of done is inadequate, or is not being met, technical debt can be expected to accumulate. A so-called Hardening Sprint is an attempt to pay off this debt rather than improve the team’s process and thereby stop debt arising.
  5. Release Sprint: Each sprint must result in a potentially releasable increment, regardless of the number of teams and deliverables involved in a release, so batch sizes of undelivered work can be minimized and controlled. A so-called Release Sprint would therefore be a contra-indication to agile practice.
  6. Release Retrospective: A similar antipattern, since each sprint must yield an increment that is potentially releasable. The outcome of any release should be inspected in the ensuing Sprint Retrospective.
  7. Undone Scrum
  8. Mechanical (or Zombie) Scrum
  9. Dogmatic Scrum
  10. One-Size-Fits-All Scrum
  11. Water-Scrum-Fall
  12. Good Enough Scrum
  13. Snowflake Scrum
  14. Nothing should be baselined in SCRUM

¹Example of DoR

These considerations are often summarized as the “INVEST criteria”, and they provide us with a useful Definition of Ready which can be applied to Product Backlog Items. By actively participating in Product Backlog refinement, a good Development Team will collaborate with the Product Owner in making sure that a standard such as this is observed.

Independent. The PBI should be self-contained and it should be possible to bring it into progress without a dependency upon another PBI or an external resource.
Negotiable. A good PBI should leave room for discussion regarding its optimal implementation.
Valuable. The value a PBI delivers to stakeholders should be clear.
Estimable. A PBI must have a size relative to other PBIs.
Small. PBIs should be small enough to estimate with reasonable accuracy and to plan into a time-box such as a Sprint.
Testable. Each PBI should have clear acceptance criteria which allow its satisfaction to be tested.

Scalled SCRUM

When there are n teams in a project, there are:
1 Product Backlog
n Sprint Backlogs each Sprint
one or more Definitions of Done, as long as they are compatible with each other
1 integrated Increment each Sprint
1 Product Owner
n Scrum Master roles which can be occupied by 1 or more Scrum Masters

Note 1: one project is about one product.
Note 2: The way Scrum Guide explains it, it sounds like there should be one Definition of Done for scaled Scrum, but Scrum.org believes that there can be multiple definitions, as long as they are compatible with each other and capable of creating integrated Increments, and that’s what you have to answer in your exam.

Leave a Reply

Your email address will not be published.