The Agile PM Toolkit Series - Holiday Wall

Our teams need some kind of visual indicator about availability of team members on a given day/week. In order to facilitate this, I have been using a holiday wall in order to bring this visibility on the table.

Below is a picture of holiday wall in 2 of my projects.

Add caption

A holiday wall is a very simple matrix with names of team members and dates. Team members indicate planned vacations/time off on this wall by marking a simple cross. We typically try to maintain a visibility of 2 weeks and typically update this on a Mon or Fri.

A visual wall is useful when,

• Signing up for stories - you wouldn't want to start a story by a pair where both are off for next few days or you will ensure that team member who has a planned vacation pairs with some one who is not on vacation at that time.
• Deciding in what to sign-up for an iteration - you will sign-up for less, if the number of people available on the team are lesser 
• Setting expectations with stakeholders
• Informing team of your plans in advance

A holiday wall is useful for planned vacation and any adhoc/unplanned leaves are not updated here. Its good to talk about them during standup.

For planned leaves which are beyond the period on the wall, we use a google calendar or put it as comments on the wall. 

A point to note is that this is not a substitute for communication, and team members definitely call out about their availability and planned vacations. The wall is just a visual indicator.

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 - Capacity Planning and Tracking Tool

Today I would like to share an excel sheet that I use for creating my capacity planning, Burn-up and Scope tracking. 

My colleague Angela Ferguson had shared her planning sheet with me (thanks Ange). Over the years I tweaked it for my needs and added my specific flavors to it. The attached excel sheet is my version of capacity planning and tracking.

At some point while using this sheet, I needed scope tracking sheet and hence added it. The burn-ups from tools were not effective as I wanted to add scope lines and other things so also added a burn-up sheet. In some projects I needed finger charts and also have another version with finger charts as well. Drop a comment if you need the one with finger charts.

I use this excel to determine the capacity of the team and hence the velocity. I also use this sheet for regular tracking of leaves and determining the utilization so I can plan better for future.

Instructions for using the excel sheet are mentioned in the "Read Me" sheet.

Please download it as "Excel" and not as a google doc. The formulae and formatting will ONLY work on excel. Feel free to change it as needed and share it with others.  Please drop your comments on how you find this tool. Let me know if it was easy or tough to use and understand the instructions.

Capacity Plan and Tracking

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.

The Agile PM Toolkit series - The Release Planning Wall

I have started with the The Agile PM Toolkit series with the thought of writing about tools and techniques that I have found quite helpful while PMing Projects.  I have been using most of these tools quite regularly. Some I have learned them from my fellow ThoughtWorkers and adopted in my projects while some I have derived on my own. The idea is to share these and spread the knowledge. Please provide your valuable feedback and comments. Feel free to share this with others.

The first in the series is the "Release Planning Wall". 

The Release Planning wall is an outcome of the Release Planning exercise done during inception. It helps me in planning and tracking the project on a day to day basis. With a release planning wall, I am able to identify

• Number of Parallel streams planned
• Dependency of stories in a stream and across the streams (add small post-its of different color to highlight dependency)
• Priority of features/stories planned
• How a feature is being build (each story card for a feature can be of different color)
• How are next set of Iterations planned 
• Most importantly, the Big picture view. How everything fits in together

The release planning wall is a typical grid of story cards arranged in rows and columns. The columns represents iterations and the rows represents parallel streams of work. Most often one stream is equivalent to work accomplished by a dev pair in the project. Each card represents a story. The cards can be color coded to represent specific features.

Whenever possible, I try to setup this wall just on the left of the current iteration wall. This way there is a visual indication of work that needs to be done on your left, followed by work that is currently in play on your right.

As iterations are completed the stories on the wall move from the Release wall (future iterations) to the Current iteration wall. The Release wall is a  continues planning wall and work will flow as project progresses. The wall keeps on evolving as team starts delivering. It is flexible enough to change as per business needs. The focus is to ensure that the immediate set of iterations are planned really well. The future can be planned on rough assumptions and can be hazy. Things keep getting clearer as you move ahead. 


The wall can be made a lot more visual by color coding features, adding small post-its, adding a grid etc. The above pictures has pink post-its to indicate UX dependencies and yellow post-its for data dependencies. You can get as fancy as you want.

Planning and updating the wall is a team activity and you need inputs from from your team to identify dependencies and plan the work. The BAs, Devs, UX & PM can all work together to prepare the wall. The Product Owner can define the business priorities for the planning.

This wall is a physical wall and can be replicated in tools like Jira and Mingle for remote access or distributed teams. I understand that it is duplication of work to have the wall at two places. But the benefits of having a visual indicator in front of the team is so high that I do not mind the effort of duplication and keeping the electronic wall in sync.

Update: I have written about how to facilitate a release planning session during inception here. This is the first activity post which a release plan can be used as a tracking tool.