Communication during a transition

In summary it should be focused on what you hear not on what you say.


We recognised that communication with staff during an agile transition was important for two reasons; firstly so that the transition changes would be understood and accepted. Secondly and most importantly, so that issues and concerns from staff would be raised. We could only address concerns that we knew about so it was crucial that they were raised by the people who were feeling the impact of the changes.

Try as we might, deafening silence was the result of most of our communication approaches. 

While this blog post presents many communication approaches that failed to generate any feedback, overall the transition was a big success, with the results to prove it. The net positive survey response to ‘I am well informed about the agile transition’ rose from 70% to 84% and then to 90% over two years. However the ultimate indicator of success is that the vast majority of staff are really happy at work.

What I have taken away from all of this, is that communication should come from numerous channels and MUST be two way to be effective. It also brings to mind the Proverb "Listen to people twice as much as you speak." 

For those who are interested, the remainder of this blog explains the different approaches that we tried and a brief summary of the outcomes.

• Email feedback inbox – e-mails received in two years, zero.
• End of Transition Team sprint Email, explaining what we had done and are planning on doing. In there we linked to the feedback email address and mentioned that all of the Transition Team is open to being approached – feedback received, zero.
• Chocolates hidden behind links in the End of Transition Team email - we ended up eating the chocolates ourselves as no one found them.
• Directly telling people about chocolates hidden behind links – partial success, with some heavy hints, the chocolates were ‘found’ and handed out, excitement and interest created = zero.
• End of sprint Blog, explaining what we had done and are planning on doing - very few people subscribed to the blog.
• Transition Team members provided in person updates to teams after their stand ups – partial success, teams got the information and queried a few items; however where generally dis-interested and questioned why they get Management updates and Transition Team updates.
• Submit news to go in Management Update – un-tested by this time the Transition was wrapping up and only one news item was submitted, ‘the disbanding of the Transition Team’.
• Quarterly Staff speak ups – this generated a couple of questions but generally there was silence, at least they were there to hear the messages.
• Ask Transition team for concerns, who in turn asked Scrum Masters, who in turn asked team members – success, a reasonable number of concerns were raised. Many of these were turned into Transition Team User Stories.
• Surveys – ten questions one page, done via Survey Monkey, same survey three times over two years. Success: 80% of staff responded, plenty of meaningful and detailed feedback received. Many of these were turned into Transition Team User Stories.
• Rick Roll entire division in Transition Team farewell e-mail – good result, at least five people contacted me ;-)
• Scrum Masters discussing issues with their manager during regular 1 on 1s – success, plenty of issues where raised and then discussed by the Transition Team with several of these becoming Transition Team users stories and some guidance for stories already in progress or about to start.
• Division Manager holding Staff Forums with small cross functional cross team groups – a great success, staff really got stuck into providing direct and honest feedback. Some of this was related to the transition and other items were more general. This provided some Transition Team user stories and some guidance for stories already in progress or about to start.

Image Provided by: © Svidenovic | Dreamstime Stock Photos & Stock Free Images

Story Points are only one third of the reason for estimating

“One’s destination is never a place, but rather a new way of looking at things.”
From: Miller, H. (1957). Big Sur and the Oranges of Hieronymus Bosch

Assigning some Story Points to a User Story may seem like the point of agile estimation; however in my eyes it just signifies the end of the process. 

For me the goals of agile estimation are to build a shared understanding in the team of what the story is and to build team consensus around what the rough estimate in Story Points should be.

The journey that the team goes through to come up with the estimate, is more important than the number that is assigned at the end of the process. Sure the assigned estimate assists with planning, however the knowledge that the team gains during discussion will help with their understanding of what they are delivering, why and how they will go about it. I often hear discussions on topics such as: user needs, business value, design, potential new User Stories, testing approach, development approach, how this User Story fits into the Epic, which are all valuable.

Here is a brief summary of the benefits that the team gain by going through an agile estimation process.

Assigning Story Points to each User Story supports

• Grooming – identify stories that are large / candidates for splitting, identifying inefficiencies such as splitting an 8 pointer into two 5 pointers – should we do it as an 8 pointer to save overall time?
• Sprint planning – roughly creating a sprint backlog based on average velocity.
• Sprint planning – switching User Stories of equal Story Points in/out, up/down priority.
• Release planning – using the combination of average velocity and story points of remaining stories to provide a rough view of our status.

