Breaking down the Coder vs. QA divide

The Coders vs. QA divide is prevalent in almost all companies that are new to an agile way of working. The Coders camp out on one side of the wall, throwing work over to the testers. Creating cross functional teams does not automatically resolve the ingrained ‘over the wall’ mental model of development. Often two mini teams form within the agile team, with the wall still very much intact. This mental wall perpetuates ‘Us vs. Them’ adversarial behaviour; which generally leads to late delivery, reduced quality, stressed testers, limited collaboration and frustration on both sides. Thankfully this issue can be addressed in a reasonable time-frame when the appropriate actions are applied as a cohesive approach.

The long term goal regarding Coders vs. QA is usually to blur the line between Coders and QA to the point that they are all ‘Developers’. Some of the Developers have more of a QA focus; however all of the Developers are actively involved in testing and quality throughout the life-cycle of the product. These Developers create and maintain a test suite that adheres to the agile QA pyramid. This is a long and rewarding journey to take; with breaking down the Coder vs. QA wall as the first major step.

How to identify that the Coder vs. QA wall exists

When you notice two or more of the following situations, it is likely that there is a divide between the coders and the QA.

• QA/Testers are the only people who test the software. No one else helps even when it appears likely the team will not complete a user story within the iteration.
• Reviews and showcases where teams discuss user stories that have been built, yet the user story has not been tested.
• Reviews and showcases where teams show user stories that have not been tested.
• Inconsistent velocity from teams.
• The testers are stressed at the end of iterations while the coders are idle looking for work, or worse still working on user stories from future sprints.
• All of the testing occurs in the last 10% of the sprint.
• Request to extend sprint duration because it takes too long to test the delivered features.
• Use of phrases such as “It is done, I have coded it, it just needs to be tested.”

How to remove the Coder vs. QA wall

My favored approach to removing the wall involves some carefully executed company level actions, supported by team level coaching. While it can be addressed just via team coaching; that does not scale well, produces inconsistent results and takes a lot longer. I recommend considering the following actions, remembering that these actions need to work together to change the hearts of minds of many different people.

Company-wide minimum DOD includes “User Stories must be Tested”. All teams must have a DOD that includes the ‘minimum DOD’; they are free to build upon if they wish.

Company-wide training which emphasizes

• Teams succeed or fail as a whole
• The whole team is responsible for quality, not just the testers.
• QA provide Test Thinking, however everyone in the team contributes to testing.
• Value of completed stories over partially complete stories
• WIP is waste
• WIP reduces our ability to change direction
• ATDD/BDD

Company-wide support for ATDD/BDD with

• Tooling and environments
• Expertise and coaching for the implementation
• Specific training for QA to develop their automation skills

Coach Product Owners to

• Value only completed stories.
• Demand to see only completed stories in reviews/showcases
• Demand to only see working software in reviews/showcases

Support team coaches/scrum masters to:

• Re-enforce the messages from the Companywide training
• Establish Coder/QA pairing
• Establish ATDD / BDD
• Work with QA to create a prioritise automation testing backlog. This backlog can be worked on by Coders/QA during slack time. Over time it will reduce the demand for manual testing, freeing up the QA to focus on automation, exploratory testing and building quality in.
• Run team exercises where team members learn more of the details of what each other does and how they can help each other.
• Provide training to the coders on basic of effective manual testing; so that they are better able to step in when needed.

Questions for you

• What has your experience been with Coder vs. QA divides?
• Have I missed any signs of the divide?
• Have you taken different actions that worked well or taught you what not to do?

Image by Helen Wilkinson [CC BY-SA 2.0], via Wikimedia Commons

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.

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

• Money Voting
• Value vs. Size
• Prioritisation Matrix
• Weighted Shortest Job First

* 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

• What is it, to be an Agile Coach?
• Iteration Manager to Iteration Leader

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

What is it, to be an Agile Coach?

I am ...

a teacher - providing people with new knowledge.

a trainer - running people through exercises and giving them feedback, so they can improve their skills.

