ALM Rangers Ruck – Proposed innovations to the v1.2 guidance. Thoughts?

We introduced the concept of “loose Scrum” (also known as a maul or ruck in Rugby) in 2011 to streamline the ALM Rangers projects and continuously adjust and improve to maximise respect for people, optimise development flow and embrace the philosophy of kaizen (https://en.wikipedia.org/wiki/Kaizen).

Revised 2014-02-11.

remembering our constraints

Before we cover our observations and proposed innovations it is important that you peruse ALM Guidance: Visual Studio ALM Rangers — Reflections on Virtual Teams and Things you probably [did not] know about the Visual Studio ALM Rangers to understand our world, challenges and constraints. One of the self-inflicted (intentional) constraints is our 24x7 dog-fooding of VS Online and using features out-of-the-box.

We are in the process of wrapping up our last in-flight projects and preparing new teams to take-off on new adventures. As part of kaizen we have made observations and are discussing possible innovations herein.


so, where’s the fire … what are my observations?

OBSERVATION IMPACT  
Teams have agreed on very ambitious estimations, often adding 8h and even 40h tasks to their sprint backlog. Failure to deliver working solutions at the end of sprints and a trend to “carry over” work to next sprint. image
Teams often fail to invest the time to plan each sprint or perform micro-task planning. Inaccurate planning, inconsistent sprint velocities and overhead in terms of task management during the sprint.  
Teams are seldom doing sprint retrospective, or giving candid feedback. Retros are seen as a process overhead, rather than opportunity to improve the team environment.  
Teams often start with an objective to complete in 2-3 months, but continue from sprint to sprint until work is eventually completed. The team has no milestones to work towards and no horizon in sight. Projects turn into an on-going rut Sad smile  
Teams often start energetic, then deflate and awaken towards the end for the usual death march to meet expectations, or Rangers simply wait for the last possible moment to deliver. Frustrations amongst team members, especially where there are dependencies, and a frequent cancellation of features. Also a spike (burn up) during a sprint as unknown dependencies are identified “late” as shown. image

 


proposed innovations

Many of the proposed innovations are based on learning's from Scaled Agile Framework® (SAFe™), which is an approach we are investigating as part of our Agile and Ruck environments.

 

Light bulb #1 - normali[s|z]ed estimations

Simplify estimation effort, improve estimation accuracy and ensure estimates are done and supported by team.

image See How do you normalise your velocity estimation for more information.

  1. Estimate assuming full-time availability of resources.
  2. Team estimates stories using story points based on developer/contributor and a tester/reviewer pair per story.
  3. Team finds smallest story that can be developed and validated in full day, relating it to one story point.
  4. Team estimates the remaining tasks, using the 1 story point task as a reference.
  5. Split up big stories into smaller stories that are equal or less to the part-time sprint maximum.
  6. Visually indicate when a story/task is ready for testing/review. For example, the snippet shows a feature #9462, with a story #9463 that has been developed and tagged as ready for testing.
    image
  7. A story is only complete when development and testing activities are completed, and the definition of done (DoD) is met.
    2014-02-11 …dev + test is not a waterfall sequence. Unit tests and test cases can be created before or in parallel to development efforts.
  8. The tester/reviewer should be a motivation for the developer/contributor to  avoid the last minute submission.

Clarification from discussions:

  • We will use the poll feature in Lync as a bare minimum or online planning poker solutions. Requirement is that at least 50% of the team is present and that the PO does no estimating.
    image … 1,2,3,5,8,13,21
  • Story points have no direct correlation with time (hours) and usually we calculate:
    ~days = days per iteration * (backlog size / velocity)
    However, as
    we have not been able to define an average velocity for Rangers, I propose we use the hybrid story point approach and associate our story point to a day, for example, which of these piles can I develop and test in a day? That’s 1SP and that defines the base of the estimations.
  • A story with a SP of 1, 2, 3, 5, 8 or more could be do’able in a day as well. It is all relative and based on the smallest pile of stuff the team identified as a SP=1.

Light bulb #2 - enforce a TRP sprint

Introduce pro-active sprint planning, reduce ambiguity and task management.

image

Each new project or subsequent release starts with a training-research-planning (TRP) sprint to gather the following objectives:

  • Motivation which outlines why we are considering the project
  • Vision which describes the objectives of the project
  • Smart objectives (specific, measurable, achievable, realistic and time-based)
  • Acceptance criteria which define what it take for the product owner(PO) to signoff the project
  • Definition of Done for the TRP sprint

The TRP sprints starts with a kick-off meeting, followed by research, training and finally a sprint planning meeting that plans the first construction sprint with a high-level of confidence and subsequent sprints with best-case estimates.

Light bulb #3 - enforce PSI time box

Ensure that the team has a realistic horizon in sight. Do less, better and ship what we have on demand.

image

In the context of Ranger solutions each release is time-boxed within one TRP sprint (see above), 1-3 development sprints and a QP sprint (see below). Each project team is divided into one or two feature teams, each with its own sprint plan, but all sharing the same cadence and project vision, objectives and acceptance criteria.

Each feature team commits time at the end of the sprint to do a sprint retrospective and plan the next sprint. In addition each team delivers a 1-3min video which summarises the sprint deliverable and can be used as reference for new team members or stakeholders. This becomes invaluable evidence for the Ruck-of-Rucks! See https://sdrv.ms/La0W1P for an exceptional example of a sprint demo video.

Clarification from discussions:

  • The idea is that we make it easy for a team to deliver evidence on their working solution and allow them to do some well-deserved PR.
  • Essentially I see the following standard story for each sprint:
    Standard: As a stakeholder I can view a sprint demo video so that that I can get a quick overview of deliverables  

Light bulb #4 - enforce a QP sprint

Raise quality bar across the board

image

Scaled Agile Framework® (SAFe™) introduced a hardening-innovation-planning (HIP) sprint at the end of a potentially shippable increment (PSI).

We will us the opportunity to raise the overall quality bar and plan during this last sprint. The team focuses on eliminating any remaining debt, such as copy-editing, and validates that all quality bars have been met and encourages the product owner (PO) to signoff. In addition the team uses the time to experiment with innovations for future releases and if needed, to plan the next release.

Light bulb #5 - agree on one innovation

Minimise waste of time due to meetings and encourage continuous improvement.

Instead of meeting to discuss what went well, what went not so well and how we can improve, we agree on at least one innovation for the next sprint.  This becomes invaluable evidence for the Ruck-of-Rucks!

Clarification from discussions:

  • The idea is that we continue to discuss and agree on what went well and badly if possible, but that each team must deliver one innovation for the next sprint.
  • Essentially I see the following standard story for each sprint:
    Standard: As a team we can define one innovation for the next sprint so that we can improve our project continuously  

Light bulb #6 - revise ruck chart

Create consistent project plan and align with visualization such as the Scaled Agile Framework .

Retire our v1.2 Ruck Cheat Sheet …
image

… and introduce a new poster / cheat sheet …
Ruck Cheatsheet 


we need your thoughts and consensus

We need your thoughts and candid feedback, so that we can make decisions by consensus and start the dog-fooding of innovations with our next project adventures.

Add your comments below or contact us by email.