5 December 2011
ralfkruse81
The focus of the 4th lesson was on the product owner side. The preparation and organization of the work on the product is crucial for the success of product development. In small groups the students walked trough the whole process of creating a good vision and preparing & organizing the product backlog.
We started by building a product box to foster the ideas. It brought creativity and fun into this exercise and allowed to establish the foundation for a great vision. Here are some impressions of the product box exercise to build the vision:
From the vision we moved on by highlighting those requirements that represent our product differentiators.
The students then, starting from those requiremetns, created user stories and placed them into the Product Backlog. To structure it we used requirements and Minimal Marketable Features (MMFs). The MMFs are used to build minimal sets of functionality (by grouping together user stories ...
23 November 2011
ralfkruse81
In the second lesson I built awareness among the students that a common goal, good communication and teamwork is crucial for the success of a project. Therefore we played the agile42 Scrum Lego City Game.
We formed three teams, who worked together to build a Scrum Lego City.
In fixed timeboxes and with a clear vision, the teams made 3 sprints in order to build the city. They made a Sprint Planning and an estimation but the first sprint was a disaster. A lot of half done User Stories, there where no real integrated results and a lot of wrong assumptions about what was expected.
Why? Because they only worked together as individuals but not together as a team. Everybody was doing what he thought would be best. No right communication and no common understanding ...
24 October 2011
ralfkruse81
Software is getting more and more complex and a lot of projects fail. The students experienced this problem simple exercise: The marshmallow challenge. The students had to build a tower out of spaghettis, cover-tape, a string and with a marshmallow on top in a fixed timebox of 18 minutes.
Well, the exercise worked out as expected. Three of four teams had no tower at the end. Pretty comparable to real software projects :-)
What happend?:
I gave them a complex environment with fixed circumstances and rules. Instead of trying and failing fast and often, they discussed nearly until the timebox was over or they added the marshmallow in the last second and the tower broke under the weight.
After also some other interactive sessions like the well known ball point game the students got the message and learned:
- Assumptions lead to wrong results - proof them fast and often
- Build your ...
Ralf Kruse