Discussions build a Shared Understanding, which supports

• Grooming – effective ways of splitting a User Story into multiple User Stories.
• User Story Planning – splitting user Stories into a set of tasks that will work for the whole team.
• Development – design ideas, implementation approach, testing approach, etc.
• Identifying issues – such as impediments, dependencies, etc.

Using consensus to arrive at the Story Points supports

• Sprint planning – with a stable average velocity and consensus on the Story Point of each User Story, there will be less second guessing of what to pull into the sprint.
• Commitment to delivering the Sprint Backlog – consensus around the estimate, leads the team owning the sprint commitment. i.e. “it was my estimate, so I will push to finish the story within the sprint”.

Interested in estimation?

• Fast Estimation
• Story Points do not equate to time
• Top Tips for Planning Poker

Iteration Manager to Iteration Leader

Scrum Master to Scrum Leader

Iteration Managers/Scrum Masters should not just be managing their team. They should be providing the team with leadership that helps them to achieve great things to together.

• Lead not by telling them.
• Lead by helping them to set clear and elevating goals.
• Lead by teaching an agile way of thinking.
• Lead by teaching them to think through the problems that you yourself contemplate.
• Lead by making them think for themselves.
• Lead by encouraging them all to be their best.
• Lead by example. I.e. exhibit the Scrum values. Be the change you want to see.

Self-organising doesn't mean they don't have an Iteration Manager, it means they can function without one. An Iteration Manager will always be there leading them onto a greater success then they could achieve by themselves. That is what great leaders do.

This article is available in presentation form on SlideShare: Iteration Manager to Iteration Leader.

Photo Credit: I was unable to find the owner of this photo. Please contact me if you own it.

Running a World Café

This is a brief summary of my experience of running a World Café.

I volunteered to run a World Café, themed around Organisational Impediments and how to solve them, for my local agile Meet-Up group ‘Brisbane Agile’*

I deliberately kept my preparation to a minimum. I held some discussions with the Meet-Up Organiser, regarding how we would run the event and set up the room. Apart from that I created a few wall charts to help smooth out proceedings and came up with some sample Organisational Impediments. These were a backup in case the participants were reluctant to volunteer their own items for discussion. This word document contains the wall charts I used.

We set up the room with five groups of tables that seated about six people each. Seating for thirty people was wishful thinking, by the start time we had two full tables. The low numbers were probably due to the event being event in the Christmas season.

While guests were entering and eating the free pizza, I wondered around introduced myself. Asking what had brought them here and suggesting that they post their question or topic on the provided wall charts. From member I think we ended up with eight topics being suggested by the participants.

After brief introductions from our sponsor and the meet-up organiser, I got everyone on their feet and used dot voting to select two of the eight suggested topics. There were a couple of clear winners, which made it easy to start the two tables discussing each topic.

As a group we decided as a group to drop down to ten minute discussion rounds. This allowed us to get through four topics in total.

I time boxed us to ten minutes of discussion, followed by a couple of minutes to switch tables and then another ten minutes of discussion. The conversations that occurred where very animated. It was a real struggle to stop them and get us on to the next round. After the first topics had been discussed by both groups we had the topic leader provide a quick overview which sparked even more discussion.

With roughly half of our planned time used up we used dot voting again to select another two topics and do it all again. Again we had very energetic discussions, which were constrained by the ten minute boundary.

The result was these sheets of butchers paper, which fail to convey the excitement and energy that was in the room.

Result: Agile Contract Models

Result: Introducing Agile into a large organisation

Result: What is more effective Scrum of Iterative Waterfall and Why?

Result: Agile estimation

We ended up with some very satisfied attendees. Some left with a much better understanding of agile, another walked away with an action plan for how he will sell agile to the management group in the company he has just joined. Everyone seemed to walk away happy.

I whole heartedly recommend you to run your own World Café; it is easy to set up, exciting and harness the energy of the participants.

*At the time of the World Café it was actually a separate group ‘Brisbane Scrum and Agile’ Group, however it has since merged with the ‘Brisbane Lean and Agile’ group to become ‘Brisbane Agile’.

Photo by: Travel Fools of America 

The Three Keys to splitting User Stories effectively

