Saturday, December 10, 2016

Your teams 1st retrospective will be your hardest retrospective

High emotions, Intertwined issues and Inexperience are the key challenges that will all combine to make your 1st retrospective the hardest retrospective you have to facilitate. This situation is similar to your first driving lesson being on a rainy night, while you are surrounded by drunk drivers. Luckily there are steps you can take to tackle all three key challenges, and run the teams first retrospective successfully.



High emotions

For teams that have not had an effective avenue to express and tackle their day to day work issues; there tends to be a lot of emotion released in their first retrospective. During the retrospective team often realise they have a voice and are being listened to; hence a lot of the issues they have been frustrated about are vented. The emotional venting that occurs is hard to hear yet often therapeutic for all involved. If you and the team can turn those emotions into actions that address some of the teams’ frustrations they will not just like retrospectives they will love them.

Mitigation actions 

  1. Display the Prime Directive and read it out as part of your introduction.
  2. Acknowledge all input provided by the team, even if you disagree with it. You only have to acknowledge what is said, you do not need to agree with it. Merely the simple act of acknowledge is enough for the team to feel heard and hence reduce the level of emotion in the room below boiling point. The easiest way to acknowledge their input is to read out all of the post-it notes that they write out in the gathering data phase.



Intertwined issues

New teams and existing teams that have not held retrospectives previously; will often have their first retrospective dominated by a tangled mess of intertwined issues. The trouble is that one or two root causes are creating many, many symptoms and likely a lot of frustration. So no matter which symptom the team selects to analyse; it is intertwined with several other symptoms. This tangled mess drives the team conversation around in useless circles unless structured techniques are used to untangle the mess.

Mitigation actions

  1. Ensure you have plenty of time to discuss the first topic
    1. Schedule 90 minutes for the retrospective, one hour is just not enough time
    2. Time box the early parts of the retrospective to ensure enough time for discussion at the end.
  2. Accept it is likely that the team will only get to analyse the top priority issue. The good news is that addressing just one issue will be big success for your first retrospective!
  3. Use Tree Root Diagrams to help untangle the intertwined symptoms.




Inexperience

When this is the first retrospective for the team, yourself or both, there are likely to be feelings of excitement, anticipation, apprehension, uncertainty, etc. Also the role of facilitator is challenging at the best of times, as you attempt to juggle time-boxing, active listening, note taking and group facilitation. Thankfully there are plenty of resources available to prepare you and the team. Here are just a few approaches to get you started…

Mitigation actions for your inexperience

  1. Observe retrospectives run by more experienced facilitators.
  2. Pair with an experienced facilitator for your first retrospective.
  3. Delegate Time keeping to someone in the team.
  4. Delegate taking notes to someone in the team.


Mitigation actions for the Teams’ inexperience

  1. Circulate the retrospective objective and agenda ahead of time
  2. Provide the team with Retrospective Prompting questions a couple of days prior to the retrospective.


Sunday, December 4, 2016

Retrospective Prompting Questions

Retrospectives can generate an enormous amount of input in the right circumstances; which allows for a rich investigation of how to improve the team. However there are some situations which can lead to an input drought; and the prevention of team improvement. I have found that the list of questions at the end of this article can be used to easily prompt a team to generate input which leads to an effective retrospective and steady improvement of results.



There are four situations in which these questions prove particularly useful:


One: Team transforming from command and control culture

When transitioning to agile from a strong command and control environment, many team members say as little as possible in Retrospectives. They are used to being told what to do, and do not want to seem like the ‘trouble maker’ by pointing out obvious issues. The prompting questions help them to find something that the feel comfortable providing input on. The more often they provide input in retrospectives and don’t get in trouble for it, the more useful information they will provide in the future.


Two: Team is new to retrospectives

Teams that haven’t done retrospectives in the past often don’t understand the scope of what can be discussed. To aid the explanation of scope and to help bring out information from quiet team members the following list of questions is often useful. 
Again for teams transitioning from a command and control culture the scope of what they could change in the past was very limited. This compounds their reluctance to speak up. 

Three: Retrospectives stagnating; due to repetition

For teams that have done many retrospectives; there can come a time where they run out of things to discuss. The prompting questions help them to broaden their view and finds topics worth discussing as a team.

