Tuesday, October 30, 2018

Illusion of Choice


Let’s imagine that you have accepted an invite to hang out at my place. Creepy I know. Anyway, we are chatting and realise that it would be good to have some music playing. I say “pick an album from my collection, anything you like…”



Is there an album in there that you would choose to listen to? Was what you really wanted to listen to? This is the illusion of choice.

When I do this as a presentation, roughly half the attendees answer Yes to the first question, then roughly half of them drop their hand for the second question.

The illusion of choice is one sure way to ruin a Lean Start-up experiment. If you fall into the illusion of choice you are just re-enforcing your pre-existing notion of what is true. Should you continue to do this you will not learn the truth from your experiments. Read on to see what I mean.



When Telstra Wholesale started its journey to Open APIs; they came armed with a survey from their 200+ customers about which APIs were most important to them. Unfortunately, the list of APIs to choose from was provided by Telstra, a bit like my CD collection. The customers dutifully prioritise that list and there were some clear winners. Telstra built those APIs and deployed them, guess how many customers installed them? That’s right ZERO.

Thank fully Telstra Wholesale realised their mistake and went to their customers. This time they asked them how they used APIs, how APIs helped their business. Through this they found some common themes. They built and deployed the most needed API and got immediate uptake. The uptake increased as the expanded the first API and added more.

To apply this concept: Surveys need to be open not closed, otherwise we just confirm our own guesses.


The survey on the left is easier for our respondents to fill in and easier for you to analyse, however it is a closed survey. The survey on the left requires more effort from our respondent and a lot more analysis effort on your behalf; however, it is open and will generate more knowledge.

There are more approaches to keeping a survey open, but this is a key one.

Thursday, August 9, 2018

Who does the work requiring an expert in another team


Classic situation that tests our agile thinking… Team Neptune and Team Saturn are two mature agile teams. Team Neptune has a sizable chunk of upcoming work that centres around “System/Framework/Technology X” for which, one particular member of Team Saturn is the expert. The involvement of this expert will be crucial to the success of Team Neptune’s work. The challenge comes in how we can achieve the chunk of work without damaging / disrupting one or both teams.

“System/Framework/Technology X” It could be an ancient system that the expert helped to design and build with everyone else who worked on it now departed from the company. It could be a framework that the expert has deep experience in, etc, etc.

Generally what I see is that the expert is not needed for all of the work, however there is a central and crucial piece of work that they need to be involved in. You can see that in the diagrams below as the gray square “crucial piece” within the blue chunk of work.
I have seen three approaches used to handle this situation:



Approach A. For the duration of the chunk of work, the expert becomes a temporary member of Team Neptune and takes a leading hand in the work. They leave Team Saturn for the duration, attending none of their ceremonies.




Approach B. For the duration of the chunk of work, the expert takes a leading hand in the work; attending both teams ceremonies for the duration of the chunk of work. The expert remains a permanent member of Team Saturn. With a foot in both teams the expert is able to progress the work of both teams, with a focus on the Team Neptune work.



Approach C. Part of the work is allocated to Team Saturn who completes the work and hands it back to Team Neptune. The expert remains a permanent member of Team Saturn. Team Saturn also takes on a piece of work to provide knowledge transfer / training to Team Neptune. The expert attends design / planning ceremonies for Team Neptune and all of his Team Saturn ceremonies.

All three approaches involve sharing, helping each other, cross skilling and a big effort from the expert. Approach C has regularly proven to be the best approach when this situation has arisen. The reasons I believe delivers a good result are:
  • Both teams remain unchanged in regards to people; keeping their sense of team.
  • Clear focus for both teams, and especially for the expert.
  • No duplication of ceremonies eating into the experts’ time.
  • Keeps management mindset on split up the work to match the teams; i.e. promoting Stable teams.
  • Improved opportunities for members of Team Saturn to contribute to the work, hence improving the cross skilling.


How have you handled similar situations? What worked well for you?

Wednesday, May 30, 2018

