Saturday, September 23, 2017

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


Sunday, April 23, 2017

The Fist of Five a voting and consensus building technique

The Fist of Five is a voting and consensus building technique that allows groups of people to quickly understand what they agree and disagree on. With a foundation built upon the agreements they do have; the group can focus their time and effort on resolving their differences. The simultaneous voting aspect of Fist of Five boosts the effectiveness of the group conversations by giving everyone an equal voice. I.e. the loud extroverts in the group no longer dominate the conversation. It only takes one minute to teach the Fist of Five to a new group of people and considering its broad versatility; it is a collaborative technique well worth learning. 

I am sure that you have been in a lengthy team discussion that is wrapped up by the lead saying, “so we all agree then?!”. The team responds with some half nods, some murmuring and plenty of silence. The lead moves on quickly and you are left confused about what we just agreed upon and how much agreement there really was. This to me is a failed attempt and consensus based decision making. The Fist of Five can improve these situations in numerous ways with very little effort expended. 

Benefits of the Fist of Five


  • Reveals hidden information: Who agrees, who is sitting on the fence, who disagrees, why do they disagree.
  • Reduces me vs. them mentality: Participants are disagreeing with a statement not necessarily a person.
  • Builds consensus: quickly see where everyone agrees, hone in the areas of disagreement allowing for discussion to resolve these differences.
  • Saves time: prevents discussion around topics that are already agreed upon, speeds up the resolution of differences because the specifics of the disagreement are often clearer.
  • Provides more time to tackle the key issues: once the disagreements are clear, the group can focus their precious time on that item.


How to use the Fist of Five 


  1. The facilitator makes a statement, such as “The Sprint Backlog should include the seven User Stories that are underlined on the whiteboard” or “The new team name should be ‘High Five’”
  2. The facilitator counts down from three, holding their fist in the air. (They use that time to visually confirm that all participants are ready to vote, who show their readiness by raising their own fist into the air).
  3. At the end of the count down, all participants change their fist into their vote, as shown below.
  4. The votes are ‘read’ which leads to an ‘outcome’ as explained below. The outcomes include: Statement Accepted, Statement Rejected, and More Discussion is needed.



Participant voting


Participants show their agreement or disagreement with the statement by voting as follows:

  • 5 fingers: strongly agree / it is spot on / approaching perfect
  • 4 fingers: agree / it could be improved but i am happy with it
  • 3 fingers: neutral / will go with the majority
  • 2 fingers: disagree / the intent needs to be tweaked / the wording needs to change
  • 1 fingers: strongly disagree / the intent is wrong / i do not support this


Reading the votes

  • Strong agreement: Everyone voted four or five.
  • Agreement: The majority voted four or five; there are no twos or ones.
  • Strong disagreement: There are only threes and below.
  • Disagreement: any other result; such as there are some ones or twos, and some fours or fives.


Outcomes

  • If Agreement or Strong Agreement is reached, the statement is accepted; the team has made a decision!
  • If there is Strong Disagreement the statement is rejected; the team has made a decision!
  • If there is Disagreement then more discussion is needed. One at a time, those that voted two or one explain their point of view to the group, then others in the group join in the conversation. The facilitator guides the discussion before deciding what to do. Usually some changes will be made to the statement followed by a revote.



When to use the Fist of Five

The Fist of Five is surprising versatile; primarily because there are so many different situations where teams need to agree or at least understand what consensus exists within the team. Some situations where I have found the Fist of Five to be highly effective:

  • Choosing a team name
  • Choosing a name for a project
  • Agreeing on a Sprint backlog – which user stories to include
  • Deciding on the scope of a project – which scope items to include.
  • Agreeing on a Vision statement – which intentions to include and the specific wording of the sentence(s).
  • Deciding on the objectives for a community, such as Scrum Master Community of Practice - which objectives to include and the specific wording of each objective.
  • Deciding on a set of team values – which values to include and the specific wording of each value.


How to use the Fist of Five on multiple items

