Monday, October 28, 2013

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).


Reference user stories

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.


Example voting results, showing to choose the majority, not to average the results
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?


Interested in estimation?



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



Saturday, October 19, 2013

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?





Photo by: Rafael Anderson Gonzales Mendoza  

Sunday, September 8, 2013

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. 


Going around an obstruction


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.

Friday, July 12, 2013

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


Example user stories with size


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?



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

Sunday, June 16, 2013

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.

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


Sunday, May 26, 2013

Agile Development with debt ridden code

Is your code base as messy as this kitchen?



If it is, I am sure it will be slowing you down. Working on technical debt ridden code is very hard to do in an agile way.

This is because the debt: 

  • Limits our ability to easily cut scope to meet our deadlines. (Caused by Coupling)
  • Makes it hard to split the work into small user stories. (Caused by Coupling)
  • Makes it hard to predict when we will be done. (Caused by lack of tests, coupling, defects, unexpected side effects)
  • Limits our ability to work fast, while maintaining high quality (Caused by all types of debt, especially debt with the tests)

Technical Debt that impacts our ability to delivery consistently:

  • Tight coupling
  • Design that limits extensibility
  • Inconsistent design
  • Inconsistent coding style
  • Existing defects, especially hidden/unknown defects.
  • Lack of automated tests
  • Unpredictable/ inconsistent test results 
  • Slow tests 

Recommendation One: Focus on Fast, Reliable Automated Test Results

The aims are to improving the quality & scope of our test suite, along with obtaining faster feedback. Fast, reliable feedback allows the team to work towards their sprint goals in small controlled steps and this improves reliability of delivery. 

Here are my specific tips to achieve these aims:

  • Run the test suite more often. Once a day is rarely fast enough, aim for at least three test suite runs during working hours, more is even better.
  • Increase granularity of reporting; ensure that all tests report their results separately. Watch out for 1 test failing that stops several other tests from running; this results in secondary defects being hidden until the defect causing the first test to fail is resolved.
  • Split up the test suite into separate tests or test groups; run them in parallel on separate environments. You may need to acquire more environments. This does a couple of things; it removes dependencies within the test suite which will likely identify some hidden defects. Secondly it will greatly reduce the overall duration of the test suite resulting in faster feedback.
  • Get faster hardware to run the tests on, resulting in faster feedback.
  • Add more environments, with at least one environment per team; giving flexibility of when/who runs the tests, resulting in faster feedback.
  • Set standards of how tests and test suites are structured. Ensure all new tests are developed to the standard and any exist tests that are ‘touched’ are updated to the new standard. Over time this will improve the quality of the entire test suite.
  • Improve the reliability of the test suite by identifying and removing intermittent tests. Refer to Martin Fowlers excellent article on Non Determinism in Tests for specific approaches to removing intermittent failures.  Also run the test suite on isolated hardware to remove outside influences. 
  • If your tests are running over night, identify regular IT maintenance work that could be impacting on your test results. For example database backups that greatly reduce the speed of the database.
  • Enforce that all new development work has automated tests that cover that work. This is not just for new features/components. Any work on existing code must have tests added, if there are no tests for that area of the code, they may have a substantial piece of work to do. However it does not take long for the extra effort to start paying dividends.

Recommendation Two: Incrementally attack the debt

Fast, reliable feedback allows the team to engage in effective refactoring.  This in time allows them to reduce coupling with their code and also reduce other types of technical debt, which further increases their reliability of delivery. 

With our Fast, Reliable Test Suite in place it is now time to start attacking the debt:
  • Revise the existing Coding standards with a focus on decoupling and consistency. Ensure all new code is developed to the standard and any exist code that is ‘touched’ is updated to the new standard.
  • With each new piece of work that the team is about to start, get them to think about technical debt that is related to this work. Investigate the debt, make it visible, do a cost benefit analysis for the reduction of that debt and involve the Product Owner.


Do you have any other tips for working in these difficult situations?

Photo Credit: independentman    

Monday, May 20, 2013

Transforming the Scrum of Scrums and Delegating Release Co-ordination


“The agile manager’s scariest move; handing over responsibility”

