User Stories to Play POCHallenge "agile"
I presented @POChallenge at the Tools4AgileTeams #t4at14 conference, Wiesbaden, Germany, 6. Nov.2014, 14:45 with new moves: epics, user stories feat. agile mindset. Now you can compare Waterfall with Agile more realistical.
I presented @POChallenge at the Tools4AgileTeams #t4at14 conference, Wiesbaden, Germany, 6. Nov.2014, 14:45 with new moves: epics, user stories feat. agile mindset. Now you can compare Waterfall with Agile more realistical.
Download User Stories ready to play. This user stories are written for LEGO Creator Series 6910 (Sports Car), 31000 (Pick-up truck), and 5761 (Digger, front loader).
The PO can share the product vision/requirements in using high level written user stories instead or in parallel to the LEGO building instructions. However, PO can go back to LEGO instruction (hidden from the team) as often he wants to – "asking the customer". Using the user stories, PO and team plan together with the team the sequence of what is built ("sprint planning").
The PO can share the product vision/requirements in using high level written user stories instead or in parallel to the LEGO building instructions. However, PO can go back to LEGO instruction (hidden from the team) as often he wants to – "asking the customer". Using the user stories, PO and team plan together with the team the sequence of what is built ("sprint planning").
"Agile" or "Waterfall" is not the essential Success Factor
At Tools4AgileTeams we played POChallenge with four groups: 3 groups played with the new agile flavour: epics, user stories, and acceptance criteria; and 1 group playing the waterfall style.
The building time was time-boxed to 45min for each group.
The building time was time-boxed to 45min for each group.
The experiences of this session were quite extraordinary:
- There was no significant difference in running the project in an "agile-ish" or "waterfall-ish" way -- both methodologies shows quite equal results, even in quality (correspondence to customer vision) and performance (time to finish).
- Continous customer interaction is the crucial success factor, or root cause of failure.
I started the game with the facilitation: "For each backstepping to the LEGO building instruction (customer) the PO will get a penalty". – The results: all PO's spent all their time as much as possible with their teams, and tried to minimise their "customer visits" as much as possible - in Agile Team 2 the PO never "asked his customer".
Summary / Debriefing:
- Both product owners confessed, to be frightened right from the beginning, to interact with the customer (LEGO building description) very often due to the rule "For each backstepping to the LEGO building instruction (customer) the PO will get a penalty".
- "For each backstepping to the LEGO building instruction the PO will get a penaVery soon after project start DevTeam Agile 1 felt to sacrify their agile mindset/values, and to be micro-managed by their agile(!) PO.
- To correct failures identified by their own, Agile Team 3 disassemble their model built completly from scratch 3(!) times .
- After getting back on the agile track again, Agile Team 1 started to "polish" their product – even the PO had accepted the product with its (minimal) deficienies. – The team continued to work without having any customer / PO order!
- At project start the PO in the waterfall team was very assure to have understood the "customer vision" well; but very soon, he recognised, to run out of track, and to develope a product being far aside from what the customer would expect.
Because of his own rule "to minimise penalties", he still contiuned working without customer feedback; however he had a sad feeling. Only in the last possible moment, he got "back to the customer", and started to correct the
mistakes made in the project. However, a long time, the project worked in the wrong direction.
Nevertheless, the waterfall team finished almost in equal time as the best agile team.
Team Agile 1 | Team Agile 2 | Team Agile 3 | Team Waterfall | |
---|---|---|---|---|
Overall "project time": | | | | |
PO visits at "customer": | | | | |
The experiences of this gaming session bears the observation, that the success of an IT project is more related to the fact, that the "team is in the driving seat" – i.e., pulls all information and artefacts needed – than whether the team follows the agile or waterfall philosophy.
Nevertheless, the mindset and the strong customer integration which Agiles propagates, suppports the "pulling" habit of teams better than the waterfall approach. Agile teams set themselves sooner in the driving seat.
Nevertheless, the mindset and the strong customer integration which Agiles propagates, suppports the "pulling" habit of teams better than the waterfall approach. Agile teams set themselves sooner in the driving seat.
Photo courtesy: I do thank Tobias Cieplik, zero2nine photography, for taking pictures of my workshop session.