20 Things To Do with an Umbrella

Have you ever thought of a using your Umbrella for something other than protecting from rain or sun? That was what a group of 20 people did as a part of an ice breaker before start of a workshop. 

During an inception we had few months back, we wanted to run an ice-breaker that would help get a large diverse group comfortable with us & be prepared for a highly intense and creative workshop. We wanted the ice-breaker to be quick, light weight, fun filled & something that gets the creative juices out. 

We decided to use "What is the most Innovative use of umbrella?"

The participants were given one card each and a few sketch pens. The time limit was 10 minutes. The goal was to get as innovative as possible and draw out the idea.   

The results were quite creative and participants had fun trying to think of different uses of an umbrella. Once the time was up, each participant was asked to present his idea to the group.

Here are all the innovative uses the group thought of

We ended by asking participants to vote for best idea. The winner was an umbrella that can be used as a solar powered outdoor rotisserie

Release Planning Exercise

One of the key deliverables of an inception is a Release Plan and release planning exercise is one of the final activities of an inception. Release planning is quite an intense and engaging activity and takes nearly a full day to plan. The below picture is of a completed Release plan after a day long planning session. The release plan has 3 streams to start and the 4th stream starts later down the line. This release plan had releases slotted every 4 weeks with first release in 10 weeks. 

For me, this exercise is one of the most important aspects of an inception. Today I am going to talk about how I facilitate a release planning activity. Release planning needs a bit of preparation before the exercise can begin. The first step is to ensure that you have the following things ready before you call the team for planning

• All the story cards written down on index cards. One story per card. Group them by features (see pic below). You can color code the cards for each feature to have a more visual effect. If you do not have cards you can use paper or post-it notes. Although index cards on table are the most easiest to move around. 
• A long table for cards to placed. If long tables are not available, a long running wall with cards stuck using blu-tag (or post-it notes on wall) also works. But moving cards on a wall is a bit troublesome. Or you can just clear the area in the room and use the floor.
• Iteration numbers written down on the top from left to write. The pink post-its in the below picture are iteration numbers

Once the first set of preparations are done, I call the inception team -  Devs, BAs, UX , QA (whoever has been part of the inception). I handover all the story cards that are grouped by feature to the team. The next task for this team is -

• To identify feature they would like to play first. Key things to consider while deciding the first feature to play are - the feature with the most technical risk, or a feature that is needed to building the initial technical frame work or the one on which other features have most dependency etc.
• Place the cards in a series and create the first stream of work.
• Once the first set of cards are placed a similar exercise is repeated for the remaining cards. The  team tries to determine the next important feature they would like to play and place the cards as the second stream and so on. Any features having dependency are placed in a single stream as they cannot be played in parallel.

A particular feature might be split in to streams after the initial dependency stories are completed. You don't need to slot each and every story just do enough for first set of discussions to start. Below is a picture of one of the release planning activity we did. We slotted around 10 parallel streams as they were technically possible. 

How many cards are to be slotted per iteration, per dev pair is something that the development team decides. It is based on complexity of the stories, our understanding and based on our track record of how much we have accomplished in the past. In the above picture you can see that based on our track record and comfort of the devs, we had slotted 2 stories per iteration.

Below is another picture of the inception team busy in discussing how to slot the stories in different streams. If you look closely you can see a stack of cards with each person, these are story cards grouped by features.

I prefer placing these cards at the bottom and leaving some place at the top so stakeholders can move the cards from bottom to the top. Here is a pic of how the cards look when placed at the bottom leaving place at the top for planning with the stakeholders.

Once this step is done, you are ready for action. Now call your stakeholders and walk them through what you have done and why. Talk about what technical dependencies exists and why you thought a particular feature needs to be slotted first.

Remember the main aim of the release planing activity is to define smallest possible, business relevant releases. Get your business stake holders to define small goals so that you can take things to market quickly.

Apart from deriving the aims of the release from the inception activities, I have found time boxing a great tool to get stakeholders think in terms of small and frequent releases.

Many times I have asked the customers to prioritize features that they want released first based on the assumption that money gets over by a certain time. Another option is to just draw a regular interval releases - like every 4 weeks or every 6 weeks and ask business to prioritize what gets released in that time frame. You can make this visual by drawing a line with a tape or a ribbon across the table at a gap of every 4 or 6 weeks