Splitting Epics into Features is hard, splitting Features into User Stories is hard and splitting User Stories into smaller User Stories is hard. Of course it is easy to do any of those steps poorly, but we are talking about making effective splits. Effective in that the team is able to efficiently work together to continuously deliver something of value to the Product Owner. Effective in that product risk and project risk is being addressed, while maintaining a clear picture of the team’s progress. Effective in that the splits eventually result in User Stories that the team can tackle in a sprint, i.e. each User Story adheres to most of the INVEST principles.

In my mind there are three keys to unlocking the door to effective splitting of User Stories.

Key One: Understanding

Understanding is a critical key in getting teams to effectively split up User Stories. I am talking about refers to the whole team understanding the Big Picture, Business Benefit and Design.

Understanding the Big Picture
How does this User Story relate to the Feature and the Feature to the Epic? This is important because it allows the team to know which things they can defer, and knowing what can be deferred opens up plenty of options for splitting User Stories. There is more discussion of deferring things in ‘Key: Thinking Vertical’. To achieve understanding of the Big Picture it is essential that the team is involved in splitting the Epic into smaller Product Backlog Items, early in the Release Planning process ideally as it the Epic is being split into Features. If the team was not involved in splitting up the Epic from the beginning, the Product Owner should make sure that the team is aware of the big picture, probably by describing the relationship between the features to the Epic.

Understand the Business Benefit
The team should understand the business benefit that the Feature should deliver and how that contributes to the business benefit of the Epic. Understanding of the business benefit helps the team to make smart choices about how to split up the Feature. I have found that teams who do not understand the business benefit can end up making choices that unintentionally diminish those benefits. For example they may reduce the amount of error validation that is done, thinking that it is good way of keeping costs down. However, when the business benefit centres around an awesome user experience bringing customers back, this is a poor choice. In this case the reduced error handling may upset some users and hence the business benefit is also reduced. 

Understand the Design
The design should be understood by all members of the team, at least at a high level. This does not necessitate a lot of design to exist, the important point is that everyone in the team can talk in a common language about the design choices they are making and of course how that relates to splitting up the User Stories. For example testers should be able to hold meaningful conversations with developers about testing impacts based on the design and its relationship to split of User Stories. Sharing a common understanding of the design allows all members of the team to contribute ideas for splitting User Stories, which leads to item four.

Whole team understanding
The whole team should have a shared understanding of the big picture, business benefit and design. This shared understanding ensures that everyone can be involved in splitting up the User Stories and doing so in a way that represents their concerns. i.e. Testers can ensure that the User Story is Testable. Whole team understanding also speeds up estimation and builds the team commitment to delivering the User Story.

Key Two: Thinking vertically

Waterfall development generally builds up the product layer by layer, or component by component, this is what I call the horizontal approach. 

Image 1: horizontal development, the blue items are units of work / poor User Stories

The downsides to his approach when used for agile development is that it builds up debt, unbalances the work amongst the team, deprives the team of early feedback, hides issues and hence hinders our ability to be agile.

The key to addressing the issues of horizontal approach; is to think vertically, to think about delivering vertical slices. Building vertical slices means that each User Story builds a piece of each layer of the product, the User Story must adhere to the Definition of Done and deliver some business value or be a solid step* towards that value. 

Image 2: vertical development, the blue items are units of work / User Stories

Usually the code that is delivered with each vertical slice is very small compared to what developers would have experienced with the horizontal approach. Some people struggle with this, as they feel that they are going slower than they have in the past. Of course this is true so it is important that we explain to them all of the benefits that come with this approach, such as:

• Finding issues early as hence fixing them for less cost
• Not building the bits that we thought we needed at the start but later find out we don’t need
• The ability to get fast feedback from our Product Owner, peers and customers
• Realistic reporting of our progress towards done
• Delivering value with each User Story, as opposed to delivering untested code

An important concept to get across to teams that are new to the vertical approach is; they can be ruthless about things that get deferred within the release time frame. Take the example of building a new GUI customer search for call centre operators that allows for complex ‘SQL like’ queries to be create, executed and stored. There is no way we would release it to our customers with poor performance, no error handling, a clunky user experience, or half of the fields missing. Yet all of those things are great items to split out as separate User Stories, provided they will be delivered within the Release Time-frame.

