Group Planning Simulation- A game!

Group planning simulation is a game that can be played with any number of participants. On an average this can be played in a group of 8 participants in 30 minutes.

How we play ‘Group Planning simulation’? 

• A real life practical situation is presented to a group of participants.
• The participants are asked to arrive at a plan of action.
• First they are asked to write down their own plan of action. 
• Thereafter they are expected to go over the different views and arrive at a consensus. 

Why Group Planning Simulation?

• This exercise ignites the analytical ability of the participants.
• This also boosts their ability to function in a group.
• Group planning simulation helps participants to appreciate the situation and plan accordingly.
• This activity enhances the group interaction level of each participant.
• This activity also enhances the ability to think constructively and,
• Ability to cooperate/coordinate.
• Contribution towards collective solution.
• Priority setting

We played this game at SFW India a few days back and enjoyed a lot.

The Modelling Team-

The Players-

Let me know in case of more details of this game needed.

Fun and learn- The Product Box game

A few days back we played ‘Product Box’ game in SFW India. The question arises- why we play ‘Product Box’ game?

Thought?

• Every commodity that we buy from the market is wrapped in a box/cover. This box is the primary medium for the company to market and convince others that their product is better than the competition placed alongside.

How to play?

• Divide the participants into multiple teams.
• Provide each team an empty box, stationary items like multicolored sketch pens, post-its, crayons, cartoon stickers etc.
• Ask each team to efficiently utilize the box outer surface to sell/market the product they are currently developing (or planning to develop).
• Time-box the product box creation/decoration activity (approx. 20 minutes).
• Once all product boxes are ready, each team should market the product to the audience (rest of the teams) by explaining all that is illustrated on the box.
• Once each team is finished demonstrating its product box, ask all participants to vote for the best product box excluding their own product box.
• The Product box with the maximum votes wins!

Significance-

• To create an attractive product box, the participants have to burn their neurons to imagine as to what could be the set of features that their product would offer.
• The better the team understands the business value of any product, the comfortable they are in developing that and in coming up with valuable ideas for the same.
• It is a good way of ice-breaking  for new team-members or the members who generally talk less as all team-members demonstrate and talk about their product.
• This game gives a chance to everyone for asking questions and getting the answers.
• This also showcases how programmers and testers (including other roles as Business analyst, UX designer etc.) work jointly towards achieving the goal.
• Once the product box is ready, it can be utilized later in creating user stories for project simulations.

Again its our mindset!

Who Moved My Success Cheese?

There are many flavors of Agile. Based on need to explore and select may take some time by the team(s)/organisation(s) but the top most challenge being faced is having an Agile mindset. Shift towards agility not necessarily starts when someone knows about any of the Agile flavor, it sometimes starts when even one does not know about it. Years back I read one great book (I still enjoy this book) which is quite significant when we talk about Agility- Who Moved My Cheese? Originally published: September 7, 1998 Author: Spencer Johnson

Here I have tried to share a bit of the story.The elements in bold are the elements of agility which I picked-up from the story.

Who Moved My Cheese? is a story of four characters: two mice, "Sniff" and "Scurry," and two little people, miniature humans, "Hem" and "Haw." They live in a maze and look for cheese.

“Cheese” – a metaphor for what we want to have in life.Each of us has our own idea of what Cheese is, and we pursue it because we believe it makes us happy.

Need

Initially without cheese, each group, the mice and humans, paired off and travelled the lengthy corridors searching for cheese. One day both groups happen upon a cheese-filled corridor at "Cheese Station C." Content with their find, the humans establish routines around their daily intake of cheese.

Following a Plan

Every morning, the mice & the little people headed over to Cheese Station C where they found their own kind of cheese. It was a large store of Cheese that Hem & Haw eventually moved their homes to be closer to it & built a social life around it.

Changes happen and Plans do Fail

One morning, Sniff & Scurry arrived at Cheese Station C & discovered there was no cheese.

