Project Retrospective

Retrospectives are there to help the team keep getting better by looking at whats is good, what is bad and what can be improved with how we work. But if no body speaks out, finding facts can be next to impossible. Also we tend to remember the bad more often. Add a multi-site team to this mix and what you get is a recipe for disaster.

So when a short project of three months (where a RnD team collaborated with consulting) ended and the retro for it came up i wanted to avoid a disaster and make this retro a 'good one'. 

For me gathering the data seemed the most important. After a chat with our in-house scrum guru, Hiruna we came up with an activity called a 'Discussion Matrix'. Idea was to post at least one  point of discussion before the Retro. And you had to post a reply for at least two other.  It was an instant hit. 

For a distributed team use an online white board such as http://groupzap.com or  http://linoit.com. Following is a basic summery of the activity.

Activity: Discussion Matrix

Stage: Gather Data

Time: Add the white board one week prior to retro. 30- 45 minutes during retro, for a team of  6.

Purpose: Use this for a project retrospective to find important topics about the project history. Create a discussion before to coming to the retro if time is limited.

Steps:

1. Create the online discussion board and share it among the team.  Describe the process.
2. Ask each one to enter at least one discussion point and comment on two others.
3. Before posting a topic check if others have raised it. If so then comment on it rather than adding.
4. During the retro Describe the process again and ask if someone needs to post any last minute topic or comment. If so give 5-10 min.
5. If there are less than 10 points take up a discussion on each. More than ten group and/or vote to prioritize.
6. Ask each person to read the ideas listed. Have an open discussion on the points. 
7. Use the discussion to generating insights.

Follow on activities: Prioritize with Dots/ Short Subjects

F.A.Q

• Can it be run anonymously? Yes. But having names could be a plus as well. It allowed team member to use the comments section to appreciate another.   

Scrum Master vs Process Master

Scrum Master vs Process Master. Sounds like something from Mortal Kombat or some cheesy movie. Today a friend of mine asked me why I have put 'Process Master' in my bio here at blogger. It should be Scrum Master right?  Tell that to the 'process' guys who came up with this. Truthfully , i didn't like it either. The official explanation is that the process we follow is 95% Scrum and 5% Kanban. 

What is Kanban anyway? Kanban simply means 'sign' in Japanese. Henrik Kniberg has a very simple and visual example. He tells a story of a Japanese garden where a guard hands you a ticket when you enter. Entrance is free and there is no info on the card. When you go out guard as you to return the card. And this is not a fancy hi-tec card with. Just a number printed on it. So what is the use of it. Answer is to keep track of how many people are in the garden. Maybe there is only hundred cards. Once the guard run out of them he will not let anyone enter until someone leaves and returns the card. And that how we run the support process Kanban style. We only have limited number of slots for bugs. When they fill up we don't take in any more. When one gets patched we take the next one on the list. Sounds simple right? and it is. And for that I am called a Process Master.  If this was Mk I think the Scrum Master would win. Flawless Victory!

Love it, Hate it..JIRA Agile

We had our weekly demo today. In the morning i wanted to make our Jira WFB to show the task group by user stories and it in turn grouped by epics, so we could easily show an overview of progress during the demo.  30 minutes later I realized it could NOT be done! Well not with the current JIRA version anyway. Oh how I long for the White Board days.

Well not really. When we started agile in our company in 2012 we began with a simple work flow 'white' board complete with yellow stickies. It looked great but soon it was a mess. Partly b'coz we tried to put lot of info on  the little 3M sticky and partly due to lack of  experience in agile ways.

I was glad when we shifted to an online WFB. I think it was the Atlassian JIRA with GreenHopper plugin (now called 'JIRA Agile'. It had a few kinks but I think it was OK. Today we used it in almost every way imaginable. Entering user stories, tasks, spikes bugs and  estimating them , building a sprint backlog, planning a sprint,  visualizing team activity and reporting on team progress.

JIRA Agile makes all these things easier than ever before.  Wish it could grope by two levels!   

Can't see the forest for the trees

Today morning after the stand-up our PM asked us how do feel about the "overall progress" of the project. Since we were right at the halfway point of a three month project it was a real good question.  

Each of team member knew how the User Stories were progressing yet I got the feeling we were not seeing the whole situation clearly. Maybe because we are looking too closely at small details, or because we are too closely involved. You just can't see the forest for the trees.

First Post. Inspect and Adapt.

Inspect and Adapt ..they are the two most important things to remember when practicing scrum. Days, weeks, months or even years later i might come back to this post and wonder what could i have written as my first post. For today this seems good enough!