Four: Scrum Masters

For the Scrum Master it will be worth reading these questions prior to each Retrospective and working out which questions could be used to prompt discussion within the team.

Retrospective Prompting Questions


Delivery


  • Is our team delivering as fast as possible? If not, why not?
  • Why did the extra tasks appear in the sprint? 
  • Why were User Stories/Tasks not completed?
  • Why were some User Stories/Tasks, only partially completed?
  • Did the team over commit? 
  • Was the team reliant on one person/skill set to complete a task? 
  • Were any milestones missed?
  • Were last Sprint Retrospective actions items completed?
  • Where our estimates accurate? Both Story Points and hours?


Quality


  • What was the quality of our deliverables appropriate?
  • Did the Review/Demonstration make you proud to be a member of this team?
  • Was the test coverage (both automated and manual) sufficient for our needs?
  • Did our documentation provide the information that we required to complete our jobs?
  • Did rework hold us back this sprint?
  • What was the cause of the bugs/tickets that we worked on this sprint?


Scrum 


  • It has now been X sprints that we have been using Scrum, do we think our situation is better or worse since starting? What is better? What is worse?
  • What did everyone work on immediately after the Planning meeting? Why did people work on items other then high priority User Stories?
  • Why were low priority tasks being worked on, while high priority user stories were on hold?
  • Was the Product Backlog ready for use at the planning session? Prioritised, estimated, enough detail?
  • Did the Burn-down Chart realistically represent the progress of the team?
  • Did everyone view the Burn-down chart as useful?
  • How did everyone contribute to User Story value?
  • Is everyone happy with how the Stand ups are working? Can they be improved?
  • Is everyone happy with how the Reviews are working? Can they be improved?
  • Is everyone happy with how the Retrospectives are working? Can they be improved?
  • Were the actions created from our last Retrospective completed?
  • Were the actions created from our last Retrospective beneficial?


Communication and Team work


  • Did anyone in the team do outstanding work that should be acknowledged?
  • Did team members just at the chance to help each other?
  • Did anyone have difficulties obtaining timely information/assistance from people in the team? I.e. Architect, Test Specialist, Documentation Specialist, Scrum Master, etc.
  • Did anyone have difficulties obtaining timely information/assistance from people outside of the team? I.e. Product Owner, external Technical Expert.
  • How is the morale of the team?
  • Was everyone clear on the team goals?
  • Was everyone clear on their personal priorities?
  • Did internal knowledge transfer occur in a timely and effective manner?
  • How was the team internal communication? Was it clear, concise and timely?
  • How was the intra-team communication? Were expectations and dependencies clear?


To my blog readers


  • What questions would you add to this list?
  • Are there questions you would remove, or change?

Saturday, November 19, 2016

Release Vision Exercise

In late 2014 the delivery team working on the Copyright Hub as part of the Digital Catapult UK where a bit confused about the upcoming Beta Release. They were getting mixed messages regarding what the release was for, when it was due, and what were the most important features to be included. To resolve this situation I gathered the delivery team and the customer representative and ran a collaborative Release Vision Exercise, which is described below.


Release Vision (45 minutes)

Who? 
Who is the audience of the beta release?

What? 
At a high level what will the beta release contain? Aim for no more than five bullet points.

Where? 
Where will it be used? All industry sectors? All parts of England? Europe, etc.

Why? 
Why would the users and stakeholders make the painful effort to change their existing habits and migrate to this new product? 




Strap Line…
What is a one sentence summary that we could use internally? LITMUS TEST: Can the delivery team come up with a strap line that they and the customer representative agree with?


The list was brainstormed, then discussion followed by dot voting determined the winner.


Release Levers (10 minutes)
What is the order of importance of the following items? Please note they must be ordered, i.e. there cannot be two priority one items.

  • Scope – number of features included in the release (more is important)
  • Cost – project budget / number of people involved (low costs is important)
  • Schedule – when will it be released (earlier / on time release is important)
  • Value – Usefulness and usability of the included features. (user experience is important)
  • Aspects – ilities of the system, i.e. Security, Maintainability, Performance, Adaptability, etc. 

The blue numbers are the aggregate result of the Product Owner and Customer Representatives separate votes.


