Goal seeking Retrospective

I spend lots of time thinking about my teams and how to effectively use retrospective tool for Dominating Don to Silent Sara. I like to start the retrospective with an ice breaker and follow lots of different style. Some worked very nice and other failed miserably. We also focus on action items at the end. Awesome right!!!!  .

After doing almost 500+ retrospectives, one thing I have learnt that having a goal always helps. I experimented one more thing, which seems to have worked better. 

We did "High Performing Tree" retrospective with a simple twist in the language. We start every sentence with "How might we" or "Sometimes I wish". Very quickly we started filling up our tree with really clear yet individual assessment about team.   

We went over each sticky note and created our own list of important traits. Mainly focusing on, "How we can come together and work as a unit?" and "What kind of group level feedback we would require to be a performing team." Our focus was to understand, "what kind of team we actually are "and "what kind of team we imagine to become". We came up with a small plan and  quick "performing traits" burn up for ourselves. 

This was a turning point for my team. Next retrospective was very focused towards those goals and stabilizing ourselves to meet them. We always tried updating our "performing traits" burn up at the end of retrospective. 

Hope this technique will help your team as well.  Try and let me know your feedback. 

Cheers!

Manisha

Execution of Retrospective in Kanban world

No No, don’t worry I am not going to bore you with the benefit of retrospective. Retrospective is great tool if done RIGHT. My last blog touches on done right point little bit and will do a deep dive into done right topic soon.

But right now, I am wondering about a perfect way to do retrospective for teams following Kanban. Yes! you read it right! PERFECT WAY. So thought of sharing my experience on the execution aspect of retrospective for teams following Kanban.

My teams in past have been engaged in retrospective ceremony in following way : 

1. Regular 1 or 2 weeks cadence like the one scrum prescribes: Teams meet regularly and do their inspections in a regular rhythm. 
1. Advantages: Team is taking time to think and focus on continuous improvement at regular intervals. 
2. Disadvantage: Team members need to remember or recollect things on retrospective day.
2. Retrospective Item (RI) Limit based Cadence: Teams will have chart on the wall in team room or in confluence or google doc to collect retrospective items. Specifying the RI LIMIT for the team.  Something similar to WIP Limit. Team would meet as soon the limit is met. We should always keep 2-3 weeks upper bound limit. i.e. if they can't reach their RI Limit in 3 weeks they should huddle around to discuss points for improvement.
1. Advantages: Team controls the limit and does it, what feels right for them. My earlier team had done it and they kept the RI Limit to 3. The person writing 3rd item was responsible for scheduling a meeting on teams calendar. Agile Coach was responsible to remind them incase 2 or 3 weeks limit was broken.
2. Disadvantage: Team members might miss the retrospective since there is no fix cadence. Team with very low maturity level might feel overwhelmed..
3. Just in time Retrospective: Do it when you need it. Team members would call a meeting when they will feel the need of it. 

1. Advantages: Team members have full autonomy to call for a meeting, whenever they feel the need of it. The topics are fresh in they mind and they can find better solution by discussing them. It comparatively takes less time but requires high disciplined team.
2. Disadvantage: Same as earlier one, team members might miss the retrospective since there is no fix cadence. I would not suggest this style for any new team. This is definitely a good tool for mature and fully performing teams.

These are the three styles of retrospective cadence my teams have followed in past. Do share if you have tried something else and have worked well for your teams. I am trying to find a best way for distributed teams and my hunt is still on.

So long

Manisha

.  

Why we need Agile Retrospective?

Retrospective was designed to address Twelfth Agile Principle, which states: "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly." 
 

Prime directive

“Regardless of what we discover, we must understand and truly believe that everyone does the best job he or she could, given what was known at the time, his or her skills and abilities, the resources available, and the situation at hand.” 

Purpose of Retrospective

Using Retrospective :

• we focus on learning and understanding instead of blaming 
• we should find the root cause of the problem vs. just finding the symptom 
• we Inspect in past and do the changes in FUTURE to get adapt according to our environment.
• we are improving our future work.
• we are extending the usefulness of current and future activities.
• team understands what went wrong together so they can change their way towards betterment.

What Agile Retrospective is not

• History Lesson learnt 
• Hot air (Blame Game)
• transform into complaint sessions: (People do not complain with bad intentions. They simply exteriorise what is affecting them. They have needs that are not being fulfilled and they need to express their emotions. Problems occur when the receiver is put off by the complaint and immediately enters defensive mode and counterattacks. )
• Change the world 
• Wishful thinking
• Ideas fest
• After action review 
• Postmortem  
• Project Review

Structure of a Retrospective 

• Set the stage ( What you can expect to get out of this exercise and choose right style for facilitation.)
• Gather data ( What )
• Generate insights ( So What )
• Decide what to do ( Now What)
• Close the retrospective ( Action Items)

Thanks

Manisha

What is an Impediment?

One of my team always says "Wish we did not have this meeting today" or "We are still waiting for our server rule to be created" or "Thoughts on how to get feedback sooner from architectural group" or "We are still figuring out whom to ask for getting rights for TFS server". Their comments made me think, how can I help them and what to do to raise their concern.

During this thinking process, I asked myself, are these impediments?

At present, we have mechanism to flag stories or tasks in Jira as blocker or impediments. We, agile coaches, get alert whenever somebody marks an issue as impediment. We all work our best to remove it as quickly and as efficiently as possible. Impediment for us is anything, which stops team from doing its work. 

What if we change the definition to, "Impediment is anything which is preventing our teams from achieving continuous flow as fast as possible." it can be anything like delay in getting new server for testing, getting feedback from other group, too many meetings complain etc... Most of the times team members do not specify them as impediment but these things effect our flow. Hence keeping an eye on them is very useful and can help teams a lot. 

Alongside, we facilitated a retrospective called Angel retrospective. We asked team members to wish for one thing which will help them in achieving their goal in most effective and efficient way. We collected their wishes and it was starting point for our impediment list.  

I am still working on finding techniques and methods to collect impediments and work on removing them.

Let me know your experience

Manisha