*While I agree that User Stories should deliver some business value (The V from INVEST), I have found that by splitting up User Stories so that they are small enough to fit into a Sprint there are often times that the business value is not clear. At the Feature and/or Epic level it is clear what the business value is, and the User Story is clearly contributing towards that, but the User Story itself does not deliver much/if any value.

Key Three: Experience in splitting User Stories

This is a classic catch 22, a bit of experience in splitting User Stories seems to make it much easier to split the next User Story and opens up the mind to new ways of splitting User Stories. This is where an Agile Coach can really help, by working with the team to split their first couple of User Stories hence breaking out of the catch 22. Another option is to run workshops on splitting User Stories that include practical exercises. The workshops that I have run are always well received and provide teams with that vital kick start to their experiences.

For most developers that are new to agile, the vast majority of their experiences regarding splitting up work has been in splitting it horizontally. It is a hard habit to break out of thinking this way, again this is where an Agile Coach is very helpful; to show them new ways of thinking. This can be accomplished with a few hints, some probing questions and pressure for the team to stick to the Definition of Done, while delivering an increment of value.

Additionally to support the team in thinking about different splitting approaches I like to provide them with cheat sheets and short articles that describe different splitting approaches. Here are some of my favourite articles and cheat sheets: 

• Twenty ways to split Stories by Bill Wake - One page cheat sheet and blog with detailed explanation.
• Patterns for Splitting User Stories by Richard Lawrence - another cheat sheet and blog with detailed explanation. 
• How you'll probably learn to split features by J. B. Rainsberger - explains the transition in thinking about splitting that occurs for many people.
• Story weight reduction kit by James Grenning.

Causal Loop Diagrams

Thank you to Renae and Shane who helped me to find the answers to why our teams were struggling to split up Features into small User Stories. We found the answers by drawing a Causal Loop diagram together, you can find out more about Causal Loop diagrams in the book The Fifth Discipline by Peter M. Senge. If you are stuck on a complex problem, I highly recommend that you grab a couple of peers and get them to help you draw a Causal Loop Diagram about the problem.

Image 3: A snap shot of the Causal Loop Diagram that inspired this blog post.

Photo of keys by: mmarchin  

The benefits of time

I recently learnt first-hand the benefit that time brings, by that I mean how time for people to think through ideas and try it for themselves is crucial to success.

Usually when I give advice to someone, I spend a fair bit of my own time thinking about how they are progressing and generally worrying about the situation. My recent experience has shown that by do that I am doing myself a disservice.

The experience was as follows; a couple of teams that I had been coaching were both in tough situations for different reasons which I will not go into. I gave both of their Scrum Masters a couple of pieces of advice regarding some practices to change. Normally this is where I would have spent the coming days stressing about their progress and thinking of contingency plans. However some rather big impacts occurred in my personal life and work was the last thing on my mind. When I returned to work, I was surprised to find that both teams had achieved solid success with the suggested changes, all with no stressing on my behalf. I should not have been surprised; these were two very capable teams lead by intelligent and effective Scrum Masters.

What I took away from this event was that I need to allow more time for people to think about and trial new ideas before I check back in with them. In the mean time I can find other people and teams that I can help.

As a personal mantra: Plant the seed, don’t stress, just sit back and wait.

Photo by: Earls37a

Top tips for Retrospectives

Tip: Change ‘Five Whys?’ to ‘Five What Caused that?’

“No problem can be solved from the same level of consciousness that created it.” Albert Einstein 

This quote is one of the many reasons why I am a big advocate of using the Five Whys techniques in Retrospectives. My experience shows me that finding and then fixing the root cause has a much longer lasting effect then fixing the reported problem (aka symptom). While the Five Whys technique is great; there a little twist that can make it even more effective for new teams.

Teams are new to Retrospectives find it a big challenge to raise issues that they are used to ignoring or hiding. Creating an environment where they feel safe to bring up issues is critically important for the success of the Retrospective.

‘Why’ is a word that puts people into a defensive state of mind.  As it focuses the respondent on their own involvement in the issue and hence, they are inclined to play down the issue for fear of making themselves look bad. Hence I prefer to phrase the Five Whys as the Five ‘What caused that?’ Using the word ‘what’ takes the focus off the respondent and lets them look at the issues that caused the symptom. This allows them to stay in a problem solving state of mind as opposed to a defensive state of mind. 