The key thing to remember is that business can only decide which stories get done, they cannot decide how many stories get done in the given time frame. This is because as development team, you know the capacity and pace at which your team will perform and business just gets to swap in and out stories and you as development team decide if they can be accomplished in the time frame and if the dependencies are taken care of.

You will soon realize that customers start discussing and start to move stories based on what they want first. Its an iterative process and you keep going through it discussing till all your stories are slotted. Here is a picture of stakeholders moving cards to prioritize requirements.





By the end of the session, you will have most of your stories slotted and releases finalized.  Below is a picture of a completed release plan. You can add different color post-its for key dependencies or mile stones. You can color code a feature by different colors to make it a lot more visual. In the below picture, we have 4 streams of work and then some dependencies added in terms of data & UX followed by a 5th & 6th stream which starts later down the line.

You can either slot all your stories or decide to slot only the initial one and then re-plan based on how things progress. The important thing to remember is that this is just a starting point for planning and release planning is a continues process and it keeps evolving as the project progresses. You can read more about how release planning can be used as continuous planning and tracking tool here

In one of the recent inception, we used a i-pad to record the entire release planning activity. Here is a quick 36 sec video that summarizes the whole day. Thank you Michiel for sharing the video :)

The Agile Lego Game with a twist of distribution

Two weeks back, we played the Agile lego game in office. The idea was to give a feel of how distributed agile teams works to our new Product Owner and few new team members.

A typical agile lego game consists of teams working for around 3 to 4 iterations and trying to build something using the lego blocks. A product owner is sitting with the team while they build and helps the team in understanding the requirements. He is right there to answer all the queries and the teams get a feel of how interactions help over documentation. The team also tries to builds incrementally and learns the value of being able to build small and change as needed.

We aimed higher, we wanted to give a feel of distributed teams and hence had to add the twist of taking the product owner away from the team and available only on calls :) 

We started by creating 3 teams with 5 members each. Each team had 2 product owners and 1 facilitator assigned. We called everyone and explained the rules of the game

• Planning Meeting for 3 mins (including estimation)
• Each iteration is 7 mins 
• Showcase to get stories signed off is 2 mins
• Post showcase everyone will come together for a huddle to discuss the learnings and observation
• The team gets 3 iterations to build an animal
• Since the teams were to get a feel of distribution, we had set-up 6 laptops with a gotomeeting (web conferencing and online meeting tool) which we use regularly on our project. The customer was available online through it. 
• A team could make 1 person travel once during the iteration to customer site (if needed)

The teams were assigned their Product Owners and facilitators and we started the first iteration. The teams were on one side of the office and the product owners were sitting in meeting rooms. Below is a picture of the teams trying to talk to the PO over a call.

The teams started by looking at stories and trying to talk to the PO to understand more details on each of the stories. Once call was done, the teams got head down building the animal. Here are some pics of teams busy building the animal using the lego blocks

In no time our facilitators called "time out" as time for development was over and it was showcase time. Since it would have been difficult to show a lego animal over call, we decided to have the PO visit the teams for showcase. The teams had to showcase the stories that they had developed and get it signed-off from the customer. A few teams managed to get a couple of stories signed off.

We called all the teams together and asked for observations/comments

• Communicating over a call: The first point was how difficult it was to interact over the call, all the teams & PO understood the challenges of communications that we face on an everyday basis and the importance of using the right tools - online meetings, speakers, camera etc.
• Availability of PO: Some of the PO decided that they were busy in other meetings and were not available for calls ( a very real life scenario) that gave a feel of what the teams face and how important is the availability of a PO for the success of the team.
• Not pushing back on design constraints: Since one story mentioned build the animal in a color, the teams just went ahead and built it in a color of customer choice. No one pushed back on this and later realized how much constraint it adds on the team since lego blocks of that color are limited. This is also a very real life scenario were you might end up making some design decisions that might put big constraints on you if you only think short term.
• Not deciding which stories are priority: Most of the teams just started working on stories immediately, they did not take advantage of planning meeting to discuss the priority of a particular story or the business value it might add. The customer was available and would have informed if they needed a particular story or not.
• No Collaboration between team members: Another challenge that teams faced was many people ended up doing the same activity (like building a fence for the animal). This happened because team members were not collaborating and there was lack of communication between them. This helped in understanding the importance of communication and collaboration between teams. The teams discussed how dining table setting for working helps in communication.