The end result

This process surfaced some key issues that the customer representative and Business Analyst (acting as Product Owner) disagreed upon and allowed them to resolve these differences. It also provided clarity to the delivery team regarding what they were being asked to do. The end result was a successful release that has changed the face of copyright on the internet forever: Video of Launch Party

Sunday, November 13, 2016

Tree Root Diagrams, a powerful problem solving addition to the Five Whys

Solving problems in this complex world can be a huge challenge. The Five Whys is a powerful technique in our hunt for the root cause of an issue; however it rarely provides the full answer. Combining Tree Root Diagrams with the Five Whys can ensure that your team gains a full understanding of the root cause(s) of the issue. Once you know the root cause(s) a permanent solution is only a few simple actions away.

A Tree Root Diagram captures all of the causes linked to an issue in a downward expanding tree of causes. These diagrams often look like the root structure of a large tree. They are most useful when a group of people is collaboratively solving a complex problem.



The approach is straight forward: on a large whiteboard write your issue (really the symptom) in the top middle part of the whiteboard. Ask “What caused this to occur?” Write a very brief summary of each cause that is mentioned and draw an arrow from the symptom to each cause. Now repeat for each cause, building up your tree as your examine each cause. For each Root Cause you identify, circle it and come up with an action or two to address it. List the actions near the Root Cause and draw a line from the actions to the Root Cause.

Benefits of Tree Root Diagrams
  • Finds multiple causes of a single symptom; including related issues.
  • Visualizes the relationship between the symptom and its many causes.
  • Visually links actions to the Root Cause the group is addressing.
  • Allows the group to discuss tangential topics then return to the core issue without losing track of what they were up to.
  • Acts as a record of what the group discussed and agreed upon.


More Examples
A simpler example

An example of when it is quiet linear.

A complex example


How I stumbled onto Tree Root Diagrams
Around July 2015 I was coaching some new Scrum Masters in effective problem solving and usage of the Five Whys. I keep hearing myself suggest to them to write down each answer to Why that the team called out. My intention being to get them and the team realized that the first answer is rarely the root cause. I quickly realized I was not doing this myself and set out to walk my own talk. What I found when I made a concerted effort to write down the causes, was that there were often multiple possible answers to each Why. Hence my notes quickly turned into tree diagrams which I labelled as Tree Root Diagrams and have used ever since.

Ishikawa diagrams

Tree root diagrams are similar yet different to Ishikawa diagrams turned 90 degrees. Ishikawa diagrams focus on categorizing the different causes in a hierarchy. Tree Root Diagrams focus on the linkage between causes; of potentially very different categories.

Tuesday, May 26, 2015

Weekend Escape an agile Backlog Management Game

Weekend Escape is an agile backlog management game where small teams collaborate to order a backlog with a specific business goal in mind. Once the team has produced their backlog, they review the output of another team and discuss the differences. Everyone participates and discussion plays a key part in the game. Participant’s eyes are often opened to the complexity of backlog prioritisation. The game has been designed for all staff, not just Product Owners. The Extended Version of the game ramps up the challenge. It is aimed at Product Owners, yet suitable for anyone with a little more time to spare.


Weekend Escape a backlog management game



Learning objectives

  • Experience the challenges of prioritising and ordering a backlog.
  • Understand how an agile team can help their Product Owner by making the backlog items easier to compare.
  • Extended Version: Experience how business goals impact the approach to prioritisation


Suitability

  • People: 6 to 20. People will be split into an even number of teams of 3 to 5 people. 
  • Time for Standard version: ~30 minutes.
  • Time for Extended version: ~75 to 90 minutes.
  • Requires roughly 1m to 1.5m of table space per team.

The detailed instructions are available in PDF.


One example of a completed backlog, Weekend Escape, Backlog Management Game
One example of a completed backlog

I am interested to hear any feedback about the game, especially from those that have tried it out. So please leave your comments below...



Sunday, February 8, 2015

Lack of empowerment is making your project late

Projects become late one day at a time because small impediments occur and front line workers are not empowered to resolve those impediments on the spot. Those small impediments turn into day long or longer delays. Once that day is lost to delay it is near impossible to get it back. To reduce this we need to empower front line workers to immediately solve impediments and to exploit opportunities that present themselves. 