Lastly when looking at a tough problem, writing up the Five ‘What caused that’ items on a whiteboard as the team discusses the issue helps to give the discussion focus.

Tip: Validate the input of all attendees

One of the most effective techniques for creating a safe environment in Retrospectives is a simple one; validate the input of all attendees, especially the quiet people. What I do to validate their input is summarised in these points:

• Validate each idea that is raised by either reading the idea aloud or repeat back the idea that was raised verbally.
• Treat all people and ideas equally (even if I strongly disagree)
• Keep the Retrospective to one conversation at a time so that everyone is involved in all of the discussions.
• Specifically ask quiet people what they think about issues under discussion.
• Support quiet people to get their ideas across when they do voluntarily speak up.

Tip: Prioritise and cluster

The Retrospective format that I most often use is ‘Puzzle, Problem, Try, Keep’ from Agile Retrospectives by Esther Derby and Diana Larsen.

Starting the Retrospective with five minutes for participants to write up their thoughts onto Post-it notes in silence is a method that allows everyone to provide their own unique input without being influenced by other participants. I suggest one thought per Post-It note, as it makes arranging and discussing each thought much easier. You can stick the Post-Its notes into the Puzzle column to begin with and it is usually a good idea to cluster similar thoughts.

Image 1: The teams ideas clustered in the Puzzle column by theme

With the initial thoughts clustered into the Puzzle column any important issues will stand out as a big clump. If you have lots of separate thoughts, it will be worth asking the team if there are any burning issues before proceeding. 

With the large clusters and burning issues identified you now have a set of thoughts to address first.

Tip: Use a workflow

I see the ‘Puzzle, Problem, Try, Keep’ Retrospective as a workflow. Thoughts start out as Puzzles and either stay there or move to be a Problem. Problems link to Tries. Tries from previous Retrospectives were either successful and hence become a Keep, or need to be re-tried or are dropped. In general this results in a left to right workflow.

After gathering the Thoughts of the participants into the Puzzle column it is always worthwhile discussing the Tries from the previous Retrospective. Was the Try successful and hence should become a Keep. Did the Try have issues that we think we can overcome; hence it stays as a Try. Is it an abject failure, hence dropping off all together? Discussing previous tries shows the team that Retrospectives are for delivering outcomes not just suggesting Tries that are never followed up on.

Image 2: The Try's from last Retrospective being reviewed and placed accordingly.


Now it is finally time to address the new thoughts. I suggest discussing each thought in turn.

For puzzles and problems, use the ‘Five What Caused That?’ approach to identify the root cause, aka Problem. Once it is clear that you have a Problem move the Post-It to the Problem column and list the root cause.

Image 3: Put the top priority discussion topic into the Problem column and noting its root causes.


With a Problem in the Problem column that is well understood and it has a root cause identified it is time for the team to recommend one or more Tries. These are written in the Try column and you should draw arrows from the Problem to the matching Tries. The arrows represent cause and effect, ensuring that we put effort into Tries that will have some lasting impact.

Image 4: Linking the Problem to its Try's.

For thoughts about things that went well, or items you should keep; be sure to discuss with the team why it was successful and how we can ensure it will be successful again in the future.

Tip: Find the Problem that Tries are attempting to solve

Often participant’s thoughts will be suggestions for Tries, e.g. ‘Run the tests in parallel’, or ‘Use Gradle for our build process’. In this case it is very important to understand what Problem they are attempting to solve before just adding the Post-It note to the Try column. You can use the ‘Five What Caused That?’ approach to ensure that you attempting to solve the root cause.

Image 5: What the board could look like at the end of a Retrospective.

Tip: Make sure Tries are turned into action

I have seen several teams that where good at coming up with Tries, yet were poor at acting on those tries; hence they did not improve as fast as they could have. The reasons for the lack of action were many and varied. Here are a few of things that I have found to help teams follow through on their Tries. They can be used in isolation or in combination.

• Assign a single person as an Owner of each Try during the Retrospective.
• Display the list of Tries near the teams Task board.
• Create a Task cards for each Try and put it on the Task board.
• Discuss the progress of each Try during Daily Stand ups.

Interested in more tips?

• Top Tips for Planning Poker
• Top Tips for Project Retrospectives