Saturday, September 23, 2017

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?

Sunday, April 23, 2017

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

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’”

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).

At the end of the count down, all participants change their fist into their vote, as shown below.

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)

Sunday, February 5, 2017

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:

Increased social interaction, building up a sense of community and company.

More time available for collaboration and face to face work activities.

Encourages people to rarely do overtime.

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?

Saturday, December 10, 2016

High emotions, Intertwined issues and Inexperience are the key challenges that will all combine to make your 1st retrospective the hardest retrospective you have to facilitate. This situation is similar to your first driving lesson being on a rainy night, while you are surrounded by drunk drivers. Luckily there are steps you can take to tackle all three key challenges, and run the teams first retrospective successfully.

High emotions

For teams that have not had an effective avenue to express and tackle their day to day work issues; there tends to be a lot of emotion released in their first retrospective. During the retrospective team often realise they have a voice and are being listened to; hence a lot of the issues they have been frustrated about are vented. The emotional venting that occurs is hard to hear yet often therapeutic for all involved. If you and the team can turn those emotions into actions that address some of the teams’ frustrations they will not just like retrospectives they will love them.Mitigation actions

Acknowledge all input provided by the team, even if you disagree with it. You only have to acknowledge what is said, you do not need to agree with it. Merely the simple act of acknowledge is enough for the team to feel heard and hence reduce the level of emotion in the room below boiling point. The easiest way to acknowledge their input is to read out all of the post-it notes that they write out in the gathering data phase.

Intertwined issues

New teams and existing teams that have not held retrospectives previously; will often have their first retrospective dominated by a tangled mess of intertwined issues. The trouble is that one or two root causes are creating many, many symptoms and likely a lot of frustration. So no matter which symptom the team selects to analyse; it is intertwined with several other symptoms. This tangled mess drives the team conversation around in useless circles unless structured techniques are used to untangle the mess.Mitigation actions

Ensure you have plenty of time to discuss the first topic

Schedule 90 minutes for the retrospective, one hour is just not enough time

Time box the early parts of the retrospective to ensure enough time for discussion at the end.

Accept it is likely that the team will only get to analyse the top priority issue. The good news is that addressing just one issue will be big success for your first retrospective!

Inexperience

When this is the first retrospective for the team, yourself or both, there are likely to be feelings of excitement, anticipation, apprehension, uncertainty, etc. Also the role of facilitator is challenging at the best of times, as you attempt to juggle time-boxing, active listening, note taking and group facilitation. Thankfully there are plenty of resources available to prepare you and the team. Here are just a few approaches to get you started…Mitigation actions for your inexperience

Sunday, December 4, 2016

Retrospectives can generate an enormous amount of input in the right circumstances; which allows for a rich investigation of how to improve the team. However there are some situations which can lead to an input drought; and the prevention of team improvement. I have found that the list of questions at the end of this article can be used to easily prompt a team to generate input which leads to an effective retrospective and steady improvement of results.

There are four situations in which these questions prove particularly useful:

One: Team transforming from command and control culture

When transitioning to agile from a strong command and control environment, many team members say as little as possible in Retrospectives. They are used to being told what to do, and do not want to seem like the ‘trouble maker’ by pointing out obvious issues. The prompting questions help them to find something that the feel comfortable providing input on. The more often they provide input in retrospectives and don’t get in trouble for it, the more useful information they will provide in the future.

Two: Team is new to retrospectives

Teams that haven’t done retrospectives in the past often don’t understand the scope of what can be discussed. To aid the explanation of scope and to help bring out information from quiet team members the following list of questions is often useful. Again for teams transitioning from a command and control culture the scope of what they could change in the past was very limited. This compounds their reluctance to speak up.

Three: Retrospectives stagnating; due to repetition

For teams that have done many retrospectives; there can come a time where they run out of things to discuss. The prompting questions help them to broaden their view and finds topics worth discussing as a team.

Four: Scrum Masters

For the Scrum Master it will be worth reading these questions prior to each Retrospective and working out which questions could be used to prompt discussion within the team.

Retrospective Prompting Questions

Delivery

Is our team delivering as fast as possible? If not, why not?

Why did the extra tasks appear in the sprint?

Why were User Stories/Tasks not completed?

Why were some User Stories/Tasks, only partially completed?

Did the team over commit?

Was the team reliant on one person/skill set to complete a task?

Were any milestones missed?

Were last Sprint Retrospective actions items completed?

Where our estimates accurate? Both Story Points and hours?

Quality

What was the quality of our deliverables appropriate?

Did the Review/Demonstration make you proud to be a member of this team?

Was the test coverage (both automated and manual) sufficient for our needs?

Did our documentation provide the information that we required to complete our jobs?

Did rework hold us back this sprint?

What was the cause of the bugs/tickets that we worked on this sprint?

