Paper Planes Game

24 September 2015

paperplanes-header

A scrum retrospective game for one team.

Preparation

Rules

Playing it

Start the game. Depending on the level of the team they might ask for better requirements soon.
Give the nice printout. When the team gets stuck in detailed discussions emphasize that the goal is a flying plane, not a plan.

Good For ...

The game is fun and short. The focus can be on several different topics

Example

A team of 4 freelancers.
During the game the team is mostly talking about what they need in their assigned role.
The tester is not doing anything for 8 / 10 minutes.
After 5 min someone asked for better instructions.
The Scrum Master hands out the printout and emphasizes the build plane goal.
Now the team starts building planes.
Result 3 planes. 2 from printouts.

Findings after the game
* without the titles we would have build 20 planes
* testing is actually fun if you're involved early

Source at openCage.github.io

Eventual Efficiency

13 May 2014

ice

Efficiency is what managers want. For some strange reason they look at Scrum to speed up their teams. The even stranger thing is that this is a good idea.
They get efficiency just not right away.

Scrum is actually not designed for efficiency but for quality.
There is nothing in Scrum emphasizing efficiency. Quite the contrary, the definition of done, the requirement for constant learning add extra tasks, extra long tasks.

Slower not faster.
That is a hard pill to swallow.

But but but didn't you say eventually efficient? Yes listen. After a slow start, your team is now routinely following Scrum and Agile principles.
They want more and more frequently input from the PO and customer.
They speak the language of the product not just about its technical but also its business aspects.
The PO needs less and less time to explain the stories, because the team understands the product much better.
The PO needs less and less time testing the stories because the team understands his wishes better and better.
The team members setup a Continuous Delivery Pipeline and learned to develop code with lots of small commits without breaking the build.
Merges are frequent but painless.
Continuous refactorings and code quality initiatives reduced the technical debt.
All team members are familiar with the code base and architecture.
New features are easier to integrate.
The team members are all T-shaped workers and can handle every task you throw at them, independent of who's on vacation.
You have no QA department anymore. They didn't find anything in the sprint results by bringing their knowhow to the team.
Every sprint produces a potentially shippable product.
The number of stages from business idea to deployment converge to 1, i.e the team, one sprint.

There is your efficiency.

So how long does this take? Depends were you start and how much freedom the team gets. A year to see the first real effects is not unreasonable.
Perfection only comes if you keep improving over years. But how can I do this within a 6 month customer project ? Well kids that's a story for an other day.

Source at openCage.github.io

It is Not a Sprint

01 February 2014

exhausted

Scrum comes with a set of new carefully chosen terms for roles in Software Development. 'Product Owner', the owner of the product, the budget and the one responisible. Team member, not developer, architect or tester.
The terms are choosen to project a good idea what the role is about, mostly.
Lets look at sprint. If you never bothered to look at a scrum book or took a training you might infer that a sprint is short and fast. The people involved spent all their time on resolving one thing fully concentrating to complete it. So far so good. But it can also suggest that the involved go to an all out effort to finish the task they set out to do. A sprinter wants to be first in this round, because there is no second. Whether he can walk or talk afterwards is of no relevance, it is over and he's won. Here the analogy breaks. A scrum team always has a next sprint. If you (PO, manager or team member) organize sprints that massive overtime is acceptable you will end up with the follwing scheme: The first days of sprint everybody just hangs around, than the speed slowly picks up until evetybody is on overtime the last days before the sprint end. The stories tend to be not well understood, because they were discussed either during the time everybody is still exhausted, or everybody is in hypermode and has no time for the next sprint. The tasks tend to be rushed with a suboptimal quality. Technical dept will mount because nobody thinks about tomorrow. Everybody seams to be working so hard but the velocity drops.

If we want to think in sports term we should look at marathon runners. How do you organize a run in \infinity many rounds so that you never fall behind and are always in a good shape . You can still sprint once in a while if it is necessary but without sacrificing the full race/ product / project. Remember a profesional marathon runner can run at a speed that looks like sprinting to an amteur pretty much forever but he does not exhaust himself in the middle of the race.

Source at openCage.github.io


Older posts are available in the archive.