The agile bird !

Its always a great experience to share knowledge with others. Today we had a mini workshop for some of the colleagues of Informatics and few of our new Exilesoft colleagues together to learn agile.

Total time box – 2 hours for the training. (4PM to 6 PM) In that, I had to spend first one hour to take them though the agile concepts and introduction to Scrum. I tried to cover up some of the practical issues too such as planning a huge backlog, vertical designing or so which they are already into.

So we were left with 1 more hour, which I wanted them to go through an exercise to learn and feel agile concepts better by themselves.

So, yesterday night I prepared this small backlog for them…

As a	I need	So that	Weight	Priority
Marketing Manager	a bird with 2 wings	I can sell the toy to kids
VP Marketing	The bird to carry the logo	We can brand it as our own toy
Sales person	The bird to have red color feathers	It will be more appealing to young girls
Marketing manager	The bird to have blue eyes	The bird will be more appealing to the kids
Production manager	The documentation on how to make the bird	I can train more people to produce birds like this
Marketing manager	The bird to have 2 legs	The bird will be able to stand
Marketing manager	The bird to be bundled with a cage	We can add more value in the market
Brand manager	A catchy name to the bird	The bird will be popular among the kids
Angry kid	Soak the bird in water	The bird will be destroyed easily

The product vision: to produce a toy bird to the market, this can compete with other toy birds in the market.

Product backlog

You may notice few points in the product backlog user stories. There are some functional requirements which is a must to deliver and some nice to have features too. With the angry child user story, I wanted them to get the idea of having user stories from hacker’s perspective to come up with security related user stories too to the product backlog. Documentation user story was brought in to the picture, so that team will understand if the documentation is needed by stakeholders to treat it as a user story and deliver it.

We had 8 members, so we split the team to two. My colleagues Shamira Dias and Manujaya Kuruppu volunteered to play the product owner role for the 2 teams. Thanks to them they did a great job of taking teams through the product backlog and helping them to learn estimation techniques.

Shamira and Manujaya prioritized the stories to their teams after having a discussion with them. They prioritized the highest market value items first. Both the teams played planning poker to estimate the user stories with their product owners which helped them to get the real idea about relative estimation using story points.

After that.. They decided 2 releases for the backlog. First release within 15 min and other release within 20 min. which is the final release of the bird. Product owners mentioned to their teams what they need for the release one.

Here they are busy making this bird… Team A

Team B - Making the bird


When they did the final release, Navin came as the customer and he had to make a hard decision about buying one bird. He bought Duckybird J because it could fly perfectly and he was fascinated about his flying skills.

Here is the Mountain bird by team B at the final release :-)

Here is the Ducky bird by team A at the final release :-)

After that we did a retrospective with the teams...( we had no time to do a retro after the release 1 which could have been the perfect scenario.)

The findings

• 1. In release 1, team A failed to do the product release on time even with minimal required features. So they saw how their competition came to the market.
• 2. Team B prioritized the red feather story for the release 1 , so they had no time to deliver a stable product which is a bird who could stand.
• 3. Team B delivered extra (Gold plating??)_ nice decoration on bird which was not included as a user story in the backlog and they totally forgot about the flying feature of the bird which made them to loose their opportunity in the market against the competition
• 4. Team B – the whole team spent time on doing documentation and didn’t deliver the cage and the fence. – there scrum master was too involved in building and forgot to get his team guided towards signing in to various tasks to improve the utilization of time. which can happen in real development projects.
• 5. Testers of both teams didn’t add much value to the team from testing perspective.
• 6. They learn the difference of a scrum master from the Project Manager
• 7. They learned how the team culture works in agile organizations.

Rewards

After that , I rewarded the scrum master of team A as his product owner managed to make a sale based on what his team produced.. The team accepted that they didn’t feel very happy about it as they felt he was rewarded at their cost and instead the management could have rewarded the whole team because the whole team worked hard to release a nice toy bird to the market.

Thanks to all who participated the training.. it was a great experience to share knowledge with a team from another company. I'm sure my colleagues also enjoyed it a lot.

Update: you can see the PB user story about flying is missing.. This is how the PB was at the initial stage.. which I wanted the teams to learn that PB is not perfect at once.. there are so many hidden things which will come out when PO refines it again and when the team ask the question. Team knows that many birds fly and this is a question I expected them to ask with their domain knowledge. Thank you @michelesliger for notifying this to me. This is an addition I did when posting it.