Once we* had our Delivery Teams regularly delivering increments of valuable working software; the management team made the tough call of pushing the responsibility for co-ordination of releases to the Delivery Teams. This blog post follows this decision through its successes and failures and explains how we adapted to the feedback we received and issues that we identified.

*The Royal we: Management Team, Transformation Team, and Coaching Staff.

Attempt 1 – Complete freedom

A meeting was arranged by the management team to announced to the Scrum Masters (and a few other stakeholders) that as part of the ongoing transition the Scrum Masters must step up and take ownership and responsible for co-ordinating our quarterly releases. After this meeting the management team deliberately sat back and let the Scrum Masters sort it out themselves.

The Scrum Masters held a brief meeting to decide how they would handle the situation. They quickly selected two Scrum Masters to lead the co-ordination effort. One of them took the lead and did a great job of co-ordinating the release, which went out on time and to the quality we had aimed for. There was plenty of room for improvement but no major disasters.  

While the Scrum Masters were comfortable with this change, the management team quickly lost visibility of any issues that were occurring and at the same time were getting feedback from many staff members about a lack of communication between the Delivery Teams.

Another couple of issues popped up, which told us another approach was needed for the next release: 
  1. The Scrum Master who lead the co-ordination of the previous release was promoted into the management team. 
  2. The other Scrum Master who had been involved was currently swamped with practice improvement work. We were not sure who would step up to the take the reins.


Attempt 2 – PMO established Scrum of Scrums

With issues around lack of visibility, low communication between teams and concerns about how repeatable our previous success was, the management team decided that they needed to act.

At this point in time the culture had moved from ‘responsibilities being assigned to individuals’ towards ‘responsibilities being assigned to teams’. Looking at our current issues the decision was made by the management team to rotate the responsibility for Release Co-ordination between Delivery Teams each release, along with establishing a Scrum of Scrums as a status reporting, cross team communication and impediment removal approach.

To get things moving quickly our PMO manager booked a weekly meeting with the Scrum Masters, during which they were asked what the status was of each release that was in progress (we have 1 or 2 maintenance releases and 1 feature release in progress at any one time). The Scrum Masters saw it as the PMO meeting and were fearful of raising issues at the meeting, as those issues would then be forwarded onto the management team. The Scrum Masters thought that any issues that were raised made them look bad, meanwhile the management team was hanging out to know the real status of the releases, so that they could help wherever was needed. This fear or lack of a ‘Safe to Fail’ environment was addresses separately (and is perhaps the topic of another blog).

With the PMO established Scrum of Scrum operating, the management team continued to receive feedback that there was not enough team to team communication, however we did start to get some issues raises and did get some feeling for how well the releases were going (and they were going well). We were still concerned that the level of ownership of Release Co-ordination was not as high as we needed it to be.

Attempt 3 – Scrum Master established Scrum of Scrums

With Attempt 2 still not providing the results we wanted, we decided to intervene by re-invigorating the ‘SOS’ (this unfortunately meeting name was one of the first things to go).
To kick off the change our two Engineering Managers (who have responsibilities around People and Practices) each talked one-on-one with the Scrum Masters that reported to them. 

They asked about the Scrum Masters view of the SOS meetings and set out some clear expectations around team to team communication, Scrum Master to team communication, the raising of issues, ownership of release co-ordination and running the Scrum of Scrums. Lastly they were told that a meeting would soon be organised with all of the Scrum Masters where they would have to work out how they would re-invigorate the Scrum of Scrums.

I facilitated the meeting with the Scrum Masters and the Engineering Managers in attendance. We started with one of the Engineering managers setting down the expectations regarding the Scrum of Scrums:
  • Raise team specific risks, so that the other teams are aware and can assist.
  • Explain what each team is doing, so that the other teams are aware and can assist.
  • As a group uncover big risks and either deal with them or escalate them.
  • As a group review and understand commitments especially those with specific dates.




Goals of the Scrum of Scrums


Once those expectations were clear we got down to the business of the Scrum Masters deciding what information they needed to be able to meet those expectations, how the meeting would be organised, when it would occur and who should attend.

Self selected actions for making the Scrum of Scrums effective


