Why agile teams should not use an electronic task board

I often hear people expressing interest in moving to an electronic task board. This always concerns me. I see so many benefits in physical boards and only a few benefits in electronic boards. Until recently I had struggled to explain to people why they should go for physical over electronic. 

Now with thanks to Allan Kelly (who presented at Agile Tour London), I can articulate why it is so important to stick with a physical board. 

Teams should work collaboratively to create and design their own physical task board; because this creates significant buy-in to actually using the board on a regular basis. The act of deciding how the board will look / operate is much more interactive when done physically. This creates a stronger sense of ownership for the board and hence increased buy in.

As an aside; if you are working in a distributed way, go ahead move to an electronic task board. For me this is where electronic task boards shine. However if you are working in a co-located team (and I hope you are), you should go for a simple physical task board. 

The diversity that can be achieved via a physical board continues to astound me. To gain some appreciate for this please head over to Agile Board Hacks.

Other reasons to stick with physical boards are that it is often very difficult to use these powerful annotations on an electronic task board:

1. Pairing estimates. E.g. ‘Extract user details from the request (8h x 2)’, meaning two people will pair on this task, spending 8 hours each for a total estimate of 16 hours.
2. Action plus Review on one card. E.g. ‘Extract user details from the request (18 + 3)’, meaning 1 person will spend 18 hours developing the functionality, and then there will be 3 hours for someone else to review it and the first person to correct any issues.

Scrum Roles and Responsibilities Game

I have recently posted my first game to TastyCupCakes.org, the Scrum Roles and Responsibilities game.

This is a game that I have used many, many in my Scrum training courses. I have found it is a great way to help trainees understand the differences between the Scrum roles and importantly what each role should be focusing on.

The physical interaction and discussion elements encourage everyone to participate and really helps to make the lessons learnt stick in the students brains. 

The format of that game can also be easily reused to teach other topics. Such as what is included in our different Definitions of Done (Release, Feature, User Story). 

Top tips for Planning Poker

Planning Poker is a simple exercise that delivers outstanding results when performed well. It can quickly lead the team to a shared understanding of the work and an accurate estimate of the size of the work. However I often see it performed sub optimally, leading to waste, inaccurate estimates, misunderstanding and division within the team.

These are my Top Tips for performing Planning Poker in an efficient, effective and fun manner.

Bring Reference Stories

Bring a range of Reference User Stories on index cards to your estimation session. I find that a range of sizes and types of work helps immensely when we are sizing. I recommend that you have between 3 to 10 Reference Stories, in the size range of 1 Story Points to 8 or even 13 Story Points. The reference story index cards can just have the story title written on them (provided the team is well aware of what the story entails).

Bringing these reference stories serves two purposes. 1. There is no need to recall the Reference Stories from memory, they are right there in front of you. This makes the process of sizing stories easier and faster. 2. It stops ‘size creep’ / ‘story point inflation’, which unintentionally affects some teams.

Involve Everyone

Everyone should display an estimate each round. We do not want the situation where Developers put out a ‘?’ card each time there is a testing focused story and vis-versa.

But how can Testers size Development work you ask? By using Relative Estimation along with asking some probing questions, is the answer. The questions that we need to train the team members to ask, highlight the differences of the Un-sized Story to the Reference Stories. 

Some sample probing questions:

• Testers can ask: How many components does it affect? How many components were affected in the reference story?
• Testers can ask: How much development work is there per component, compared to this reference story? 
• Developers can ask: Do we need to test it on multiple platforms, like we did for this reference story?
• Developers can ask: Are there more functional areas to tests than this reference story?

With this information out on the table, everyone should have enough information to compare the Un-sized Story to the Reference Stories and hence select a Relative Estimate. This is one the key reasons that Planning Poker works in a cross functional team.

Talk about Complexity, Effort & Doubt

Story Points are made up of complexity, effort,& doubt, with Complexity being the most important aspect. Everyone in the team needs to understands what these all mean and how it relates to their work.

Talk about:

• More/less complexity (more interactions between components, technical debt that makes it harder to make changes, difficult algorithms, availability of assistance from an expert in the area, availability of documentation that explains how it all works, etc.)
• More/less effort (extra tasks, extra components to work on, less test cases to create, ability to reuse existing work, available of a tool that automates part of the work, etc.)
• More/less doubt (lack of tests, uncertainty regarding the current design, unclear expectations from the Product Owner, new technology, not sure if the documentation covers it, etc.)