Scrum

It has now been X sprints that we have been using Scrum, do we think our situation is better or worse since starting? What is better? What is worse?

What did everyone work on immediately after the Planning meeting? Why did people work on items other then high priority User Stories?

Why were low priority tasks being worked on, while high priority user stories were on hold?

Was the Product Backlog ready for use at the planning session? Prioritised, estimated, enough detail?

Did the Burn-down Chart realistically represent the progress of the team?

Did everyone view the Burn-down chart as useful?

How did everyone contribute to User Story value?

Is everyone happy with how the Stand ups are working? Can they be improved?

Is everyone happy with how the Reviews are working? Can they be improved?

Is everyone happy with how the Retrospectives are working? Can they be improved?

Were the actions created from our last Retrospective completed?

Were the actions created from our last Retrospective beneficial?

Communication and Team work

Did anyone in the team do outstanding work that should be acknowledged?

Saturday, November 19, 2016

In late 2014 the delivery team working on the Copyright Hub as part of the Digital Catapult UK where a bit confused about the upcoming Beta Release. They were getting mixed messages regarding what the release was for, when it was due, and what were the most important features to be included. To resolve this situation I gathered the delivery team and the customer representative and ran a collaborative Release Vision Exercise, which is described below.

Release Vision (45 minutes)

Who? Who is the audience of the beta release?What? At a high level what will the beta release contain? Aim for no more than five bullet points.Where? Where will it be used? All industry sectors? All parts of England? Europe, etc.Why? Why would the users and stakeholders make the painful effort to change their existing habits and migrate to this new product?

Strap Line…What is a one sentence summary that we could use internally? LITMUS TEST: Can the delivery team come up with a strap line that they and the customer representative agree with?

The list was brainstormed, then discussion followed by dot voting determined the winner.

Release Levers (10 minutes)What is the order of importance of the following items? Please note they must be ordered, i.e. there cannot be two priority one items.

Scope – number of features included in the release (more is important)

Cost – project budget / number of people involved (low costs is important)

Schedule – when will it be released (earlier / on time release is important)

Value – Usefulness and usability of the included features. (user experience is important)

The blue numbers are the aggregate result of the Product Owner and Customer Representatives separate votes.

The end result

This process surfaced some key issues that the customer representative and Business Analyst (acting as Product Owner) disagreed upon and allowed them to resolve these differences. It also provided clarity to the delivery team regarding what they were being asked to do. The end result was a successful release that has changed the face of copyright on the internet forever: Video of Launch Party

Sunday, November 13, 2016

Solving problems in this complex world can be a huge
challenge. The Five Whys is a powerful technique in our hunt for the root cause
of an issue; however it rarely provides the full answer. Combining Tree Root
Diagrams with the Five Whys can ensure that your team gains a full
understanding of the root cause(s) of the issue. Once you know the root cause(s)
a permanent solution is only a few simple actions away.

A Tree Root Diagram captures all of the causes linked to an
issue in a downward expanding tree of causes. These diagrams often look like
the root structure of a large tree. They are most useful when a group of people
is collaboratively solving a complex problem.

The approach is straight forward: on a large whiteboard
write your issue (really the symptom) in the top middle part of the whiteboard.
Ask “What caused this to occur?” Write a very brief summary of each cause that
is mentioned and draw an arrow from the symptom to each cause. Now repeat for
each cause, building up your tree as your examine each cause. For each Root
Cause you identify, circle it and come up with an action or two to address it.
List the actions near the Root Cause and draw a line from the actions to the
Root Cause.

Benefits of Tree Root Diagrams

Finds multiple causes of a single symptom; including related
issues.

Visualizes the relationship between the symptom and its many
causes.

Visually links actions to the Root Cause the group is
addressing.

Allows the group to discuss tangential topics then return to
the core issue without losing track of what they were up to.

Acts as a record of what the group discussed and agreed
upon.

More Examples

A simpler example

An example of when it is quiet linear.

A complex example

How I stumbled onto Tree Root Diagrams

Around July 2015 I was coaching some new Scrum Masters in
effective problem solving and usage of the Five Whys. I keep hearing myself
suggest to them to write down each answer to Why that the team called out. My
intention being to get them and the team realized that the first answer is
rarely the root cause. I quickly realized I was not doing this myself and set
out to walk my own talk. What I found when I made a concerted effort to write down
the causes, was that there were often multiple possible answers to each Why.
Hence my notes quickly turned into tree diagrams which I labelled as Tree Root
Diagrams and have used ever since.

Ishikawa diagrams

Tree root diagrams are similar yet different to Ishikawa
diagrams turned 90 degrees. Ishikawa diagrams focus on categorizing the
different causes in a hierarchy. Tree Root Diagrams focus on the linkage
between causes; of potentially very different categories.