Co-ordination < Cooperation < Collaboration

This is one way a work group can improve their interactions and hence become a high performing team. Individuals and Interactions are crucial for a team to have a chance of being a successful agile team. I often see teams that are full of great individuals yet the team is not performing as well as they could be. One common cause of this is that they are all working as individuals and not interacting effectively. These work groups can become great teams by progressing themselves from Co-ordination to Cooperation to Collaboration. 

Co-ordination

Dictionary Definition: the organization of the different elements of a complex body or activity so as to enable them to work together effectively.

The working definition I use: Pursuing individual success over team success, by staying well out of each other’s work. i.e. Team members working on separate user stories within the same iteration. 

Symptoms at Stand ups: 

• Many user stories in progress.
• Reporting their status to the ‘leader’, not the team.
• No interest in user stories that are not their own.
• No concern regarding delivery of user stories that are not their own.

Cooperation

Dictionary Definition: the action or process of working together to the same end.

The working definition I use: Pursuing team success, by working as individuals. i.e. Team members working on separate tasks within the same user story. 

Symptoms at Stand ups: 

• Few user stories in progress
• Present their information to the team.
• Asking questions about user stories that they are not working on.
• Interest in the delivery of user stories that they are not working on.
• Rushing to select the most interesting tasks for themselves. 
• Rarely offering to assist each other.

Collaboration

Dictionary Definition: the action of working with someone to produce something.

The working definition I use: Pursuing team success, by working as one. i.e. Team members working on the same task within a user story. E.g. Test Scenario workshops, design workshops/sessions, pair programming, pair testing.

Symptoms at Stand ups: 

• Few user stories in progress
• Present their information to the team.
• Regularly offering to assist each other, especially when a user story is at risk.
• Requesting the team input into selecting the next task that will best help the team achieve its goal. 
• Regularly offering to pair with each other, and regular acceptance of those offers.
• Useful discussions often break out. It is sometimes hard to keep the stand up short because there is some much input and interest is effective plans and strategy.

Collaboration improves creativity

Effective collaboration results in something far greater than any contributor could achieve by themselves. Here are some creative collaborations, were I believe the result was superior to the input of any individual: Monty Python, Pink Floyd, The Beatles. They all bounced ideas off each other, helping each other to reach great heights. When separated they were all still great individuals yet failed to reach the dizzying heights they reached when collaborating.

Collaboration improves reviews

It is hard to provide an effective review without in-depth understanding of the work being carried out. That is why it is difficult and sometimes ineffective to review each other’s work when team members are just cooperating with each other. When team members collaborate with each other they are able to review as they progress, and/or review the work with deep understanding that results in superior feedback and hence a superior result. 

Collaboration improves planning

Planning is only as good as the input it receives. When team members are collaborating they are more invested in the work, and hence more motivated to provide input. Additionally they are more motivation to ask the tough questions at stand ups, that help teams deliver when the going gets tough.

Summary

Team members should aim to always be Cooperating and often be collaborating. 

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