a networker - connecting people so that they can help each other.

a mentor - encouraging people to grow and improve.

a facilitator - organising events/ceremonies/meetings ensuring they deliver results while involving everyone.

a coach - helping people to grow, through thinking differently/ thinking about new things.

an agent of change - working tirelessly to improve how people, teams and companies operate.

a councilor - really listening to people as they talk through their concerns.

a supporter - helping people through tough times.

a student - always learning from others, reading, listening, observing.

a scientist - running experiments and sharing what I learn.

a statistician - gathering data, analysing that data, and sharing my thoughts. 

a historian - recording and explaining the history of projects and teams, both successful and unsuccessful.

an author - writing my blog for others to read.

an orator - speaking in a language that my audience can clearly understand. 

an evangelist - shouting out loud and proud about what I believe in.

a leader - providing direction to those who call for it.

a team member - mostly working with others to achieve my goals.

an agile coaching - helping people, teams and companies, to make their work life more fulfilling, enjoyable, effective and efficient.

Are you like me? What can we learn from each other?

Photo Credit: Phil W Shirley

Transforming the Scrum of Scrums and Delegating Release Co-ordination

“The agile manager’s scariest move; handing over responsibility”

Once we* had our Delivery Teams regularly delivering increments of valuable working software; the management team made the tough call of pushing the responsibility for co-ordination of releases to the Delivery Teams. This blog post follows this decision through its successes and failures and explains how we adapted to the feedback we received and issues that we identified.

*The Royal we: Management Team, Transformation Team, and Coaching Staff.

Attempt 1 – Complete freedom

A meeting was arranged by the management team to announced to the Scrum Masters (and a few other stakeholders) that as part of the ongoing transition the Scrum Masters must step up and take ownership and responsible for co-ordinating our quarterly releases. After this meeting the management team deliberately sat back and let the Scrum Masters sort it out themselves.

The Scrum Masters held a brief meeting to decide how they would handle the situation. They quickly selected two Scrum Masters to lead the co-ordination effort. One of them took the lead and did a great job of co-ordinating the release, which went out on time and to the quality we had aimed for. There was plenty of room for improvement but no major disasters.  

While the Scrum Masters were comfortable with this change, the management team quickly lost visibility of any issues that were occurring and at the same time were getting feedback from many staff members about a lack of communication between the Delivery Teams.

Another couple of issues popped up, which told us another approach was needed for the next release: 

1. The Scrum Master who lead the co-ordination of the previous release was promoted into the management team. 
2. The other Scrum Master who had been involved was currently swamped with practice improvement work. We were not sure who would step up to the take the reins.

Attempt 2 – PMO established Scrum of Scrums

With issues around lack of visibility, low communication between teams and concerns about how repeatable our previous success was, the management team decided that they needed to act.

At this point in time the culture had moved from ‘responsibilities being assigned to individuals’ towards ‘responsibilities being assigned to teams’. Looking at our current issues the decision was made by the management team to rotate the responsibility for Release Co-ordination between Delivery Teams each release, along with establishing a Scrum of Scrums as a status reporting, cross team communication and impediment removal approach.

To get things moving quickly our PMO manager booked a weekly meeting with the Scrum Masters, during which they were asked what the status was of each release that was in progress (we have 1 or 2 maintenance releases and 1 feature release in progress at any one time). The Scrum Masters saw it as the PMO meeting and were fearful of raising issues at the meeting, as those issues would then be forwarded onto the management team. The Scrum Masters thought that any issues that were raised made them look bad, meanwhile the management team was hanging out to know the real status of the releases, so that they could help wherever was needed. This fear or lack of a ‘Safe to Fail’ environment was addresses separately (and is perhaps the topic of another blog).

With the PMO established Scrum of Scrum operating, the management team continued to receive feedback that there was not enough team to team communication, however we did start to get some issues raises and did get some feeling for how well the releases were going (and they were going well). We were still concerned that the level of ownership of Release Co-ordination was not as high as we needed it to be.