Review of “Certified LeSS Practitioner” three day course by Venkatesh (Venki) Krishnamurthy


The first two days of Certified LeSS Practitioner were engaging and challenging. I went into the course thinking I could tweet interesting snippets as we went through; however there was no time for tweeting or distractions it constant thinking, doing, speaking. Hearing and following through the questions of others in the course was often very interesting.

The last day was not nearly as engaging due to several factors: I was tired, the content shifting to a light touch of the remaining rules of LeSS and Venki mentioning we were on track to finish early; consequent the participants but the brakes on.



Preparation
We were provided a long reading list of books, articles, videos and set a knowledge test. The test was not referenced/used in the training and some of the answer conflicted with Venki’s teaching. Several people in the class had fragile knowledge of scrum, did none of the pre reading and managed just fine. I had already consumed many items on the reading list several years ago. I re-read some of the articles, watched a few videos and found that they were not a cohesive set of learning materials. It seems they were every public article of LeSS published, with lots of duplication included. This reading list should be shortened significantly perhaps just to the rules of LeSS and a video or two for background.

We were told to bring laptops to work on, but only needed one per table of people to read the scrum guide. We were also encouraged not to take electronic notes, instead were handed 48-page exercise books and encouraged to take notes, which actually worked really well. My suggestion would be that laptops were discouraged during the lead up and printed copies of the Scrum Guide provided to each group.

Delivery
While the first two days were engaging, it felt like we were on a roller coaster blind folded; only Venki knew where we were going. Jumping from topic to topic without structure, without order, ignoring the printed slides, it was hard to know if we were making progress. While it sounds terrible I can’t make out if it is a strength or weakness of his delivery. As questions were raised we would deep dive on the topic, the reason why and potentially tangents to that topic.

Venki did make sure that everyone’s question were answered. Sometimes those answers were in the form of a question, or reference to a principle; forcing us to think through the question and find a suitable answer. I feel that this approach was key to the engaging nature of the training.

Content
The content covered in depth was
  • History of LeSS – If I have to hear “600 experiments” one more time…
  • Ten LeSS principles
  • LeSS is Scrum, what is Scrum, how are they the same, how are they different.
  • Systems Thinking
  • Causal Loop Diagrams
  • The why behind the LeSS Framework
  • The LeSS Framework (three pages of rules) and LeSS Huge Framework. Please note that this could be explained in two hours if done in one hit. Rightfully so it did not receive much more time than that through out the three days; after all we can always read the rules on the https://less.works


The content only lightly touched on was.
  • The LeSS guides


I found it interesting that Venki played funny videos after each break session. It surely lightened the mood, however only a few of them were directly related to the training course. Most of them had a tenuous connect at best.

Most of the interactive exercises were fun, interesting and embedded knowledge in us; such as designing a multiple team sprint planning approach, casual loop modelling of feature teams vs component teams. There were several interactive exercises that fell down in delivery and/or opportunities for learning. i.e. While searching for hidden post-its around the room with types of wastes written on them was fun, yet it delivered almost nothing in the way of knowledge.



