Tuesday, April 1, 2014

Scrum Master Competencies

The Scrum Master is a complex, challenging and rewarding role. Consequently they need to develop a broad range of competencies. A diverse skill set will allow them to succeed; no matter what the world throws at them and their team.

What follows is the list of competencies that I believe a great Scrum Master / agile Iteration Manager should develop over time.




Organising the Team

Knowledge of Scrum rules
Making the team status visible to everyone, all of the time
Communicating internally
Communicating externally
* Ensure the Team level documentation is up to date, and of appropriate quality
Provides Clear Direction within the Sprint 
  • Set clear and elevating goals within the Sprint. PO sets goals outside of the Sprint.
  • Focuses team on delivering priority/valuable items
  • Limits team WIP
Effective Facilitation
  • Outcome focused Meetings
  • Time Boxing
  • Adjusting to different situations
  • Dealing with Difficult people
  • Observe while participating
  • Be Participant and Facilitator
  • Create safety
  • Root Cause Analysis
Dealing with impediments
  • Identifying impediments
  • Resolving team impediments
  • Resolving cross team impediments
  • Appropriate Escalation
Using Collaborative engagement techniques 
Involving whole team in Sprint planning
  • Setting clear elevating goals
  • Appropriate commitment level
  • Ownership of the commitment
  • Adjustment of the Sprint Plan


Improving the team

Managing Technical Debt 
Using Lean principles in decisions 
  • Eliminate waste
  • Build Quality in
  • Create Knowledge
  • Defer Commitment
  • Deliver Fast
  • Respect People
  • Optimise the whole
Leading change
Using Continuous Validated Learning 
  • Plan, Do, Check, Act
  • Designing Experiments
  • Collecting & using Data
  • Safe to Fail
  • Varied Retrospective Approaches
Improving team members
Establishing a good Team Culture
  • Celebrate successes
  • Social bonding
  • Supporting each other
  • Promotes cross skilling
  • Let’s the team experience failures
Using Agile Technical Practices
  • Refactoring
  • Agile Testing
  • Test First
  • TDD
  • ATDD
  • CI
  • PP
  • Simple Design

Establishing a Self-organising team 

Exhibit Servant leadership
Exhibit Scrum Values
Using Agile Principles in decisions
Ownership of team commitments
Encouraging ‘leaders’ within the team
Making it visible & get the team to take action
Get team to identify and remove impediments
Involving whole team in grooming / design
Involving whole team in medium term planning
Do yourself out of a job


Thinking Big

Basic medium term planning
Visualise teams medium term progress
Ownership of Department level commitments 
Communicating with other teams 
Identifying and resolving cross team impediments 
Improving cross team Technical Practices
Recording appropriate feature information for future teams
Ensure the Department level documentation is up to date, and of appropriate quality
* Ensure the Company level documentation is up to date, and of appropriate quality
Optimising the whole
  • High level knowledge of medium term plan for all teams
  • Volunteering to help other teams
Improving other Scrum Masters and POs
  • Providing Feedback
  • Motivating
  • Supporting



Self-Development

Balances Responsibilities of SM, Team Contribution, Self-Development
Coachable
Learns by reading / researching
Learns by experimenting / doing
Learns by discussing


Other Characteristics

Patient
Assertive
Self-Starter
Organised
Prepares well for meetings
Consistent
Understands people


Getting Team Based Results

Team delivering consistently
Team regularly finishing their top priority stories first 
Team regularly finishing >=33% of stories prior to the Sprint half way mark 
Team and PO collaborating extensively on stories (planning, splitting, design, implementation, verification)
Team not building up inappropriate Technical Debt
Retrospectives regularly result in positive changes
Innovation is occurring



Your Thoughts...

Have I missed anything? 

Is there any that you disagree with?


Photo Credit: angus clyne via Compfight cc

Sunday, March 2, 2014

Organisational change in change resistant organisations

In organisations that are resistant to change, I introduce change incrementally and iteratively. I use a Plan Do Check Act approach to rollout changes step by step. This blog describes that approach and what I think about as I attempt to implement changes. Most of my thinking focuses on the Planning step. That focus comes because the act of planning mitigates impediments, strengthens your plan and builds consensus. All of which is crucial in a change resistant organisation.

If the approach that I describe seems ‘heavy’ to you, that’s because it is. This approach will be overkill in organisations that are ready to embrace change. However for change resistant organisation I have found that this approach allows me to gradually introduce changes that deliver Impact. As those Impacts mount up, people slowly begin to trust more and allow for more impactful changes.  

Summarised change approach