In summary they decided upon:
  • All Scrum Masters and the PMO manager would meet weekly on a Monday after all of the Stand Ups were completed. No other people had to attend, however back up Scrum Masters and the Lead Architect was optionally invited.
  • Using a large highly visible planning board, showing all teams, all key user stories, dates, etc.
  • A simple agenda: Each Scrum Master presents in the order shown on the board, and then any issues/news is discussed as a group.
  • Each Scrum Master was responsible for keeping their team’s row up to date.
  • One volunteer would create the first Scrum of Scrums board.


Multi-team release planning board


Continuation / Tuning

The first meeting went reasonable smoothly, a due date was clarified, a risk was discovered and they discovered two teams that needed to co-ordination on a user story. A few tweaks to the board where suggesting, including using a consistent colour coding scheme.

The next few meetings were tentative affairs as each Scrum Master was ‘feeling out’ how they should behave in this new situation.

The fifth meeting seemed like they were starting to get off track and just running through the motions of an ineffective status update meeting.

Multi-team release planning board


The sixth meeting had some minor cross team concerns discussed. A couple of teams had let their information get out of date, with only one user stories up for the current sprint. The major issue was that we were fast approaching a critical release date, and there was no communication around the status of features that had been committed in the release. It seems like the Scrum Masters were not considering the whole release as much as was hoped by the management team. This prompted a lot of one-on-one discussions and feedback sessions, which thankfully all hit the mark.

Seventh meeting: Great, they are really getting it, taking ownership, asking questions, self-organising. The teams that last week only had one card had added all of their planned user stories and provided more detail in their summaries; this triggered conversations and overall seemed successful.

The Eighth meeting was held part way through the first sprint of our new Release cycle. The board had the next 4 to 5 sprints filled in for most teams (only at a high level for sprints 2 to 5). As a group they spotted three key issues and quickly resolved them. It looks like the Scrum of Scrums is working and is here to stay.

Multi-team release planning board, after several evolutions

Monday, May 13, 2013

Coaching Scrum Masters


In my coaching work, I find that any effort I put into coaching Scrum Masters pays itself back many times over. The Scrum Master is able to take their improved knowledge and apply it to their team which has a compounding effect. With the Scrum Masters fulfilling their role well the teams can hit their stride earlier and I can focus on key individuals and organisational issues.


Growth in people


In this blog post I explained my approach of providing direct feedback to Scrum Masters based on the Scrum Activity that they just facilitated. That approach has served me well; however it was not always been smooth sailing. I have learnt a few lessons along the way. From my successes and lessons I present to you a list of ‘Trys’.

The basic approach is to observe the Scrum Activities (Planning, Review, Retrospectives, Stand ups) and provide feedback directly to the Scrum Masters. Focusing on the Scrum Activities helps the Scrum Masters to quickly come to terms with the most visible aspects of Scrum. With these visible aspects under control, they can move on to learning about the more ‘behind the scenes’ aspects.


Prior to the activity


  • Try asking for permission from the Scrum Master to attend the activity. This serves several purposes; it helps to bring the Scrum Master onside ready to receive your feedback, it gives you a chance to ask the Scrum Master to explain your presence to the attendees at the start of the activity, and it allows you to book in a time to provide the feedback promptly after the activity.



During the activity


  • Try having the Scrum Master explain to the attendees as part of setting the scene for the activity; that your presence is to provide feedback to the Scrum Master and help them improve; it is not to grade the team. This goes a little way towards the attendees being more open in your presence.
  • Try taking plenty of notes during the activity. Making sure to record specific examples of the incident that relates to the feedback you want to provide. i.e. During a Retrospective ‘Need to drill into symptoms to find root cause’, would be better recorded as ‘John said the tests where taking too long; you should have asked why are they taking so long, before getting the team to come up with a Try.”