What I took away
  • Use LeSS to descale / simply the target area of the organisation through empirical process control.
  • Don’ t use LeSS to scale up your existing agility.
  • LeSS is designed for a big bang change (limited to the target area of the organisation). i.e. The vast majority of teams MUST be fully cross functional feature teams, otherwise you are not doing LeSS.
  • The initial perfection vision of LeSS is a potentially shippable product increment every two weeks. Once that is achieved aim for one week.
  • Concept of understanding the System Optimising Goal of all systems you are interacting in / part of. I.e. What is the company/CEO’s System Optimising Goal? Is that the same goal as your area? Is it the same goal as the tool you are using?
  • Thinking in Systems: A Primer by Donella Meadows, is worth reading prior to the 5th Discipline by Peter Senge. “Thinking in Systems” will provide the though patterns that make it easier to digest “The 5th Discipline”.
  • Using a WIP limit indicates that there is a problem that you are not solving. Perhaps another team is flooding your team with work? Perhaps your own has an uneven flow?
  • Make all queues visible, then reduce/remove those queues.
  • Use LeSS Huge only when your one PO can’t handle the number of teams that you have. The 2-8 teams for LeSS is just a guide based on the worst and best PO’s they have seen. 9 teams is not the trigger point for LeSS Huge, it is purely down to the ability of the PO to handle the teams you have or not.
  • If you have LeSS huge try to only break out a new Product Area when you have 4 teams. This is so that the PO can keep those 4 teams effectively occupied. They have seen that having less then 4 teams for 1 PO often leads to starvation of those teams backlogs. So why do they suggest that use LeSS when you have 2 or 3 teams? The answer is that there is no better solution, better off using LeSS and potentially suffering some starvation than to not use LeSS when you have multiple teams.
  • Product Areas may be made up of multiple “themes” this is especially true when those themes only need a team or two to service them. E.g. your 4 team Product Area may be made up of 2 teams for theme A, 1 team for theme B and 1 team for theme C.
  • How can 1 PO handle 4 teams, let alone 8? The answer is to just to Strategy, Vision and Prioritisation. Leave the clarification of User Stories to the team who work directly with the customers. Cutting out this clarification effort frees up the PO to work with more teams.
  • When you need to seed knowledge across multiple teams; try creating a temporary “undone” team with someone who is strong in the desired skillset and stack the rest of the team with people who are keen to learn that skill. Temporarily they do all of the work related to the skill, once they have learnt the skill, the team is disbanded and they take their new found knowledge back to their feature team.
  • If you must have a distributed PO, place them in the same location as the customer(s) in preference to placing them in the same location of the team(s). The reason being they deliver the most value from better understanding the customers needs.
  • While LeSS demands that most teams are Feature Teams, it accepts that there will be some service teams, such as finance, admin, etc. It also accepts that the feature teams DOD may not be complete especially in the early days. That undone work will be covered by team(s) called “undone”. The name was chosen deliberately to be unappealing, because the aim is to get rid of those team(s) ASAP and have that work done by the features teams within the sprint.
  • Multi team Product Backlog refinement has recently been made the default over separate team Product Backlog refinement.
  • Have a clear product definition is crucial to a successful LeSS implementation. This definition should be as broad and as end user centric as possible.
  • The action plan from each team’s retrospective is shared at the overall retrospective. This is intended to prevent duplicated effort and worst still actions that interfere with each other.
  • The Overall Retrospective is held early in the next sprint, it is not held on the same day as end of sprint.
  • Every new role created in an organisation, disempowers another role somewhere in the organisation.
  • Financial matters are handled by the Product Owner in LeSS Huge it is still the single PO that handles the $$$.
  • Organisational agility is constrained by technical agility.
  • To constrain your causal loop diagram choose 3 to 5 parameters of interest before starting the diagram and focus on them. This worked during the training; however I am concerned that choosing/guessing those parameters up front indicates that you already understand the situation which you often don’t when you are creating a causal loop diagram in the first place. I will need to test this outside of a training environment


Overall Rating: 8/10

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

Saturday, December 10, 2016

Your teams 1st retrospective will be your hardest retrospective

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 

  1. Display the Prime Directive and read it out as part of your introduction.
  2. 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

  1. Ensure you have plenty of time to discuss the first topic
    1. Schedule 90 minutes for the retrospective, one hour is just not enough time
    2. Time box the early parts of the retrospective to ensure enough time for discussion at the end.
  2. 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!
  3. Use Tree Root Diagrams to help untangle the intertwined symptoms.




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

  1. Observe retrospectives run by more experienced facilitators.
  2. Pair with an experienced facilitator for your first retrospective.
  3. Delegate Time keeping to someone in the team.
  4. Delegate taking notes to someone in the team.


Mitigation actions for the Teams’ inexperience

  1. Circulate the retrospective objective and agenda ahead of time
  2. Provide the team with Retrospective Prompting questions a couple of days prior to the retrospective.