Don’t talk about numbers

Don’t let team members talk about changing your estimate. E.g.  'I will go down to a 5.' 'Ok, ok it's a 2.', ‘Alright I’ll go up’.

This results in or is the result of peer pressure. ‘Story Points are only one third of the reason for estimating’, peer pressure prevents the team from gaining the other two thirds worth of benefits. 

Also try to avoid talking about how much time it will take to do things. ‘Story Points do not equate to Time’, so we should minimise our mention of time.

Instead of talking about numbers, get the team to focus on Effort, Complexity & Doubt, and then re-vote.

Choose the Majority answer

Create a team rule that ‘When there is a lack of consistency in estimates after two rounds of estimation; the estimate which the majority of team members have chosen is selected as the estimate.’ 

Picking the majority answer instead of picking the highest answer (or the lowest) ensures that the team’s estimates will average out over the long term. Always picking the highest estimate will inflate the team’s estimates, and lead to less predictability.

In the above example, with 4 votes to 3 votes, the team would choose 5 as their estimate.

Use estimation to confirm shared understanding

Watch out for stalled/circular discussions and call for the team to estimate. 

Sometimes you will find that the team all throws out the same estimate! When they do you can move on. Even though the conversation was going around in circles the team had a similar idea of the size of the work. Which means you can sort out the details in the sprint, instead of trying to sort it out in your estimation session.

If some team members do throw out different estimates; then you need to head back to the discussion to try and clear it up. The good news is that the attempt at sizing will have only taken a minute or so.

Combined result

Once you and your team are practiced in how to run an effective Planning Poker session; it should be fast, accurate and fun.

Do you have any other tips that have lead your team towards great Planning Poker sessions?

Interested in more tips?

• Top Tips for Retrospectives
• Top Tips for Project Retrospectives

Interested in estimation?

• Fast Estimation
• Story Points are only one third of the reason to estimate
• Story Points do not equate to time

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

Top Tips for Project Retrospectives

Project Retrospectives tend to be high stakes, emotionally charged, cross teams events, with managers in attendance. This all adds up to an environment that is not ‘Safe to Fail’ as you would expect in a typical Sprint Retrospective. While my Top Tips for Sprint Retrospectives can still be applied to Project Retrospectives; the several significant differences between these Retrospectives, means a different style of approach is needed.

Project Retrospectives are useful when a project spans multiple teams and multiple sprints. During the project I would expect that each team would hold a Sprint Retrospective every Sprint. The Project Retrospective is an additional ceremony that occurs after the project is completed. This could also apply to Release Retrospectives, i.e. a Retrospective for all of the agile teams involved in a multiple sprint release.

What follows are my top tips for running a successful Project Retrospective. i.e. A Retrospective that allows the real issues to be identified and action taken to resolve them.

Tip: Choose the attendees wisely

The attendees that you invite will have a significant bearing on the issues that are identified and importantly on how successfully those issues will be addressed. I recommend you invite:
• Representatives from all teams involved in the project.
• Representatives from all disciplines involved in the project (e.g. product owner, leaders, project managers, business analysts, developers, testers, designers, architects, support). 
• People who will speak honestly in front of management.
• Stakeholders/Management that will hear the issues first hand; then be available to own and resolve those issues. This is crucial to a Retrospective leading to real change.
• As few people as possible, certainly less then 15. To help with this mix up the discipline you invite from the separate agile teams. e.g. Developer from one team, tester from another, business analyst from a third.

Tip: Get all attendees to prepare ahead of the meeting 

About a week ahead of the Retrospective, hand out post it notes to all attendees and ask them to pre-write their thoughts: what went well, what went poorly, what can we improve? This will save a lot of time in the meeting.

You can also get prepared yourself. I recommend researching a timeline of important events from the life of the project (e.g. Customer signs contract, First Release, huge technical issue first identified, original targeted delivery date that was missed, Final Release). Just prior to the start of the meeting you can draw up this timeline on the whiteboard.