This session was very helpful to the teams as it gave them a quick feedback on how they are doing, and what they need to improve upon. This also emphasized the need of doing regular feedbacks in the team.

The teams then got into their next iteration. This time some of the teams improvised based on the feedback received. This time we decided to have the PO with the teams.

• Some teams planned well and decided on what they will pickup in the iteration. They got their PO to prioritize their stories.
• One team managed to collaborate really well - divided the tasks among themselves
• They got their PO to work very closely with them and managed to build the animal by second iteration.

Below is the picture of the team collaborating effective, working closely with the PO and the animal they build at the end of the second iteration.

It was now time for some twists, based on what we observed

• We decided to swap the PO of 2 teams. We just announced that both these teams now have new PO. It was exactly replicating our real life scenario where we had a new PO.
• We observed that the team which was collaborating well, was heavily dependent on one person interacting with the PO, we decided that he is out sick and took him out of the team
• We also decided that although one team had managed to build the animal in the 2nd iteration, due to business requirements we wanted lots of changes in it.

The idea was to give the teams a feel of real life situations and see how teams adapt to change of key stakeholders and change in business needs. We also wanted the teams to experience what happens if there is a single point of failure. 

At the end of 3 iterations the teams had some real fun playing the game & building the animal along with the an effective & long lasting learning experience.

The Agile PM Toolkit Series - River of Life/Time Line

Another tool in my PM Toolkit is the "River of Life". A fantastic tool that can be used for varied purposes. I have used it for retros, personal journeys, milestone celebrations, or even presentations.

Today, I would like to talk about the "river of life" as a tool in projects. Below is a picture from 2 different projects where I have facilitated/attended the "river of life". In one project (the picture with orange and pink post-its) I have used it as a mechanism to identify things that have worked for us(orange post-its) and things that have challenged/not worked for us (pink post-its). In the second project we used to to identify things that we "learned", "liked", "lacked" and "longed". 

Below I have tried to capture step by step flow of all the activities that I do when I facilitate a river of life exercise. The exercise listed below was done as a part of milestone check and the team wanted to reflect on past and take a stock of the current situation.

Step 1

To run a river of life exercise, first determine a timeline (1 month, 3 months, 6 months) and determine what is it you want to achieve - a retro, a celebration, just talk etc.

Step 2

Get the team to start identify key events that have happened during this time. The key events can be anything that is significant to the team - a milestone reached, a team outing, some one joining the team etc. The idea of identifying key events is for the team to recollect what happened during that time. One event per post-it. Get the team to put it on the time line 

Step 3

Now do a walk through of the events, this helps in the team talking about incidences and recollecting them. Some times just this activity is sufficient and you may want to end the river of life here itself. I have used this when I just want the team to talk about things that have not been spoken about, things that I want the team to "get out of the system" and move on. At times I have also stopped here when I just wanted the team to reflect on things accomplished and celebrate :)

But if you want to do more then go to Step 4. Based on what the aim of my session is I ask the team to do the next set of activity. As an example, I will talk about how I have used it to discuss things that have worked and things that are challenging.

Step 4

Once the team has spoken about the timeline, I distribute the post-its again and ask the team to now think about things that have worked for them, or made them happy or made their life simpler, anything that has benefited the team. All the things have to be in relation to the timeline. The post-its will be added above the timeline. The higher the happiness factor the higher the post-it is put on the time line. 

Step 5

Similarly we repeat the exercise for all the things that have challenged, made you go slow, made you sad/unhappy or disturbed. Again the post-its are added below the timeline. The unhappier the event the lower it is placed. 

Step 6

Once all the events are added, walk through the events and talk about them. Some times the team discusses action items for avoiding the mistakes, actions to continue the good things. Don't mandate the action items - let them flow on its own and if they don't, its OK. The aim is to talk about it.

Finally, this is not an every day activity. Use it once in a while after some significant events have happened. It can also be used as a end of project retro.