After the activity


  • Try to meet with the recipient promptly after the event. The same day is ideal, the next day is ok. With the event fresh in your minds you will both be better placed to discuss specific examples.
  • Try keeping your feedback to around five key points or less. Any more then that will be hard for the recipient to take in during the feedback meeting. I often look at my page of notes and mark a couple of good points and a couple of the areas for improvement, making sure to only mark five points or less.
  • Try meeting in private, this encourages the recipient to be more open and frank with you, especially when talking about their interactions with other people.
  • Try starting the feedback meeting by asking them what they thought of the event; their answer is often enlightening. Some times they may already have internalised the feedback that you intended to give them, they may have seen the activity completely different to you, they may have had some insight into why people did what they did, they may offer up some issues that gives you a great opportunity to drill into.
  • Try to discuss all criticisms in a constructive way. They should be presented as areas for improvement. E.g. ‘You did not stop the ongoing discussion about how to design the widget, that discussion was wasting the team’s time.’ would be better phrased as ‘The ongoing discussion about how to design the widget, could have been cut short and taken offline. This would have saved several minutes for the team. Perhaps next time a discussion is occurring that only involves a couple of people goes for over a minute of two, you could politely ask them to take it offline? Would you be comfortable doing that?’
  • Try using the Feedback Sandwich:  

  1. Start with positive feedback (Praise).     
  2. Discuss areas for improvement (Constructive Criticism)     
  3. Wrap up with more good stuff or general encouragement (Praise).

  • Try to discuss all praise and criticisms based on recent and specific examples. E.g. ‘It would be good to see you support the voice of the quiet people in the team’ would be better as ‘When Ronald started to talk about his issues with the documentation being out of date; it would have been a great opportunity to support a quiet voice in the team by agreeing with him and asking the team to discuss it further’.


Good luck giving out your feedback and seeing your Scrum Masters grow. Let me know if any of these try's worked for you. I am also keen to hear about any that backfire for you.

Photo by: Kris Anderson

Sunday, April 21, 2013

Focus on UX


I recently attended a session of the London Agile DiscussionGroup where the focus for the night was UX, what is it, where does it fit in the lifecycle of an agile project? To me it was a very interesting night as I have not worked directly with a UX designer before. I was intrigued to see how others have done it.


I was especially keen to know whether they had been able to work in a continuous manner (UX developed in the same sprint that it is applied to the product) as opposed to working sequentially (UX developed in Sprint N, UX applied to product in Sprint N+1). Going into the night I had seen couple of ThoughtWorks presentations on Continuous Design. However because I had never experienced it, I was open to possibilities on both sides of the debate. At the end of the night I had heard three tales of Continuous UX occurring in the wild and about 70% of the attendees believed that it will be possible for them to do Continuous UX in the future.

For me there were three key takeaways from the night:
  1. Continuous UX is possible.
  2. The key to Continuous UX is small User Stories.
  3. UX needs to involve feedback from real users; ideally the feedback should be analytical data. Otherwise it is just guess work and not really UX.


From what I heard most UX is a case of cyclically incorporating the feedback/data into the on-going design and development work. There will be some UX Debt accumulate, but you need to keep it low as the cost of those UX changes can quickly sky rocket. In summary UX like architecture, needs to be a little bit ahead of the daily sprint work, but not sprints ahead.

One of the real life success stories I heard, was of a small team (1 UX, 2 developers & 1 QA) building internal system and working on small User Stories. The UX guy would produce working CSS of the item in half a day, and work with the team on refining it. They were able to deliver a continuous flow of changes that incorporated UX. The UX guy building directly into CSS and not writing down his ideas; was a large part of their success, along with their small stories that lead to simple UX.

Restaurant Booking Web site scenario

To put our new found knowledge into action, each table of participants at the meet up, took on the following scenario. As a new project team, create a web site for a local restaurant that allows them to take bookings for dinner. Outline the project plan sprint by sprint for the first couple of sprints. From my memory this is what we came up with as a team.

Sprint 0
  •        Establish team
  •        User Story Workshop & Project envisioning
  •        Establish Infrastructure: hardware, coding standards, continuous integration, etc.
  •        Deploy a hello world home page that is not published to DNS servers hence is only available to navigate to via entering the IP address.
  •        Create architecture that allows for AB split testing and analytics capture
  •        Create Brand Guidelines – style guides, reusable controls such as buttons.
  •        Conduct Market Research


Sprint 1
  •        Deploy a publicly accessible holding page that uses the brand guidelines, indicates that a full web site is under construction, shows the address, phone number and e-mail address of the restaurant.
  •        Conduct AB split testing on some different holding pages.
  •        Start working on the highest priority User Stories, incorporating UX as we went.