Also just prior to the start of the meeting you can write the objective of the meeting up on the whiteboard. Such as ‘Objective: Assign Owners to the Key Issues we identify.’  This will prove useful when discussions in the meeting start to get off track. You can point to the written objective and ask if the current discussion is helping us to achieve our goal?

Tip: Schedule it promptly after the Project ends

Timing is crucial. It should not be immediately after the project ends, because some peoples feelings will be raw. It should definitely be within one month of the project end, so that it is still fresh enough in everyone’s memory.

Tip: Use a structured yet simple agenda

The agenda that I recommend is:
• Facilitator provide an introduction [1 minute]
• Gain shared acceptance of the meeting objective [2 minutes]
• Attendees to post their ideas on the timeline & cluster them as appropriate [5 minutes]
• Facilitator lead discussion of the clusters in priority order (large clusters first) [75 minutes]
• Facilitator summarise the issues and owners [5 minutes]

Tip: Focus the meeting on assigning owners to the key issues

While facilitating the meeting you should try to focus the discussions on 
• Bringing out the issues; and moving towards the root cause. 
• Agreeing which issues are the priority issues to be addressed.
• Getting agreement on who in the room should own each issue and hence resolve it.

Tip: Follow up after the meeting

Send the list of agreed issues & agreed owners to all of the attendees. You may want to consider posting this in a public location such as a Wiki.

The real key is regularly following up the owner of each issue. You need to ensure that they are working on resolving the issues. Otherwise the whole exercise will have been an expensive whinge-fest. 

Retrospectives are meant to lead to Real Change, you can make it happen.

Interested in more tips?

• Top Tips for Planning Poker
• Top Tips for Retrospectives

Photo by: Rafael Anderson Gonzales Mendoza  

Flexible Agile Coaches have a greater impact

A.k.a. How separating implementation from outcome can lead to better results

Flexible Agile Coaches, Scrum Masters and Change Agents have a greater impact. Flexibility in how their goals are achieved; allows them to deliver more changes and more effective changes. Overall this results in them having a greater impact. They do this by separating the ‘what’ from the ‘how’ and focusing on ‘what’ they want to achieve not 'how' they want to achieve it. This flexibility allows the Agile Coach to move around obstacles to change, instead of having to remove the obstacle. 

I.e. having permanent monitors on the walls displaying a live stream of production metrics, office news, etc is great for increasing information dissemination. However an increase in information dissemination could be achieved via numerous other means: face to face updates from leadership team, simple prints outs updated every day, e-mails, news page on the wiki; RSS feeds etc. 

It is easier to implement a change when you are not wedded to how you want to achieve your goal. I have found that ‘letting go’ of my chosen approach leads to better results. 

The implementations that are not mine; come from talking to the stakeholders about the goal. The stakeholders regularly suggest alternative approaches that still lead towards the goal. The important difference is that they feel ownership over the alternative approach. This ownership builds acceptance and stickiness of the approach; which provides a great foundation for future changes.

What can you do?

Once you decide what you would like to change; work backwards to figure out what your goal is. Think about what benefits you expect to come from applying the change. This will lead you to your real goal.

e.g. You have heard that test first approaches are beneficial. You would like your teams to start using Test First for all of their development. So Test First is your ‘How’. 

Now it is time to find out the ‘What’. Think about the benefits of implementing Test First. Perhaps you could read some blogs to find this out. Your thought and research leads you to consider the benefits as (builds shared understanding, improves code quality, reduce waste by building just enough software to make the tests pass). From there you believe that Improving Code Quality is the benefit that you are primarily interested in. That means that ‘Improving Code Quality’ is your true goal.

With your goal identified, your focus should move to achieving the goal; not necessarily implementing your suggested approach. Work indirectly towards your goal. If barriers pop up don’t try to steam roll them, instead change direction slightly while still heading towards your goal.

e.g. Test First is receiving a lot of push back. However in your discussions regarding Test First, several people indicated that they would be accepting of using Code Reviews. Make use of their interest in Code Reviews. Help them to implement code reviews and reap the benefits that come from Code Reviews. Achieving some success via code reviews is more useful than fighting tooth and nails to implement test first straight away. Through this process you will have built up some trust with your stakeholders and should be in a good place to help them with their next move towards Improved Code Quality.

Examples of Goals with different approaches

Improve ownership of the product

