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

Fast Estimation

Imagine you have just completed some Product Discovery work and have a pile of User Stories that need to be estimated. You look at the pile and think, wow that will take hours to estimate using Planning Poker. I just want rough estimates so that we can put together a release plan. We know the plan will change in the future, but we need some starting point. What can I do? 

The answer is Fast Estimation. 

Fast Estimation is derived from Planning Poker. With some preparation and a 1 hour workshop it is common for a team to estimate about 30 User Stories. Teams I have worked with have successfully used it to estimate new functionality, automation of processes, improvements to internal practices and organisational change work.

While estimation is the main objective of the Fast Estimation process, another significant benefit you get for free is Shared Understanding. By this I mean the discussions that occur help to clarify in the minds of the team members what work is required, how it inter-relates and how big the entire backlog is. The knowledge that is gained about the backlog as a whole can often be more valuable then the estimates assigned to individual User Stories.

Fast Estimation Process

Preparation
Write out the User Stories to be estimated onto Index Cards of the same colour. A short cut that often works well is to just write the Title of the User Story on the index card and have the details of the User Story on hand during the session (i.e. in an electronic tool, or a printed spreadsheet, etc).

Find one to five Reference User Stories. These are User Stories that are well understood by the team and will act as a reference point for the upcoming comparative estimation. Ideally the team will have recently completed those User Stories or have at least estimated them in Story Points. The Reference User Stories should have differing Story Points, ideally being in the 2 to 20 range. I recommend at least three reference User Stories and usually aim for five, however you can get away with one. The case where your team is new and does not have any reference User Stories; sounds like a topic for another day. If you are really stuck just pick a User Story that you think is 3 Story Points, and use that for your Reference User Story.

Write out the Reference User Stories onto Index Cards of a different colour to the cards used for the User Stories to be estimated.

Schedule a 1 hour meeting in a room that has a long table, big enough for the team to gather around.

During the workshop
Set the scene for the workshop by explaining the following points

• The objective of the workshop is to roughly estimate this stack of User Stories (show them the stack of Index Cards so that they can see how many there are), this will help to emphasise that time is of the essence. 
• Fast Estimation will only rough estimates for these User Stories. 
• There will be lots of assumptions and hence the estimates will not be very accurate.
• The team will get another chance to re-estimate these User Stories in normal grooming session prior to starting work on the User Stories.

Layout one set up Planning Poker cards on a long conference table in ascending order i.e. 0, 0.5 .. 110, ∞.  It is a good idea to leave more space between the lower / middle numbers as hopefully more of the User Stories will end up there. If there are lots of User Stories at the large end of the scale that is a whole different problem, good luck with that ;).

Place the Reference User Stories below the Planning Poker card that corresponds to its Story Points. As per the picture below.

Picture 1: Planning Poker cards and Reference User Stories, with un-estimated User Stories at the bottom.

Confirm with the participants that they understand the Reference User Stories and agree with the Story Points for each. You may need to adjust one or more of these. Once you progress past this point, do not change the Reference User Story – Story Points any more these are now set in stone.

Divide up the User Stories roughly and hand them out to the participants.

Give the participants a couple of minutes to quickly read their set of User Stories to themselves.

Pick someone at random and ask them to read out their User Story and then place it underneath the Planning Poker card that corresponds to their estimate. Only allow a brief time for this. Ask the group if they are happy with that estimate and discuss/move it as necessary. Encourage participants to move the card if they disagree and to explain their justification at the same time.

Picture 2: First User Story Estimated

Ask the group if there are any similar User Stories in peoples stacks. If so, repeat step 8 for those User Stories. Once there are no more similar User Stories pick another person at random and repeat step 8 for that User Story.

Work your wait through all of the User Stories, placing and discussing, finding similar User Stories, etc. etc.

Once all of the cards are all in position you can quickly write the Story Point estimate on each Index Card and gather them up.

Picture 3: All User Stories estimated 

As a final wrap up to the meeting it is again worth mentioning that the team may need to re-estimate these User Stories using Planning Poker before taking them into a sprint planning meeting.

A variation I have tried that did not work as well
After handing out the index cards, everyone places their cards at once in a big rush of activity. Then the team discusses them and re-estimates them as appropriate. This approach raises the energy in the room but it is a bit more confusing. Individuals will find it confusing to place their cards without the understanding of the backlog that they build up while discussing the User Stories one by one. The benefit to this approach is that very rough estimates are assigned to all of the User Stories up front, so if you run out of time at least you have everything estimated.

Teaching Fast Estimation
I have an example game to teach people Fast Estimation which extends on the fruit estimation of Planning Poker that I learnt in the Certified Scrum Master course taught by Rowan Bunning.

Write out the following Items To Cook on Index Cards, and place ‘B.L.T’ your three Story Point Reference User Story  (I have found that due to the simplicity of these User Stories 1 reference story is enough). 

Ask the participant to estimate cooking these items from scratch. I.e. for Eggs Benedict they are expected to make their own hollandaise sauce. Guide them through the Fast Estimation process,  this game usually takes less then 10 minutes (provided the participants are familiar with Planning Poker and Story Points).

Items to Cook

• Eggs Benedict
• Tin Baked Beans
• Fruit Salad
• B.L.T.
• Crispy skinned Salmon
• Poached Eggs Soufflé
• Cheese Burger
• 64 Cup Cakes
• Garden Salad
• Alacarte, 3 courses for two
• Cheese Cake
• Duck Ala orange
• Caesar Salad
• Alacarte, 3 courses for ten
• Lasagne
• Pineapple upside down cake
• Burrito’s
• Mashed Potato
• Beef Korma
• Banoffee Pie
• Fish & Chips
• 12 Fancy cup cakes

Interested in estimation?

• Story Points are only one third of the reason to estimate
• Story Points do not equate to time
• Top Tips for Planning Poker

Related Reading
I can recommend these blogs for other great approaches to estimating stacks of User Stories:

• Steve Bockman - Team Estimation Game 
• James Grenning - Planning Poker Party 

Training available in South East QLD, Australia

If this article was interesting to you, then your team would likely benefit from face to face training on Agile Estimation. I run a one-hour Agile Estimation training session, that is highly interactive, immensely fun and teaches the foundation of agile estimation along with how to effectively run Planning Poker as well as Fast Estimation. Please contact me to set up a training session for your team: andrewrusling@hotmail.com

Book Review: Presentation Zen - Simple Ideas on Presentation Design and Delivery, by Garr Reynolds

Visually it is a beautiful book that shows off Garr Reynolds design skills.

If you like discussing design and the art behind it, then this book is for you. It does a good job of discussing the design of presentations from an abstract approach, the writing style of his blog Presentation Zen shines through.

However if you want to improve your presentations this book offers very little. The useful information in the book could be condensed to about 20 pages; you may be better off searching the web for articles on basic design principles.

I picked it up hoping to improve my presentations, I walk away knowing about a few more free picture sites, having seen some great examples of slides and learn a few tips. Unfortunately the Zen of presentation design has not passed into my way thinking.

2 stars

Photo by Wesley Fryer