On-track or Off-Track? Part II

One might ask the following:

“Why bother checking? We “know” that we are on track already!”

“Can we just keep working and deliver the work when we are done?”

“Can we just tell you what tasks we did and have completed?”

“May we provide you a PowerPoint deck, screenshots, metric, list of lessons learned from our Spikes, some documentation and toll gate decks?”

Good questions! Think about those questions for a few minutes.

The thing is, a few errors accumulated everyday/ every sprint/iteration… unchecked… for a whole program increment (PI) spells disaster.

Does it make sense to show the incremental value that you have created and to be retrospective about it?  Would you like to see where the errors/problems/opportunities and go work on those sooner rather than later? Does it make sense to learn fast?

Every demo is a learning opportunity for everyone. Would you like everyone to grow and develop? Learn from your experiences…from your success and failures?

Does your  team do Sprint Review every end of each Sprint?

“Of course!” you might say.

However, do you have a working software to demo? Note: a demo using a screenshot, MS Word or PowerPoint is not a demo of a working software! Are you just going through the motions of a Sprint Review — i.e.  going through the demo just for the sake of going through one of Scrum’s ceremonies/events — and not getting from it?

Don’t just get through the demo; instead, get from the demo!

Sprint Review is not just presenting, showing, watching the demo. You have to take in all the experiences: 1) observe (inspect) the demo and listen to the team’s journey towards it (they will tell their challenges, impediments and victories); 2) look for progress (OKR — Objectives and Key Results) — does the demo move the dial towards the achievement of the PI objectives (i.e. the sprint/iteration demo embodies the Key Result(s) — the stepping stone (s)  — towards the achievement of the PI Objective(s); 3) have a conversation, provide feedback and recognize teammates; 4) adapt — does the backlog need to be updated based on Sprint Review?

Lets go tactical:

1. stage the demo with your team — your product owner cannot do this alone
2. gather the stakeholders (impacted/vested people) for the demo
3. tell them about the demo —  it is about the goal and the tangible outcome (the working software) of this iteration
4. show them the demo — product owner to do the show and tell ( demo and the journey — i.e. the challenges/impediments/victories that they have encountered, etc).
5. retrospect on the demo and the team’s experiences/journey towards the achievement of the goal. Few things to keep in mind — a good structure to follow:
   1. Look at what has been achieved (embodied by the demo) in this sprint/iteration. Observe and learn…keeping in mind the overall Program Objective (this is your ‘North Star’).
   2. Look for Key Results — the actual achievement vis-à-vis the set sprint/iteration goal(s): Did this demo move the dial towards the achievement of the overall PI Objective? Is it measurable and verifiable? Are you moving towards the right direction — the ‘North Star’?
   3. Have Conversations — authentic and rich conversations — do not hold punches! — aimed at driving performance
   4. Everyone to provide Feedback — with positive intent! This is to evaluate progress  and future improvement
   5. Recognize your teammates — express appreciation to individuals for their contribution of all sizes!
6. review your progress vis-à-vis your backlog and objectives. Are you on track or off track?
7. adapt your backlog as needed

Remember: do not show the tasks that you have completed. Instead, show the [incremental] value — which is embodied by the demo — that you have achieved. Show the working increment of the software!

• The thing is this: we get paid by bringing value to the marketplace; the simplest way to understand economics; also called reality.
• Paradigm Shift: therefore, think NOT in terms of tasks, BUT think in terms of value. By the way, this is one of the most difficult paradigm shifts taken by a person coming from a Waterfall methodology – they were trained in thinking in terms of WBS (Work Breakdown Structure) of tasks… now they need to think in terms of values… substitute WBS of tasks with a roadmap of values.
• Small is beautiful: think in terms of value delivered one slice at a time. Use incremental and iterative value creation and delivery approach, in small (pint / point) sizes!
• Releasability: think in terms of value that is eventually realized/released, on demand, to the marketplace. The Business Value is your “fruit” of your labor. The Business Value is the “fruit” of the Fig Tree. Don’t focus on the “leaves” (tasks)… instead, focus on the “fruits”.

On-Track or Off Track? You’ve got to check. Sprint Review, on cadence, is key.

October 15, 2022: My new book, “SAFe Is Like …“, is now available on Amazon. 

What our students think about the Lean Agile Guru (“Author of SAFe is Like …“) — click here

You will get a FREE SIGNED COPY if/when you register, pay, and complete a class by the Lean Agile Guru.