Don't start your Sprint or Iteration on Monday

Monday seems like a logical time to start your Sprint, right? The start of the calendar week, rested after the weekend, let’s go! In reality it is a bad idea, and I will explain why…

Primarily it comes down to interruptions to the sprint cadence. The start and finish days of a sprint are the days where it is crucial that the entire team is in attendance. Everyone needs to know what we are doing, why, and to learn together from our mistakes.

Public or Bank Holidays usually occur on a Monday. If your sprint is scheduled to start on a Monday, which is also a Public Holiday, you need to reschedule all of the sprint meetings, shorten the sprint and this causes significant admin overhead and critically it interrupts your cadence. The other issue that often occurs is the impact of changes arising from Monday morning management meetings.  These changes hit the team just after they have started their sprint, resulting in re-planning costs, and a diminished sense of autonomy.

Fridays are bad too as this is often the day that people book off to extend their weekend into a mini break. Fridays are often the day that leaving lunches, leaving drinks and other celebrations occur, resulting in more impacts.

So instead of Monday, start your sprint on Wednesday or Thursday. The sprint end/start being the middle of the week has several advantages. It avoids the issues of Monday/Friday. Meeting rooms are generally more readily available in the middle of the week.

I do not recommend Tuesday because when there is a public holiday on Monday the sprint will effectively be ending the Friday before a long weekend (which is when everyone is mentally checked out).

So in summary avoid Mondays and Fridays it will save a lot of heart ache.

Photo Credit: Andrew_D_Hurley via Compfight cc

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.

August 2014: I updated list in conjunction with adding my Agile Coach Competencies blog. Additionally a two page PDF cheat sheet of Scrum Master Competencies are now available.

Organising the Team

* Knowledge of Scrum rules
* Communicating internally
* Communicating externally
* Up to date Team level documentation
* Reporting team status
* Involving whole team in Sprint planning

• Setting clear elevating goals
• Appropriate commitment level
• Ownership of the commitment
• Adjustment of the Sprint Plan

* Provides Clear Direction 

• Set clear and elevating goals
• Balances conflicting team priorities
• Focuses team on delivering priority/valuable items
• Limits team WIP

* Dealing with impediments

• Identifying impediments
• Resolving team impediments
• Resolving cross team impediments
• Appropriate Escalation

* 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

* Using Collaborative engagement techniques 

• Planning Poker
• Fast Estimation
• Visual Planning
• Dot Voting
• Story Maps
• Brainstorming
• Cause Effect Diagrams

Improving the team

* Managing Technical Debt
* Establishing a good Team Culture

• Celebrate successes
• Social bonding
• Supporting each other
• Promotes cross skilling
• Let’s the team experience failures

* Improving team members

• Providing Feedback
• Motivating 
• Coaching
• Teaching

* Using Agile Technical Practices

• Refactoring
• Agile Testing
• Test First
• Test Driven Development
• Acceptance Test Driven Development
• Continuous Integration
• Pair Programming
• Simple Design

* Using Continuous Validated Learning 

• Plan, Do, Check, Act
• Designing Experiments
• Collecting & using Data
• Safe to Fail
• Varied Retrospective Approaches

* Leading change

• Effective Retrospectives
• Influence without authority
• Challenging the status quo
• Kaizen / Continuous Improvement
• Celebrate successes

* Using Lean principles in decisions

• Eliminate waste
• Build Quality in
• Create Knowledge
• Defer Commitment
• Deliver Fast
• Respect People
• Optimise the whole

Establishing a Self-organising team 

* Exhibit Servant leadership
* Exhibit Scrum Values
* Using Agile Principles in decisions
* Ownership of team commitments
* 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
* Encouraging ‘leaders’ within the team
* Do yourself out of a job

Thinking Big

* Basic medium term planning
* Visualise teams medium term progress
* Ownership of Department level commitments
* Optimising the whole

• High level knowledge of medium term plan for all teams
• Volunteering to help other teams

* Communicating with other teams 
* Identifying and resolving cross team impediments
* Improving cross team Technical Practices
* Recording appropriate feature information for future teams
* Up to date Department level documentation
* Up to date Company level documentation
* Improving other Scrum Masters and POs

• Providing Feedback
• Motivating
• Supporting

Self-Development

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

User Stories

* Formats
* Personas
* INVEST
* Splitting Approaches
* Vertical Slicing
* Sizing

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

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

Add caption

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.

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.

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