Sunday, July 20, 2014

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

Three people coordinating their work across three tasks on three User Stories

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

Three people cooperating while working on three tasks on one User Story

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

Two people collaborating on one task, while another cooperates by working on another task all for the one User Story

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. 

Thursday, June 5, 2014

Seeking contract as Agile Coach or Scrum Master

I am seeking a 3 month or longer, London based contract as an Agile Coach or Scrum Master. 

Please contact me if you have a role available.


Thursday, May 29, 2014

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…

Start/Finish line


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

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.


Tree of competencies


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 Do Check Act cycle


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

Planning step from Plan Do Check Act cycle



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

Do step from Plan Do Check Act cycle
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

Check step from Plan Do Check Act cycle



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

Act step from Plan Do Check Act cycle


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

How to sell 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.
Example physical task board