They weren’t surprised. Since they had noticed the supply of cheese had been getting smaller every day, they were prepared for the inevitable & knew instinctively what to do. They were quickly off in search of New Cheese.

Later that same day, Hem & Haw arrived. “What! No Cheese? Who moved my Cheese? It’s not fair!”, Hem yelled. They went home that night hungry & discouraged.

Responding to changes

The next day Hem & Haw left their homes, & returned to Cheese Station C. But situation hadn’t changed. Haw asked, “Where are Sniff & Scurry? Do you think they know something we don’t?” Hem scoffed, “What would they know? They’re just simple mice. They just respond to what happens. We’re little people. We’re smarter.”

Haw suggested, “Maybe we should stop analysing the situation so much and just get going & find some New Cheese.Haw decided to leave Cheese Station C while Hem was more comfortable staying in the cheese-less Station C.

Meanwhile, Sniff & Scurry went farther into the maze until they found Cheese Station N. They found what they had been looking for: a great supply of New Cheese. It was the biggest store of cheese the mice had ever seen.

Adapt changes and Continuous Improvement

Haw on the other hand become more anxious & wondered if he really wanted to go out into the Maze.

Haw now realised that the change probably would not have taken him by surprise if he had been watching what was happening all along and if he had anticipated change.

Haw wondered if Hem had moved on, or if he was still paralysed by his own fears. Then, Haw remembered the times when he had felt his best in the Maze. It was when he was moving along.

As Haw started running down the dark corridor, he began to smile. Haw didn’t realise it yet, but he was discovering what nourished his soul. He was letting go & trusting what lay ahead for him, even though he did not know exactly what it was.

To his surprise, Haw started to enjoy himself more & more.

To make things even better, Haw started to paint a picture in his mind again. He saw himself in great realistic detail, sitting in the middle of a pile of all his favourite cheeses-from Cheddar to Brie! He saw himself eating the many cheeses he liked, & he enjoyed what he saw.

The more clearly he saw the image of himself enjoying New Cheese, the more real & believable it became.

Haw wondered why he had always thought that a change would lead to something worse. Now he realised that change could lead to something better.

Being Agile

Then he raced through the Maze with greater strength & agility. Until he found bits of New Cheese. He entered the Cheese Station but it was empty. Someone had already been there.

Haw made his way back to Cheese Station C to offer Hem bits of New Cheese but was turned down. Hem wanted his own Cheese back. Haw just shook his head in disappointment but this does not stop him from finding New Cheese.

Haw realised again, that what you are afraid of is never as bad as what you imagine. The fear you let build up in your mind is worse than the situation that actually exists.

He realises it was natural for change to continually occur, whether you expect it or not. Change could surprise you only if you didn’t expect it & weren’t looking for it.

Haw now realised that his new beliefs were encouraging him to behave in a new way. He was behaving differently from the way he had when he had kept returning to the same cheese-less station.

Haw just hoped he was heading in the right direction.

He continued on through the Maze with greater strength & speed. He proceeded along a corridor that was new to him, rounded a corner, & found New Cheese at Cheese Station N where he saw the greatest supply of Cheese he had ever seen.

Retrospection

Haw wrote down a summary of what he had learned on the largest wall of Cheese Station N & smiled as he looked at what he had learned.

To dive-into this maze, go ahead and get a copy of this book. :-)

And yes, if you analyse the story and want to add some more elements, please do. 

Agile Nuggets: Common questions

Last weekend I attended ATA Vadodara Meet 3 at Baroda Management Association. We had very good and interactive sessions on-

• Introduction to Agile - Scrum Development by Mr. Khushru Doctor 
• Introduction to ASP.net core 1.0 by Mr. Afzal Qureshi

As we all know that Technical sessions always grab the attention of developers and the same happened with the session on ASP.net core 1.0. Once again I saw the charm of ‘open source’, this time with APS.net core.

The interesting and most important thing I observed was the great enthusiasm towards Agile practices being followed in software development among all the attendees. The Speaker was very open and patient. This helped attendees to ask lots and lots of queries and to quench their thirst and know more and more about Scrum.