Opportunities are the flip side of impediments; each day our front line workers experience impediments and opportunities. It is how they approach those situations that determine the outcome of our project. On a daily basis opportunities to improve quality, deliver faster, boost morale and drive innovation arise. Is your team ready to take advantage of them? 

Waiting for input to solve an impediment increases the impact of that impediment and often increases the effort needed to resolve it. Waiting for input to take advantage of an opportunity diminishes the value of the opportunity and again can increase the effort needed to implement it. 

Our front line workers need the authority, information, tools and support to make empowered decisions quickly.

Examples of impediments leading to day long delays

  • Scrum Master waits for his Line Manager to approve the purchase a $30 license for a communication tool that allows the team to more easily work at home; instead of purchasing it out of his own money KNOWING that his Line Manager will support the decision, and pay the expense claim.
  • A Product Owner waits until the end of the Sprint before contacting another team to make a small change in their component because the process demands it.
  • An experienced team member feels that he must wait for the Tech Lead to return from the training course his is on before he can implement a framework change.
  • Anytime, anyone waits for test results overnight.



Link to Lean
All successful lean implementations incorporate an extremely strong idea generation and execution process that involves everyone. This empowers all staff and makes fast decision making an everyday occurrence. This is a prime example of empowering staff to drive success. For further reading: The Role of Front-Line Ideas in Lean Performance Improvement


Don't let your project become late one day at a time! Empower your people; so that they own and drive project success

Photo Credit: damn_unique

Monday, November 17, 2014

Multi team sprint planning

Scrum answers the question of how one team can effectively plan their work; however it does not address how multiple teams doing Scrum can effectively plan their work. What follows is a brief explanation of the multi-team sprint planning approach that I most recently implemented for a department containing six Scrum teams.

Multi team sprint planning scale many teams scrum agile


The short version

  1. Prior to the Joint Planning Meeting the project managers perform a preliminary allocation of Epics/User Stories to teams.
  2. In the Joint Planning Meeting, each team pulls in User Stories until they are full and posts those User Stories on the Joint Planning wall. The result is reviewed by all and updated as necessary.


The longer version


Prior to the Joint Planning Meeting
  • The Project Managers schedule the fortnightly Joint Planning meeting instead of fortnightly Sprint Planning Meetings. It is held in a room large enough to provide seating and tables all of the Scrum teams is necessary. It also needs additional seating for Project Managers, Product Owners, etc. Initially the meeting was booked for 4 hours, however over time this has reduced as the process became familiar to everyone.
  • The Project Managers work with senior staff from the Scrum teams to help them understand the rough size and scope of upcoming Epics/User Stories. This allows them to roughly allocate this work to the teams. So that going into the Joint Planning Meeting each team has a backlog of approximately 2 sprints worth of work that they can pull from. Overtime the teams have become more involved in this pre-allocation.
  • The Project Managers create the Joint Planning wall in the meeting room and post up the pre-allocated backlogs.


The Joint Planning Meeting

  1. Lead Project Manager, introduces the meeting, explaining any upcoming milestones, key events and/or themes for the coming sprint.
  2. Scrum teams work to pull in size, and split Epics/User Stories are normal. Their Product Owner sits with or near them. Team members are encouraged to talk to the PMs, POs, other teams, etc, as necessary. The amount of discussion varies significantly depending on how many teams are working together / depending on other teams. Once they have their Sprint Backlog prepared they post up the User Stories on the Joint Planning wall. It is up to the team to decide to split the User Stories into tasks prior to finalising their Sprint Backlog. Once the team has posted their Sprint Backlog they are free to go.
  3. At the agreed time, all teams come back to the Joint Planning wall to review and discuss the plan for the coming sprint. This is what is shown in the photo at the top of this article. During this discussion all kinds of changes may occur work dropped, work added, work swapped between teams, dependencies uncovered, impediments noted, impediments addressed. This is the crucial element of the Joint Planning meeting.



As with all agile practices this meeting continues to evolve and change. For example some teams found the large room too noisy to hold the discussions that worked for them, hence they stayed for the initial introduction then headed off to a private room to form their Sprint Backlog before returning for the sharing and discussion.