Category Archives: Scrum

Scaling Agile: Competition and Cultural Debt

Scrum and Agile movement crossed 12 years mark (I count from Agile Manifesto in 2001).
It became an industry standard for software development in one way or another.

What if we look at Scrum as a product?

Product: Scrum (work management framework)
Market: software development organizations.
Vendor: Agile gurus to sell their services (business reason) and improve industry (noble purpose).

Starting from individual teams Scrum eventually gets its way into mid-size and big-size organizations.

Competitive landscape: fight for transferring Enterprise customers to Agile

Continue reading

Internal Scrum Training – Wave-06

We have finished our 6th wave of Internal Scrum Training – the last Internal Scrum Training this year 😉

As usually, we introduced few changes: run extra simulation on retrospective (Non-musical chairs), run Scrum Standup Sabotage game and soften constraints on Scrum Lego Game.

I must admit: it went differently and … we all had lots of fun! 🙂

Photos and videos are below.

Continue reading

Scrum Lego Game – Experiments


In recent post I shared our observations while running Scrum Lego Game as part of internal scrum training.

During next “wave” (each group of students receiving the training called ‘wave’ with corresponding number) of internal scrum training, we decided to improve the game by adding few changes.


These changes includes:

  • chance cards (regular and trump card, regular card applies to team who draw the card, but trump card applies to all teams in the game :-))
  • release burndown chart — business owner wants to know if teams are able to deliver entire Lego city (see how remaining work decreasing from sprint to sprint)
  • value burnup chart — how much value produced each team in each iteration


Originally chance cards were designed to introduce certain uncertainty of real world to the game. Certain ‘management decisions‘ explained on a chance card (e.g. 50% of team should use only right hand, while other 50% should use only left hand) supposed to lead to velocity degradation, BUT reality surprised us! Continue reading

Scrum, but…

Recently we talked on our Scrum Master Community (SMC) about “ScrumBut”.

Quick intro

This is a pattern when people deciding to change Scrum, than address issues visualized by Scrum. Of course, it is much easier to change process by introducing workaround than discover root cause of problem and change system to fix problem and prevent it from reappearing.
But doing this we compromise our ability for further continuous improvements. Eventually such improvements become shallow and “the tunnel gets darker and darker”…

This is how Ken Schwaber explained ScrumBut:

Continue reading