I have listed a few topics discussed here so these could reach to other Agile practitioners who could not attend this session.

1. What should be optimum length of a Sprint?

2. Why some teams use modified Fibonacci sequence?

3. How much Buffer should we keep during estimation of stories?

4. From where we can get Planning Poker cards?

5. Can we have changes in Definition of Done?

What should be optimum length of a Sprint?
Though most of the teams in agile world (more than 70%) opt for two week long Sprints but it depends on the nature of the project. Recently two of my teams opted for one week long sprints. These teams felt that there were lot of uncertainties and ‘Fail fast’ would be more helpful for the team.

There is a misconception that in a one week long sprint the sprint ceremonies like planning, review, retrospective etc. consumes time as team has to go every week for these ceremonies. But as we all know that the duration of ceremonies are directly proportionate to the length of the sprint.

Why some teams use modified Fibonacci sequence?
The idea of story points is not to bind the thought (size verses hours) during estimation of stories. The sizing should not be so precise that it becomes hindrance during estimation.

     Excerpt from Mike Cohn’s Blog-Why do the cards deviate slightly from the Fibonacci sequence?

We’re anal software people, too. We know that the Fibonacci sequence should go from 8 to 13 to 21. We use 20, though, instead of 21. Of course we used 21 in the early days, but dropped it after meeting with a product owner who looked at the 21 and said, “Oh, a 21. You must be very confident to give such a precise estimate. Most people would have called it 20 or 25, but you called it 21.” We replied that we used the Fibonacci sequence. The product owner said, “The Fibo-what?” After which, we decided that deviating from the Fibonacci sequence would be better because the numbers started to imply a very high level of precision that just wasn’t there.

The 1/2 is included because after awhile some teams decide they want some room in between “free” (a zero) and one. Using 1/2 isn’t something a team should do a lot, but it’s a nice option to have in some cases. More on- http://store.mountaingoatsoftware.com/pages/faqs

How much Buffer should we keep during estimation of stories?
I would strongly say, NOT at all. When we go for estimation we follow sizing. This may be Story points with Poker planning, T-Shirt sizing, Animal sizing etc. Clearly we see there are slots for sizing and these are not distributed even. For example if a story is larger than 8 point which may be of 10 or 11 point but the next number in series is 13. This helps to avoid preciseness during estimation. One important point to note is that keeping buffer will lead team to be underutilized and will slow down the velocity. Also, team will lose the essence of planning and discussion over estimated points by other team-members. Team-members will agree with the largest estimation as everybody will start thinking to have buffer.

From where we can get Planning Poker cards?

Many places for example,

• leanpitch.com/playscrum-cards/ (Pune)
• store.mountaingoatsoftware.com/
• Amazon.com
• …..many other stores
• In addition, there are lots of Planning poker apps, can be downloaded from Play stores.
• For distributed teams we can use online poker planning. Please refer PlanningPoker.com .
• Even we can download printable Planning poker from internet and get it printed.

Can we have changes in Definition of Done?
Yes, we can have changes in DOD. After all continuous improvement is the success mantra for Agile teams. We inspect and adapt!

     Excerpt from Mike Cohn’s Blog-




          Excerpt from Kenneth S. Rubin’s book- Essential Scrum:


I hope you have enjoyed this post. If any reader has any question, please feel free to ask. I would also look forward to suggestions from readers as I could be wrong at places explaining these points.

Agile Nuggets: Few common dysfunctions during software development.

A few weeks back we examined - ‘Stakeholders made the things complicated than they need to be.’

Today let us continue the next – Gluttony

• Gluttony –ScrumMaster

Facilitating multiple teams simultaneously- This leads ScrumMaster losing ‘focus’ from his teams hence results being unjust with them. Generally having a team of size 5 to 9 demands a full time ScrumMaster.

• Gluttony –Product Owner

Pushing team to take-up more and more stories in one sprint- This creates unwanted pressure of delivering stories and mostly ends up with technical debt. Also team never finds time to repay any technical debt which was taken in past.