Plan

  1. Recognise opportunities 
  2. Recognise impediments
  3. Draft an action plan that will create Impact
  4. Learn from stakeholders
  5. Tune your action plan

Do

  1. Try it out, on a small scale.


Check

  1. Observe the results
  2. Discuss the results with your stakeholders. 


Act

  1. Tune your plan for the next attempt. 
  2. Iterate on the Plan, Do, Check, Act cycle. Rolling out the change to more people/teams.


Plan



Recognise opportunities

As a Change Agent I will identify a specific opportunity for change that I think will be beneficial. This kick starts my change approach.

E.g. The Delivery Teams currently do not use Test Driven Development (TDD). I would expect that introducing TDD would increase quality in the short term and that reliability and speed would increase in the long term. Once I have identified this, I need to work how to go about introducing TDD.

An alternative starting point to identifying a specific change; is that you want to improve a general aspect of the organisation. Generally you will want to produce one or more of these Impacts:

  • Improve effectiveness
  • Improve speed
  • Improve quality 
  • Improve innovation
  • Improve morale
  • Improve reliability


Aside: I did not mention ‘improve efficiency’ or ‘reduce cost’, as they came from achieving increased speed, with increased quality and increased reliability. We are better off chasing positive influences, as opposed to reducing negative influences.
If you are interested in generally improving an aspect of the organisation I recommend you read up Selling the Idea of Lean to Management

The rest of this blog will tackle the situation where you have a specific change that you want to put into place. I will go through how I create, tune and deliver a plan of action to introduce that specific change.

Recognise impediments

I find it is important to identify and mitigate the impediments to my plan. Just thinking about what impediments you may face is often enough to come up with simple solutions to mitigating them.

I try to consider as many different sources of impediments as possible, such as:

  • People – they can be allies or impediments.
  • Organisation Structure, Team Structure.
  • Processes – from all levels and all departments.
  • Policies – from all levels and all departments.
  • Tools – entrenched, lacking or poor.
  • Environments – limited, tightly controlled, unreliable.
  • Culture – the way things are done around here, we have always done it this way, etc.
  • Environmental – building, desks, rooms, lighting, etc.


Draft Plan

I draft a rough plan of action to implement the change. I do this considering what Impacts I want to achieve and what Impediments I am facing. It is not a good idea to create a detailed plan, because I expect the plan to change significantly during the next step.

The plan usually consists of some dot points, such as:

  • Which Teams / People should I start this with?
  • Which Teams / People should I avoid?
  • Which Teams / People would be next?
  • How will I convince the initial Teams People of the benefits?
  • Who do I need to gain support from to initiate the change?
  • What Impacts do I expect?
  • How will I measure those Impacts?
  • What costs do I expect during the rollout?
  • What costs do I expect in an ongoing basis?
  • What Impediments do I need to remove?
  • What Impediments can I avoid by going around them?


Learn from Stakeholders

The plan that I draft is just the beginning. Things get serious when I start to talk to stakeholders. Engaging stakeholders serves the dual purpose of learning how I can improve the plan and building consensus for the plan.

Generally I arrange an individual discussion with each stakeholder. Starting with the least influential and working towards the most influential, and finishing with those who I believe are opposed to the plan.

Alternative approach: Sometime it can be incredible useful to discuss the plan with a critic earlier in the process. This will help improve the strength of your plan, and make future discussions easier. This works best when you have built a good relationship with someone who is critical and good at providing constructive feedback.

When meeting with each stakeholder I tend to focus on the opportunities and impediments. I avoid talking about the details of my plan unless they are a detailed focused person. I listen intently for obstacles, support, their values, what is driving their behaviour, alternative ideas and potential variations to my plan. Overall I am trying to bring them onside, and learn from them so that I can strengthen my plan for future discussions.

After each discussion I think of how to improve my plan. i.e. How to strengthen its benefits, ease its introduction costs, better ensure success, reduce obstacles, prepare arguments against potential disagreements, find evidence to support it.  I also consider which variations of the plan instead of the pure original idea will still be successful. I find it really important to be flexible in how we achieve the impacts I am seeking. 

Do



By now, this should seem like the easy step. I have built support from the change from numerous stakeholders. I have learned how to mitigate any significant impediments. The plan is ready and many people are vaguely aware that some change is coming.

This is where I try it out, hopefully on a small scale. I get the official green light from the key stakeholders. Communication before, during and after change helps significantly. So I make sure the Teams / People know what is coming up. Then get them involved. Importantly I support and observe the whole change as it is implemented. This is not a good time to go on holiday.

