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

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.

Communication during a transition

In summary it should be focused on what you hear not on what you say.


We recognised that communication with staff during an agile transition was important for two reasons; firstly so that the transition changes would be understood and accepted. Secondly and most importantly, so that issues and concerns from staff would be raised. We could only address concerns that we knew about so it was crucial that they were raised by the people who were feeling the impact of the changes.

Try as we might, deafening silence was the result of most of our communication approaches. 

While this blog post presents many communication approaches that failed to generate any feedback, overall the transition was a big success, with the results to prove it. The net positive survey response to ‘I am well informed about the agile transition’ rose from 70% to 84% and then to 90% over two years. However the ultimate indicator of success is that the vast majority of staff are really happy at work.

What I have taken away from all of this, is that communication should come from numerous channels and MUST be two way to be effective. It also brings to mind the Proverb "Listen to people twice as much as you speak." 

For those who are interested, the remainder of this blog explains the different approaches that we tried and a brief summary of the outcomes.

• Email feedback inbox – e-mails received in two years, zero.
• End of Transition Team sprint Email, explaining what we had done and are planning on doing. In there we linked to the feedback email address and mentioned that all of the Transition Team is open to being approached – feedback received, zero.
• Chocolates hidden behind links in the End of Transition Team email - we ended up eating the chocolates ourselves as no one found them.
• Directly telling people about chocolates hidden behind links – partial success, with some heavy hints, the chocolates were ‘found’ and handed out, excitement and interest created = zero.
• End of sprint Blog, explaining what we had done and are planning on doing - very few people subscribed to the blog.
• Transition Team members provided in person updates to teams after their stand ups – partial success, teams got the information and queried a few items; however where generally dis-interested and questioned why they get Management updates and Transition Team updates.
• Submit news to go in Management Update – un-tested by this time the Transition was wrapping up and only one news item was submitted, ‘the disbanding of the Transition Team’.
• Quarterly Staff speak ups – this generated a couple of questions but generally there was silence, at least they were there to hear the messages.
• Ask Transition team for concerns, who in turn asked Scrum Masters, who in turn asked team members – success, a reasonable number of concerns were raised. Many of these were turned into Transition Team User Stories.
• Surveys – ten questions one page, done via Survey Monkey, same survey three times over two years. Success: 80% of staff responded, plenty of meaningful and detailed feedback received. Many of these were turned into Transition Team User Stories.
• Rick Roll entire division in Transition Team farewell e-mail – good result, at least five people contacted me ;-)
• Scrum Masters discussing issues with their manager during regular 1 on 1s – success, plenty of issues where raised and then discussed by the Transition Team with several of these becoming Transition Team users stories and some guidance for stories already in progress or about to start.
• Division Manager holding Staff Forums with small cross functional cross team groups – a great success, staff really got stuck into providing direct and honest feedback. Some of this was related to the transition and other items were more general. This provided some Transition Team user stories and some guidance for stories already in progress or about to start.

Image Provided by: © Svidenovic | Dreamstime Stock Photos & Stock Free Images