• Gluttony –Development Team

Gold Plating- Sometimes some developer puts his time adding unnecessary things, for example too much of documentation. This does not add any value to product and results in waste.

There are multiple such points but I took one point for each. Readers can share their experiences/observations.

This Sprint Future-O-Spective with Santa Claus!

Here’s the festive season again and Santa Claus is coming to town. We need to take care of the balloons during the party so they shouldn't look awful.

What may be the impediments which need to be taken care?

•       During freezing weather, balloons shrink up terribly
•       Balloons should be retained for longer period of time
•       Safeguard balloons from our pet parrot with curved beak which is keen of pricking balloons

Our futuristic actions-

• We shall use good quality latex balloons
• Coat hi-float* on the balloons
• User Cold helium or nitrogen
• Keep our naughty parrot in the cage till the party gets over.

*Hi-Float: is a gummy resin that you apply to latex balloons to allow them to retain helium for longer periods of time.

Now team can identify how to keep balloons (forthcoming Stories of the project) safe from the identified impediments by effective utilization of resources available, or by acquiring the needed resources.

Special thanks to Bhavin Shah for drawing this wonderful drawing board.

Agile Nuggets: Simplicity!

I have seen many software projects suffering from few common dysfunctions. A few dysfunctions are mentioned below:

• Stakeholders made the things complicated than they need to be
• The real customer requirement was based on a business need and was something very simple but there was a communications gap between business analyst and programmers
• Gluttony -Product Owner
• Gluttony -ScrumMaster
• Gluttony -Development team
• Habit of taking Debts (Technical/Non-technical)
• Tight coupling of features and functions
• 
  

• A few more…

Today let us see the first one- ‘Stakeholders made the things complicated than they need to be.’

A few years back I read a very interesting analogy presented by Scott Davis,U.S. Below are the excerpts I would like to share with readers.

[My microwave oven only has one button: “add a minute.” To boil a cup of water for my coffee, I press the button three times. To melt cheese on my crackers, one click. To warm up a flour tortilla, I press “add a minute” and then open the door after 15 seconds.

Would a one-button microwave oven ever make it out of the planning committee?

Probably not. I can tell by the (never used) features on my microwave that the committee favored complexity over simplicity. Of course, they probably cloaked “complexity” in the euphemism “feature-rich.” No one ever starts out with the goal of making a product that is unnecessarily complex. The complexity comes along accidentally.

Suppose that I have a slice of cold pizza that I want to warm up. According to the manufacturer’s directions, I should press the “menu” button. 

I am now faced with the options “speedcook” or “reheat.” (Um, “reheat,” I guess, although I’m kind of hungry. I wonder if speedcook will be any faster than reheat?) 

“Beverage,” “pasta,” “pizza,” “plate of food,” “sauce,” or “soup”? (I choose “pizza,” although it does have sauce on it, and it is on a plate.)

“Deli/Fresh” or “Frozen”? (Neither, actually—it’s leftover delivery pizza. I’ll choose “Deli/Fresh,” I guess.) “1 slice,” “2 slices,” “3 slices,” or “4 slices”?

I have no idea how much longer this interrogation will last, so I press Cancel and then the “add a minute” button.

Amazon.com only has one button: “one-click purchase.” Oh, sure, I had to type in my address and my credit card number the first time I visited, but now I am one click away from my impulse buy.]

The well-known 80:20 rule in software says that 80% of users only use 20% of features.

• 45% of features were never used;
• 19% used rarely;
• 16% sometimes;
• Only 20% were used frequently or always.

However the focus on making the product “feature-rich” sometime makes it unnecessarily complex. 

The other example of such feature-rich products I see is my Mobile phone. :-) 
I am not sure how many times I used the fascinating features like 'Gesture Recognizer' it offers.

There are many ways Product owner/Stakeholders can decide the priority of the features needed. One of those I have explained in my other post.

We will keep on discussing the other dysfunctions in forthcoming Agile nuggets, stay tuned!