Check




With the initial change rolled out. I check in with the participating Teams/People. From them I can check what the real Costs, Benefits and Impacts are.

Going back to the stakeholders and discussing the results of the initial change, is a good way to build further support and gain consensus for a wider rollout. Additional it is useful to mitigate any unexpected impediments. 

Act



The discussions with stakeholders in the Check step; allows me to tune the plan for the next attempt.

From here it is a matter spreading the change out to more Teams / People with Plan, Do, Check, Act. 

Consider Pivoting: If you significantly toned down your original plan (i.e. Rolling out TDD, changed to rolling out Test First) consider what evidence you have gathered that justifies reverting to your original change idea. Perhaps you can now convince those hesitant stakeholders that your change is really worth the effort. 

Good Luck

Change is hard, especially change that sticks. 
Good luck with your change journey.

Sunday, February 23, 2014

How to sell the idea of Lean to Managers


What I have learnt is; don’t. 

Lean is counter intuitive, ill-defined*, and a tough concept to sell. Instead, ask them what outcome they want to improve: efficiency, speed, quality, innovation, morale or reliability. Use Lean Thinking to determine what Predictor could lead to the improvement they desire. Measure that Predictor, and apply some Lean Thinking without talking about Lean. The improvement they seek should materialise and you will then have support to work on the next improvement. Over time the business will be more successful. 

Effectively Lean is a tool kit that you can utilise to improve business outcomes. Don’t ‘do Lean’, use ‘Lean Thinking’.  Similar to agile, you can’t ‘do agile’, but you can think in an agile way. 

*just search for images of ‘House of Lean’ to see how many different ways it is represented.

Sell Outcomes

Generally speaking any manager is going to be interested in improve one or more of these outcomes:

  • Efficiency - producing more with less.
  • Speed – increases frequency of delivery, or completing projects quicker.
  • Quality - of the product delivered.
  • Innovation – both internal innovation and product innovation.
  • Morale - of staff
  • Reliability - of delivery / predictability of release cycles / doing what we say

Conversations about getting better at an outcome; are much easier to have then attempting to explain how Lean Principles can help them. So instead of trying to sell them on the idea of using Lean, talk to them about what they are really interested in (getting better). 

Measure Predictors not Outcomes

A Predictor is an aspect of work that affects the target Outcome.

To gain support for making future changes it is important to be able show improvement. This is where you apply some Lean Thinking (without mentioning that it is Lean) to select appropriate Predictors to measure. 

e.g. As a team you release that you quality is not as good as you would like it to be. After discussion with the team you find out that the code coverage is low (i.e. < 60%). Using the Lean Principle of ‘Build Quality In’ you decide to measure Code Coverage. The extra tests will increase the quality of your deliverables. Once the code coverage approaches 80% you drop that metric (to prevent gaming of the metric). Now you switch to measuring the pass rate of the test suite, so that the effectiveness of the tests them improve. This will again improve quality. You could also consider measuring the ratio of Test lines of code to Product lines of code. 

Some examples of Predictors

This list is just meant to give you an idea of what to consider, it is by no mean exhaustive. Importantly these measures may not fit your situation. This is where your Lean Thinking needs to kick in.

Outcome (measure of the outcome)

  • Predictor / Measure of the Predictor


Efficiency (High value delivered per release) 

  • Low average hours in meetings.
  • High ratio of work developed using ATDD.

Speed (Low cycle time) 

  • Low WIP.
  • Smaller User Stories.
  • Average utilisation of staff below 70%
  • High Quality & Reliability (speed usually comes from quality and reliability)

Quality (Low average escaped defects)

  • High ratio of work developed using TDD.
  • Test coverage approaching 80%.
  • Mutation coverage approaching 80%.
  • High average pairing hours.
  • High average Dev-QA pairing hours.

Innovation (High Average innovation ideas submitted per month) 

  • High time logged to innovation activities.
  • Low duration of continuous integration test suite.

Morale (High Engagement survey results, High Retention rate) 

  • Low sick days.
  • Average working hours just under 40 per week. 

Reliability (High Ratio of delivered to planned user stories) 

  • Smaller User Stories.
  • Low WIP.
  • Low average days a story in blocked/impeded. 
  • High average number of commits per day.


Sunday, January 26, 2014

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.



Monday, January 13, 2014

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

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



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 Effort, Complexity & Doubt

In my mind Story Points are made up of effort, complexity & doubt. It is important that everyone in the team understands what these all mean and how it relates to their work.
Talk about:

  • 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 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 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?


Interested in estimation?







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