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 (http://en.wikipedia.org/wiki/Kaizen).

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.
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
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.

---

proposed innovations

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

#1 - normali[s|z]ed estimations

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

 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.
   
7. A story is only complete when development and testing activities are completed, and the definition of done (DoD) is met.
8. The tester/reviewer should be a motivation for the developer/contributor to  avoid the last minute submission.

#2 - enforce a TRP sprint

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

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.

#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.

In the context of Ranger solutions each release or potentially shippable increment (PSI) is time-boxed within one TRP sprint (see above), 1-3 development sprints and a HIP 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. See http://sdrv.ms/La0W1P for an exceptional example of a sprint demo video.

#4 - enforce a HIP sprint

Raise quality bar across the board

The last sprint of each potentially shippable increment is a hardening-innovation-planning (HIP) sprint, during which the developers typically sit-on-their-hands. 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 PSI.

#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 one innovation for the next sprint. 

#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 …

… and introduce a new poster / cheat sheet …
 

---

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.