Sometimes your team will have brainstormed many competing items. The Fist of Five is still very effective in this situation to either decide on one winner or to select multiple items. The basic usage is the same as described above. The key difference is to vote on each item, and record those votes, before discussing any item in detail. As you vote on each item note down all the votes against the specific item (e.g. Jimmy votes 4, Bob votes 3, Sally votes 5, Dianne votes 2 could be recorded as 4352). This allows the group to assess the overall field of options and quickly rules out some options as well as locking in some clear winners. The team can now look to combine items before focusing their discussion on those items that did not have clear consensus.


Example of choosing a Project Name

What follows is the list of project names we brainstormed along with the Fist of Five votes for the items that did not have Strong Disagreement, and hence were immediately discounted. There were 6 people voting. In this situation we only wanted one name for the project so “Project New Hope” was the winner.

  • 323244 ProtoFNX (This item received two votes of 2 fingers, two votes of three fingers and two votes of four fingers)
  • Proton and FNX Foundation
  • Joint FNX & Proton
  • 234334 A new hope
  • 332244 FNXP
  • Return of the Mortar
  • Proton strikes back
  • 233323 Proton - A new hope  (This result is also Strong Disagreement)
  • Galactic War
  • Clone Wars
  • Death Star
  • Project JAM
  • JAM Session
  • Proton JAM
  • 544335 Project New Hope


Sunday, February 5, 2017

The company that takes lunch together, succeeds together

Most of the company's I have worked in have some kind of flexible working arrangements; ranging from choice over your break times; through to hot-desking with infrastructure that makes working from home almost seamless. So you can imagine my surprise when I joined my latest engagement and everyone takes lunch at the same time! Everyone also starts and finishes at the same time with only a hand full of exceptions. Initially I thought it was weird, even backwards; when close to one hundred people downed tools and headed off for their lunch break. However the many benefits that this provides quickly became apparent and I am now a convert.

To support these fixed times the company has a suitably relaxed approach to staff taking time away from the office when life demands it. i.e. A delivery can only be between 8AM and 12PM; your dog has a bad back and needs to go to the vet, etc. So for the most part everyone is at work during the set hours; however there is enough flexibility to live our lives.


The four primary benefits of fixed Start, Lunch and Finish times are:


  1. Increased social interaction, building up a sense of community and company.
  2. More time available for collaboration and face to face work activities.
  3. Encourages people to rarely do overtime.
  4. Increased efficiency 


Benefits related to increased social interaction


  • More random social interactions occur at lunch time.
  • Easier to arrange lunch with people outside of your team, because you all have lunch break at the same time.
  • Group lunch activities are easier for individuals to plan and attend; hence there more activities run and more regularly.  Some of the regular activities include:
    • Futsal
    • Board games
    • Co-op multiplayer (i.e. Rocket League, Fifa )
    • Art excursions


Increased collaboration time

The fixed times make for more time available for collaboration in day to day work. i.e. Everyone is available to collaborate from the Start time all of the way through to Finish time. No more having to wait until ‘Core Hours’ to be able to talk to someone in your own team.

Rarely do overtime

With everyone up and leaving at the same time, it sends a clear signal that overtime is not the norm here.

Benefits related to increased efficiency


  • Easier scheduling of meetings because you know when everyone is available.
  • Team daily cadence aligned.
  • Team cadence can be fine-tuned.
  • Companywide issues/opportunities can be resolved faster.
  • Company half day celebrations are easier to plan, and will not cut into productive time.


Drawbacks to fixed Start, Lunch and Finish times


  • Prevents regular commitments outside of those start and finish times. i.e. pick up kids from child care. This can turn away some prospective hires.
  • I am sure there are more I just don’t know what they are…


What are your thoughts?


  • Have you had similar experiences? I would love to hear about them, especially if they are from different industries.
  • Have you had different experiences to this? If so please let know how it was different and what we can learn by contrasting the two experiences?



Photo by: Juhan Sonin