Sunday, August 10, 2014

Ideas for tasks when splitting or planning your User Stories

After years of working in a command and control culture moving to an agile methodology feels liberating for many team members. Unfortunately it can also feel over whelming. The first time a team needs to plan their iteration for themselves the can struggle to think of appropriate (and importantly small) tasks to split their User Story into. What follows is a list of ideas that I use with new teams to open their eyes to some of the options they have available to them.

Additionally of the following information is available on this one page PDF cheat sheet.


Cheat sheet for splitting or planning User Stories into tasks


Acceptance

  • Clarify Product Owner expectations
  • Product Owner early feedback
  • Product Owner review 
  • Confirm all Acceptance criteria


Shared Understanding

  • Scenario workshop (Three amigos)
  • Design session
  • Test creation session
  • Meet with customer representative


Development

  • Design review 
  • Refactoring of existing code
  • Interfaces created
  • Code / Implementation
  • Code reviewed
  • Unit tests
  • Unit tests reviewed 
  • Defects resolved 
  • Defects retested 
  • Code merged 


Quality Assurance

  • Functional test plan created 
  • Functional test plan reviewed 
  • Functional test plan executed 
  • Automate functional tests 
  • Identify tests for automation
  • Exploratory testing
  • Regression Test Suite passes 
  • Continuous Integration passes
  • Deployment Tested
  • Performance tested


Documentation

  • Deployment instructions
  • Internal Processes / Guides
  • External Processes / Guides
  • User story – notes, history, plan
  • High Level design
  • Design decisions
  • User Manual
  • Help
  • ‘How to’ Guides 


Tracking

  • User Story updated in tracking tool 


Demonstration

  • Script/Run-sheet updated 
  • Data prepared 
  • Demo automated
  • Deployed to demo environment 
  • Practice run


Agile Coach Competencies

When thinking about how I could further improve my skills and knowledge as an Agile Coach, I came to the question of ‘How does an Agile Coach differ from a Scrum Master?’ Both provide coaching and work in agile, hence any division could appear to be very arbitrary. Writing out the competencies that I feel a good Scrum Master should have and then the competencies a good Agile Coach should have helped me answer the question. One good way to split the roles; is to look at what they focus on.

If I assume a Scrum Master is someone focused on providing Servant Leadership for a single team or a couple of teams. Than an Agile Coach is someone who focuses on coaching the department (and/or company) that those teams exist in. The Agile Coach provides training and coaching that is aimed at delivering value across the department/company, not just the team level. Sure a Scrum Master can do this, however it is not their focus when there are Agile Coaches and Scrum Masters in the same company.

With all of that in mind, I have updated my post on Scrum Master Competencies, and I present the competencies that I want a good Agile Coach to have.

The information presented below is available as a two page PDFcheat sheet.


Agile Coaching Competencies cheat sheet

Competencies of a good Agile Coach

These competencies assume that the person already has most of the Scrum Master Competencies.

Values

* Adaptable
* Persistent
* Observant
* Unassuming
* Inquisitive

Methodologies

* agile Manifesto
* Scrum
* XP
* Lean 
* Kanban
* Agile Fluency Model
* Declaration of Interdependence


Scaling Approaches

* Scrum of Scrums
* Lean PMO
* LeSS 
* SAFe 


Change Management

* Iterating towards agility
* Questioning to encourage action
* Create broad network of contacts
* Building strong relationships
* Crucial Conversations
* Fearless Change Patterns
* Kanban Method
* Kubler-Ross change curve
* Kotter’s 8 step model
* Lewin's model
* McKinsey 7-S model 
* ADKAR model
* Schein's organizational culture model
* Appreciative Inquiry


Metrics

* Dangers of metrics
* Lean metrics
* Visualising metrics
* Personal KPIs
* Team KPIs

Thinking Tools

* Queuing Theory
* Systems Thinking
* Theory of Constraints

  • The Five Focusing steps
  • Current reality tree
  • Evaporating Cloud


Coaching

* Questioning for realisation
* Questioning to encourage action
* Creating SMART goals
* GROW model
* FUEL model
* Neuro-linguistic programming 
* Body language to control the mind
* De-stressing techniques
* The Responsibility Process 
* Working with resistant people


Training / Teaching

* Reading the audience
* Keeping energy levels up
* Kolbs learning styles
* Learning Modalities
* Fleming's VARK model
* Games for learning
* Run Dojo’s
* Run Lean Coffees
* Run World Cafes
* Competency Based Training
* Creating training material
* Creating games


Evangelising

* 30s elevator pitch for agile
* Exhibit passion


Hiring

* Interviewing Techniques
* Competencies to look for


Communication

* Awesome emails
* Excellent written
* Creating memorable presentations
* Presenting
* Using appropriate medium


Planning

* Backlog Prioritisation Frameworks


* Multi Team Boards
* Traditional Iron Triangle
* Agile Iron Triangle
* Release burn-ups
* Feature / Traffic Light charts
* MoSCoW categorisation


Facilitation

* Facilitate large groups
* Facilitate senior managers


Collaborative engagement techniques 

* Impact Mapping
* Value Stream Analysis


Self Development

* Experiment at work
* Self reflection
* Attend Meet-ups
* Attend Conferences
* Read Books, Articles, etc.


Motivating Others

* Autonomy
* Relatedness / Purpose
* Mastery
* Detractors / Inhibitors


Distributed Development

* Models
* Communication
* Engagement
* Technical Practices


Agile Contracts

* 10 types
* Building trust

Your Thoughts

Have I missed anything? 

Is there any that you disagree with?


Related Articles




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


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.


Scrum Master Competencies cheat sheet


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

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.