• Encourage and support staff adding User Stories to the backlog.
• Inform staff that management expects them to take ownership of their product.
• Encourage Product Owners to ask for input from their team when creating User Stories. 

Improve code quality

• Enforce code reviews
• Implement test driven development
• Tighten the coding standards
• Promote collaboration between coders and testers.

Fewer interruptions for Stand Ups

• Ask people to walk around stand ups
• Stagger stand ups so that they do not block the corridor at the same time.

Increase reliability of team delivering their sprint commitments

• Ask teams to commit to less stories each sprint
• Management to put pressure on teams to deliver their sprint commitments
• Ask teams to hold Backlog Refinement meetings

Trying it out for yourself

Please think about separating your ‘What’ from your ‘How’, next time you make a change. Let me know how it goes for you.

Story Points do not equate to Time

A.k.a. Story Points allow us to separate Estimation from Commitment

I have known (through experience) for a long time that Story Points are a great way for teams to estimate their work. However it has taken me a long time to come up with an explanation that can convey what I already knew. If you are interested in that explanation, then please read on.

Story Points vs. Ideal Days

Story Points are an estimate of the Size of the Story. Where Size is the combination of Complexity, Effort & Doubt:

• Complexity – Difficulty, hard algorithms, complex logic extra, abstract concepts.
• Effort – Raw effort / grunt work. I.e. Making a simple parameter change to hundreds of similar method calls.
• Doubt – Uncertainty around how will we build it or what it is that we need to build.

Ideal Days or Ideal Hours is an estimate of how long it will take to complete the Story.

So while Story Points are made up of a single element: ‘Size’, Ideal Days are made up of two elements:  ‘Duration’ and ‘Size’.

Story Points cannot be equated to Ideal Days/Hours because they are made of different elements. i.e. Size vs. Duration & Size.

Here is an example that illustrates my point

Story A is estimated by the team to be 1 Story Point. Story B is estimated by the team to be 8 Story Points. Suppose that we get our two brand new graduates to work on Story A, while our two experienced Senior Developers work on Story B. Story A is completed in 5 working days, Story B is also completed in 5 days. Now suppose that we had given Story B to our new
 graduates, while our experienced Senior Developers worked on Story A. In this scenario Story A is completed in 1 day, while our graduates will struggle on eventually delivering Story B after 30 days! While the Size of the Story remained the same the Duration to complete them varied dramatically based on who worked on the Story.

Estimation vs. Commitment

We use Story Points because it allows the team to focus on estimating one element; the Size of the Story. When sizing the Story we do not have to consider Who will work on it, or consider Committing to the Story.

During Sprint Planning we decide which Stories to Commit to the Sprint Backlog. This is where the team considers who will work on which story; hence combing the elements of Size, Who & Duration.

Estimating in Story Points allows for Estimation and Commitment to be separated, giving better results for each.

Please give it a try, and let me know how it turns out for you.

Interested in estimation?

• Fast Estimation
• Story Points are only one third of the reason to estimate
• Top Tips for Planning Poker

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

What is it, to be an Agile Coach?

I am ...

a teacher - providing people with new knowledge.

a trainer - running people through exercises and giving them feedback, so they can improve their skills.

a networker - connecting people so that they can help each other.

a mentor - encouraging people to grow and improve.

a facilitator - organising events/ceremonies/meetings ensuring they deliver results while involving everyone.

a coach - helping people to grow, through thinking differently/ thinking about new things.

an agent of change - working tirelessly to improve how people, teams and companies operate.

a councilor - really listening to people as they talk through their concerns.

a supporter - helping people through tough times.

a student - always learning from others, reading, listening, observing.

a scientist - running experiments and sharing what I learn.

a statistician - gathering data, analysing that data, and sharing my thoughts. 

a historian - recording and explaining the history of projects and teams, both successful and unsuccessful.

an author - writing my blog for others to read.

an orator - speaking in a language that my audience can clearly understand. 

an evangelist - shouting out loud and proud about what I believe in.

a leader - providing direction to those who call for it.

a team member - mostly working with others to achieve my goals.

an agile coaching - helping people, teams and companies, to make their work life more fulfilling, enjoyable, effective and efficient.

Are you like me? What can we learn from each other?

Photo Credit: Phil W Shirley