Attempt 3 – Scrum Master established Scrum of Scrums

With Attempt 2 still not providing the results we wanted, we decided to intervene by re-invigorating the ‘SOS’ (this unfortunately meeting name was one of the first things to go).

To kick off the change our two Engineering Managers (who have responsibilities around People and Practices) each talked one-on-one with the Scrum Masters that reported to them. 

They asked about the Scrum Masters view of the SOS meetings and set out some clear expectations around team to team communication, Scrum Master to team communication, the raising of issues, ownership of release co-ordination and running the Scrum of Scrums. Lastly they were told that a meeting would soon be organised with all of the Scrum Masters where they would have to work out how they would re-invigorate the Scrum of Scrums.

I facilitated the meeting with the Scrum Masters and the Engineering Managers in attendance. We started with one of the Engineering managers setting down the expectations regarding the Scrum of Scrums:

• Raise team specific risks, so that the other teams are aware and can assist.
• Explain what each team is doing, so that the other teams are aware and can assist.
• As a group uncover big risks and either deal with them or escalate them.
• As a group review and understand commitments especially those with specific dates.

Once those expectations were clear we got down to the business of the Scrum Masters deciding what information they needed to be able to meet those expectations, how the meeting would be organised, when it would occur and who should attend.

In summary they decided upon:

• All Scrum Masters and the PMO manager would meet weekly on a Monday after all of the Stand Ups were completed. No other people had to attend, however back up Scrum Masters and the Lead Architect was optionally invited.
• Using a large highly visible planning board, showing all teams, all key user stories, dates, etc.
• A simple agenda: Each Scrum Master presents in the order shown on the board, and then any issues/news is discussed as a group.
• Each Scrum Master was responsible for keeping their team’s row up to date.
• One volunteer would create the first Scrum of Scrums board.

Continuation / Tuning

The first meeting went reasonable smoothly, a due date was clarified, a risk was discovered and they discovered two teams that needed to co-ordination on a user story. A few tweaks to the board where suggesting, including using a consistent colour coding scheme.

The next few meetings were tentative affairs as each Scrum Master was ‘feeling out’ how they should behave in this new situation.

The fifth meeting seemed like they were starting to get off track and just running through the motions of an ineffective status update meeting.

The sixth meeting had some minor cross team concerns discussed. A couple of teams had let their information get out of date, with only one user stories up for the current sprint. The major issue was that we were fast approaching a critical release date, and there was no communication around the status of features that had been committed in the release. It seems like the Scrum Masters were not considering the whole release as much as was hoped by the management team. This prompted a lot of one-on-one discussions and feedback sessions, which thankfully all hit the mark.

Seventh meeting: Great, they are really getting it, taking ownership, asking questions, self-organising. The teams that last week only had one card had added all of their planned user stories and provided more detail in their summaries; this triggered conversations and overall seemed successful.

The Eighth meeting was held part way through the first sprint of our new Release cycle. The board had the next 4 to 5 sprints filled in for most teams (only at a high level for sprints 2 to 5). As a group they spotted three key issues and quickly resolved them. It looks like the Scrum of Scrums is working and is here to stay.

Iteration Manager to Iteration Leader

Scrum Master to Scrum Leader

Iteration Managers/Scrum Masters should not just be managing their team. They should be providing the team with leadership that helps them to achieve great things to together.

• Lead not by telling them.
• Lead by helping them to set clear and elevating goals.
• Lead by teaching an agile way of thinking.
• Lead by teaching them to think through the problems that you yourself contemplate.
• Lead by making them think for themselves.
• Lead by encouraging them all to be their best.
• Lead by example. I.e. exhibit the Scrum values. Be the change you want to see.

Self-organising doesn't mean they don't have an Iteration Manager, it means they can function without one. An Iteration Manager will always be there leading them onto a greater success then they could achieve by themselves. That is what great leaders do.

This article is available in presentation form on SlideShare: Iteration Manager to Iteration Leader.

Photo Credit: I was unable to find the owner of this photo. Please contact me if you own it.