Game: Paper folding

Goal

The goal is to fold a paper sheet as instructed by Product Owner (PO) provided other participants just maintain audio communication with each other.

Timing

3 to 5 min

Material

One A4 size paper sheet for each participant

Roles

Product Owner (PO) – He decides how paper need to be folded and pass on instructions to all participants orally only without making any visual contact

Folders – These people fold paper as instructed by PO. These people can communicate with each other and PO but orally only without any visual contact.

Communication

PO and folders can communicates to each other any point of time in the game but orally only and without any visual contact to anyone.

Let’s play

Part 1

• ·         Every folder stands up in circle but looking out ward (not inward)
• ·         PO stands up at the center of circle. He can see only backs of the participants

Part 2 (3 to 5 minutes)

• ·         PO starts folding the paper and passing instructions orally to all participants.
• ·         Participants fold the paper and ask for clarification from PO and also talk among them selves without making any visual contact to anyone.

Part 3 (5 minutes)

• ·         Team discusses the game and list the learning

Learnings

Communication over phone (without visual contact) is not rich

Teamwork fable

I hope you all know the old story about the race between a tortoise and a rabbit.  Rabbit used to boast about his speed and agility. To his surprise, the tortoise challenged him for a race. Rabbit made fun of the tortoise, but agreed for the race. As the race began, the rabbit raced way ahead of the tortoise, just like everyone thought. Somewhere mid-way, the rabbit realized that he is way ahead of the tortoise. He decided to take a short nap. After a while, when rabbit woke up, he realized that he is already late, and the tortoise is almost on the finishing line. The rabbit ran fast as he could but still lost the race. Now it was the turn of the tortoise to boast.

Slow and steady wins

But story is not finished yet. After this win, confidence of the tortoise was high and rabbit was in shambles. When the rabbit came back to his senses he analyzed the cause of his failure. Rabbit again challenged the tortoise for a race. Tortoise was over-confident and readily accepted the challenge. In this race, rabbit did not take any rest and focused on running. Rabbit won the race by a huge margin. Now it was turn of the rabbit for the glory. 

Fast and consistent always beat the slow and steady

Now it was turn of tortoise for introspection. Next day, the tortoise challenged rabbit for yet another race. Rabbit agreed immediately. Again race started. Rabbit was consistent and fast, so he was way ahead of the tortoise. But mid-way there was a river in this race which rabbit was unable to cross. Though tortoise was slow, he still won the race.

Know your core competencies

After all these races, the rabbit and the tortoise became good friends and decided to have one more race. But this race was different. Here they decided to cooperate, and not compete. In the first half rabbit picked up the tortoise and reached to the river banks in no time. Now it was turn for the tortoise to carry rabbit and cross the river. The race set a new record.

Teamwork is better than individual performance

Now it is your choice to pick the lesson.

Large Agile Practitioner Summit (LAPS), 2016

 July 20th 2016, at SAP Campus at Palo Alto, CA Jeff Sutherland hosted Large Agile Practitioner Summit.  This even uses Open space format which was refreshing and truly engaging. I also hosted a session on “Architecture and Design in Agile”.  The discussion was superb not only around my topic but also other fifteen topics.

Interaction with Jeff is memorable. We discussed on quite a few topics of Agile - why Agile works, Agile in non-software world, career path for Scrum Masters, etc.

Looking forward for more interaction with Jeff and fellow Agilists.

Here is the gallery of topics

Interaction at CapitalVia

Recently while visiting Indore, India I got a chance to interact with IT team of CapitalVia. The experience was awesome. I was amazed with the enthusiasm of team and management in moving towards Agile way of working.

CapitalVia is a financial market research and consulting company which provides trading recommendations in equities, commodities & forex based on technical research. It is located in Indore, India. It has in house IT team of 30 dedicated, enthusiastic and collocated technical and business savvy people.

CapitalVia has organized its IT team into following roles

•  Product Owner ( although CampitalVia call them Business Analysts) – Three in number
• Technical Lead – Three in number
•  Developer – Twenty in number
•  QA – Three in number
•  Program Manager ( CapitalVia  defines as General Manager) – One in number

 

     CapitalVia is mostly PHP shop and customers for IT team are internal to organization which is focused more on functionality, ease of use, and adaptability of applications. IT team manages existing systems as well as develops new ones as requirements arise. There is no separate maintenance team; one who develops the application becomes responsible for its maintenance which encourages maintainability and bug free applications.

     

     After interaction with them I got privilege to recommend ScrumBan as basic operating model to start with. I hope team will experiment with recommendations.

The Agile Manifesto in English - 17

Principles

Agile principles are concretization of agile values.  Agile manifesto lists 12 principles. These principles are iterated in the form of assertive statements.

12.     At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Do I know everything? Do you know everything? I am sure answer is NO. Even for a small subject, hardly anyone can claim that he know it all. We are learning beings.  

In any dynamic environment, we commit mistakes and learn from it and next time tries to do it better. In reality we all do small experiments. Most of the experiments fail; we learn from them and get ready for next one.

The main thing is learning from the failures. To learn from failures, we need to reflect as individual and team.  This is an ongoing exercise of improving self, to become more effective and efficient over time period.

Learning from mistake is not only true for devTeam but of stakeholders as well.

But before doing experiment, we need to analyses and understand the probable blast radius of failure. The consequences of failure should be analyzed well. To keep the impact of failure small, we do smaller experiments. Organization should also provide the support the teams and individuals for failed experiments.

Also reflecting should be a learning endeavor not the find the punching bag exercise. 

In scrum, kanban, and devOps frameworks, this principle is reflected in following practices:

• Daily Standup
• Retrospect meeting