The Stinging Foot Spray Experiment: How data helps in emotional situations
“It stings too much!” cried my young daughter after the first spray of the medicine.
Mud at Latitude Festival
As a result of a muddy weekend camping at a music festival she had developed Athletes Foot for the first time. The only child-suitable treatment available at the chemist was a foot spray.
I had a dilemma; to help her foot heal as soon as possible we needed to continue to use the spray twice a day, but she was clearly upset and distressed by the stinging. It was difficult to tell how painful it really was. How to move forward?
“Could we do an experiment to work out how ‘stingy’ the foot spray is? On a scale out of ten, where 10 is the most painful you could imagine, how much does it hurt now?”
“10”
“OK, could you hold this stop watch here and each minute we check how much it hurts?”
And so we drew this simple chart, and made recorded her scores.
The initial observations from the Foot Spray Stinging Experiment
This was helpful for my daughter, my wife and I. It showed that although it felt very painful, the pain halved after the first minute and was gone completely in four minutes.
A problem was that we needed to keep using the spray twice a day. I decided to try to frame it as an experiment where we could test predictions.
“How stingy do you think it will be when we use the spray this evening?
“A 10 again”
It was a 9.
We kept doing this and chart below shows the results. Each time we used the spray the stinging was less and it stopped stinging quicker. By the third day my daughter was actually eager to have the spray and was proud of the fact that she could show it no longer stung.
The final results of the Foot Spray Stinging Experiment
This episode highlighted several points for me. The first is the value of jointly designing ways to test disagreements and gather more information. The second is that in situations of high emotions (or pain) there is value in having measures (even subjective ones like ‘stingingness’) to overcome cognitive biases (like magnifying recent events and incorrectly predicting the future). Although this is a personal example I think these benefits are applicable to a wider situation.
How to study the flow of work with kanban cards
Physical kanban walls, with index cards, present powerful and easy ways to collect data and encourage the team experiment with improvements to our process. I’ve come across a simple technique of writing a ‘column tally chart’ on the bottom of each index card as it crosses a kanban board to help study and manage the flow of our work.
Each day at stand up we write the first letter of the column that the card ends up in on the bottom of the index card after we’ve finished discussing it. This acts as a simple tally chart of the how many days it takes the card to cross the board, as well as providing information about where the card spent its time. Here’s an example of a card:
An example kanban index card with a column tally chart
In this case you can see the card in the centre of the photo took three days from starting development to completion. The card was in the Development column (D) the first time the team discussed it at stand up, the second day it was in the Test column (T) and at the last stand-up it was in the Done (X) column.
Studying by asking questions
We use the column tally chart information on each card to ask questions like:
- What kinds of work take us longer? Where is the time taken?
- Are there any patterns around which columns (steps) in our workflow take time?
- Where we have to hand-over work between different people on the team (such as code review or testing), do we see delays?
- Is a step in our process, like code review, adding a burden to the time it takes us to complete work?
- Are any tasks ‘bouncing back’ from a later step? Which steps are they bouncing back from?
- Are they trends in how long work is taking or how it is flowing compared to earlier periods?
For situations where we estimated the work, the cards allow us see if there is a relationship between actual time and estimated time. When we are estimating future work we can check the actual times from earlier similar tasks as a way of improving our estimates.
Analysing the data in team retrospectives
We have been taking the cards into our team retrospectives and doing whole-team grouping and sorting exercises to see if we can spot trends in the way we are working. This achieves two goals; encouraging the use of data in retrospectives, and including the team in performing data analysis.
Kanban cards with tally charts arranged into a histogram as part of the team’s retrospective
As an example, in a recent retrospective we organised the cards into a simple histogram based on the number of days that cards took to cross the board. We saw that we had an increasing number of cards that took longer than in earlier sprints. There were two downsides to having cards that flowed more slowly across the board; psychologically team members felt better when they were able to report progress at each stand-up, and that tasks that were smaller generally took less time to test and were less likely to ‘bounce back’ into Development.
Experimenting with new approaches
We agreed a retrospective meeting action that the team would look out for cards that had been in progress for more than four days and raise a discussion after standup about whether we could break the work down into smaller pieces. We have been doing this for the last few sprints and it has worked well.
Improving our methods
One improvement we’ve come up with is to use a dot above the letters we write on the card to show that there’s something blocking the card from being worked on. This allows us to see the impacts of blocks on the end to end (or cycle time) for a particular task.
Have you tried simple data collection approaches like this? If so, what did you find? I’d love to hear your experiences in the comments.
Related articles
How Kanban visualisations and conversations enable process improvement
After deciding to adopt a new process a key challenge is to actually start doing it. This is the story of how a team I’m working with decided to carry out code reviews as part of our process, and how our kanban board helped us.
The kanban board helped us visualise this new step in our process and allowed us to see that despite our belief and enthusiasm in introducing code reviews, we weren’t actually doing them. Reviewing the board at the daily stand up meeting provided visual feedback that lead to productive conversations about what might be stopping us and how we could improve. After we implemented new behaviours the board highlighted whether we improved and allowed us to continue to monitor our behaviour.
- The team’s kanban board after we’d got rid of the queues, with no cards at all in the Code Review column.
Introducing the Code Review process: a focus on ‘just enough process’
At the team meeting where we discussed a code review step we wanted to introduce ‘just enough’ process to make sure we would actually do it. We agreed to do the smallest thing that could work and to avoid being too ambitious or strict in how we defined code review. We came up with the following rules:
- If the person worked alone they needed to ask someone else on the team to come to their machine and discuss the code.
- The developer who needed the code review was responsible for pulling another person in to do it.
- If two people paired on the task it didn’t need a code review.
- If the task didn’t need a code review then the developer responsible would say so at the daily stand up and if the team agreed, it could skip that step.
What the board showed next: Good intentions were not enough
During the daily stand up meetings in the first week of working with the new process, the team reported many tasks as “finished development” when they hadn’t been code reviewed. We started moving those cards to the right of the “In Dev” column. Within a couple of days it was clear that we had a queue of index cards to the right of the “In Dev” column.
We had a brief discussion on the queue of cards to the right of “In Dev” and we agreed that it was a sign that we weren’t doing code reviews in an effective way. We said we’d focus on doing code reviews and ‘unblock the queue’ that day.
At the next day’s standup the queue was still there. This illustrates an important point; changing the way we work is hard and sometimes good intentions are not enough. At that day’s stand up meeting we had a deeper discussion about what was preventing us from doing it and identified two major issues.
The first issue was a concern about interrupting other developers. We agreed that one solution was to do the reviews directly after stand-up, since the team had all been interrupted.
A second issues was making it more obvious which cards were actively being worked on “In Dev” and which cards needed a code review. To be more explicit we created a column on the board between ‘In Dev’ and ‘Waiting for Test’ called ‘Code Review’.
By the next day’s stand up the queue of cards in Code Review was gone and we haven’t seen a queue of work build up in code review since.
Visualisation and productive conversations are key to process improvement
The kanban board showed us that our behaviour wasn’t producing the goals we wanted. Seeing this and discussing it as a team helped us understand more about what was stopping us and allowed us to experiment and test new solutions, as well as providing ongoing feedback about whether the new process step was working effectively.
What’s your experience implementing new process steps such as code review? Have you found visualising has been effective in reflecting how well your doing? Have you redesigned the way you visualise things in order to help you act more effectively? Let me know your views and experiences in the comments.
This post originally appeared on Platformability: Insight from Caplin’s tech team
Related articles
- Conversations for double-loop mindset changes with Kanban (benjaminm.net)
Conversations for double-loop mindset changes with Kanban
You can watch the video of my talkfrom the Lean Software Systems Consortium (LSSC12) conference in Boston earlier this month.
Using the Ladder of Inference to produce Double Loop Learning conversations
Visualising work is a key part of the Kanban Method. In many situations it can lead to people realising there are problems or opportunities for improvement, which can be successfully accomplished by simply changing behaviour (single loop learning). However, in some situations, particularly where there could embarrassment or threat, these change may need challenging existing mindsets (called double loop learning). Using practical examples drawn from directly helping teams, this talk will present a model for understanding how we can proactively engage in conversations that increase the chances of capitalising on the value that visualising the work provides.
Here’s a review from Jack Vinson
Benjamin Mitchell used the topic of “what comes after visualization” to start a conversation of what to do once you’ve got some visualization. He particularly talked about Chris Argyris‘ Ladder of Inference (and expanded by Peter Senge), which he used as a way of thinking about how we see things and how we interact with our colleagues and coaching / consulting clients. He particularly warned about staying away from making assumptions and working at the levels of Select and Describe (rather than Explain, Evaluate, Propose Actions). Since Argyris is one of the promoters of double-loop learning, it is not surprising that Benjamin discussed the Mindset -> Actions -> Results learning loop. I liked the discussion of taking different actions to get results vs changing one’s mindset because the Actions aren’t getting anywhere like where they need to go.
Here were some reactions from Twitter:
Let me know your reaction in the comments.
The Art of Handling Elephants in the Room
When we spot and elephant in the room, or an undiscussable topic that isn’t being addressed, it is tempting to tackle it head on. However, just naming the elephant or telling people that they’re not discussing an undiscussable topic is rarely a productive approach.
Having spotted an elephant in the
room it is tempting to shout about it
Here’s a scenario from a team’s retrospective meeting:
The team had talked about a problem and had decided to hold a workshop to focus on that issue. Kelly, the external consultant, saw a problem that no one was mentioning.
“I think there’s an elephant in the room here!” declared Kelly
“Really?”
“Yes, there’s a proposal to have a workshop, but no one has mentioned that last time we ran a workshop no one turned up! This seems like an undiscussable topic!” said Kelly
There was general agreement that people hadn’t shown up for the last workshop. After some discussion the team decided “let’s not have a workshop then” and the meeting ended.
I think Kelly’s intention was honourable – how can I get the group to start discussing things to better understand the cause of problems and ways to avoid them in future.
However, in this scenario, Kelly didn’t get what she wanted – rather than get to the cause of their problems in the past, they just decided to bypass these issues and cancel the workshop.
Unfortunately I think Kelly’s behaviour may have contributed to the results she got including the unintended consequences, such as possibly reducing the chance that the team would feel comfortable talking about ‘undiscussable’ topics in future.
Problems with the approach
There are several possible problems I see with Kelly’s approach.
Unclear intent. Kelly raises the issue of the groups not mentioning that no-one attended the previous workshop, but she doesn’t state what her intention for mentioning it was. If you are not explicit about your intention for saying something then people will automatically invent their own reason, which may not have been what you wanted.
Negative assumptions about others’ motives without providing evidence. When Kelly makes the claim that there’s an “elephant in the room” it could be interpreted as her saying that the group were all aware that no one turned up to the previous workshop and that they were all deliberately not mentioning it.
Kelly doesn’t provide any evidence that others are all aware of the issue, or that they have made a deliberate decision to avoid discussing the issue. Kelly’s claim is high on the ladder of inference.
Making an assumption about someone else’s motive, such as thinking “this group is deliberately not talking about a problem they know to exist” is an example of an attribution. Making negative attributions like this without providing evidence can mean that people feel confused or unjustly accused. Once people feel accused then it increases the chance they will respond defensively or withdraw from the conversation.
No curiosity about how others see the situation. Kelly states her view to the group but doesn’t ask whether they see things the same way or see it differently. I’d assume that Kelly was acting as if her view was obvious to others. Since Kelly asked no questions about how others see the situation and expressed her view in a definite way, it reduces the chance that others will offer their view or that Kelly would find out if others saw the situation differently.
Changing the focus from conversation’s content to it’s style is challenging. Moving from talking about the topic of a conversation (“we should have a workshop”) to talking about the style of the conversation (“we’re not discussing the undiscussable”) is a high-impact change of direction. “Going meta” like this is often worthwhile but takes skill, time and energy. To justify the investment it is better to wait until you have solid evidence of a pattern of this type of behaviour. If it’s just a single instance it more effective to keep talking about the content (“how can we make sure people turn up to this next workshop?”) rather than the communication pattern (“we’re not discussing the undiscussable”)
A more effective approach
A more effective approach may have been as follows, with annotations in brackets on what I’m trying to model:
I’d like to check a concern I have about how we are discussing the plan to hold a workshop [share your intent] and see what other’s views are. My recollection was that the last time we planned a workshop no one showed up. I was speaking to Bob and Jane about this yesterday [share your evidence]. Do you remember the last workshop the same way or differently? [be curious about others’ views]
If there was agreement around the fact no-one showed up to the last workshop I’d continue:
This is making me wonder if we are avoiding talking about what happened around the last workshop [state your reasoning]. I would like to talk briefly about what happened so we can avoid the same problems happening with this workshop [state your intent]. In terms of the last workshop, would anyone be willing to share what caused them not to attend? [inquire into others views]
Let me know your view in the comments.
Hi, I’m Benjamin. I hope that you enjoyed the post. I’m a consultant and coach who helps IT teams and their managers consistently deliver the right software solutions. You can find out more about me and my services. Contact me for a conversation about your situation.
Image Credit: David Blackwell on Flickr
Management Improvement Carnival #140
I’m hosting this edition of Jon Hunter’s Curious Cat Management Improvement Carnival. It’s been published three times a month since 2006. Here’s my round-up of interesting management-related posts from the last month with a focus on the psychology of change and software development philosophies.
Change Artist Challenge #7: Being Fully Absent by Gerald Weinberg
For managers who want to create systems that allow people to do great work, one solid test is to see if the systems works without you there:
Your challenge is to take a week away from work, and when you get back, notice what changed without you being there. … Do you think you can’t do this? Then you have a different assignment … “If you’re going on a week-long vacation and feel the project cannot do without you, then take a two-week vacation.”
Forecasting misunderstood by David M. Kasprzak
David writes well about understanding the purpose of forecasting and reporting to avoid counter-productive fire-fighting management behaviour:
Forecasting has to do with long-term vision and strategy, measurement, and learning. Focusing on reporting without planning leads to delayed information and chronic “hot buttons” that require immediate attention.
When this occurs, the PDCA cycle is simply broken. The end result is a system where the people in the organization are in a constant state of “Do!” and “Act!” without any sense of why they are doing anything, or if their efforts have actually caused an improvement.
Matt Damon does it again by Ben Decker
One of the challenges for managers is how to present their views in a persuasive way. Ben Decker analyses the techniques Matt Damon used in a recent presentation to a rally against standardised test-score based funding for schools:
[Damon uses a story -] he weaves the point of his speech around his experiences in public schools. This personalizes the message, gives him credibility, and is memorable. When listing out all the growth he experienced in school, he brought it back to the point by saying, “None of these qualities that have made me who I am can be tested.”
This links in my mind with W. Edwards Deming’s statement that “the most important figures that one needs for management are unknown or unknowable …, but successful managers must nevertheless take account of them”
Is Thinking Allowed? by Tobias Fors
Continuing the theme of managers focussing on what is easy to see, and not what is important, Tobias writes about a manager challenging him for not typing (even though typing is not the bottleneck):
When we sit and think, it looks like we’re doing nothing. This makes it hard to think in many organizations.
Doing is what it takes to change the world, but if we don’t think a little first, how can we know if we’re about to change it for the better or the worse?
Leadership Coaching Tip: A Process for Change by Barbara Alexander
Starting with a reference to Deming’s famous quote “It is not necessary to change. Survival is not mandatory”, Barbara writes a summary of the work of Robert Kegan and Lisa Laskow Lahey including their focus on uncovering the competing commitments and underlying assumptions which keep us “immune from change”:
One example from Immunity To Change that many of us may relate to is the leader whose goal is to be more receptive to new ideas. As you might imagine the behaviors he’s doing instead of his goal include talking too much, not asking open-ended questions and using a curt tone when an employee makes a suggestion. His hidden competing commitments? You guessed it . . . to have things done his way and to maintain his sense of self as a super problem solver
Why progress matters: 6 questions for Harvard’s Teresa Amabile by Daniel H. Pink
Dan Pink reports on research behind “The Progress Principle” (affiliate link) which finds that “people’s ‘inner work lives’ matter profoundly to their performance – and what motivates people the most day-to-day is making progress on meaningful work”. The research showed that support for making progress is more potent than other motivators (incentives, recognition, clear goals, interpersonal support) although surveys have found that it isn’t rated highly by most managers.
Why Is Failure Key to Lean Success? by Michael Balle
In contrast to the support for making progress, Michael Balle defends Lean Sensei’s who leave teams feeling let down by focussing on more on what was not achieved than celebrating what was. Balle talks about improvements made without challenging underlying assumptions (similar to single-loop learning) represent “pretending to learning” and not “real learning (acknowledging and understanding why we were wrong about something)” (similar to double-loop learning). I’m hopeful that a “sensei” could learn to act in ways that could help teams meet the desired higher-order learning without having the potentially de-motivating impact described.
Agile Vs. Lean Startup by Joshua Kerievsky
Whilst the “X vs Y” style is unnecessarily combative, Joshua has done an interesting job contrasting the different practices and approaches between Agile Software Development and the Lean Startup approach (which uses Agile Software Development approaches to “build things right” alongside the Customer Development process focussed on finding what the “right thing to build” is).
Good question: how to unblock stuck conversations
When discussions become stuck in a ‘death-spiral’ of point-counterpoint views it’s useful to have some techniques to unblock the discussion. One great technique is to shift the focus from telling people about your views and start asking questions to understand theirs.
I was in a bid planning meeting at a large consultancy when the discussion started to enter a conversational death spiral. Manager A believed that there should be a project manager involved in the project whilst Manager B disagreed. The conversation shifted from a discussion to a disagreement – the difference in views hooked the participants into a verbal arm wrestle over who was right.
I realised that neither manager was asking any questions of the other. It was all “let me tell you again why I’m right”.
It was as if each person thought the other person was just failing to see what was obvious to them, so each was using an ineffective strategy of repeating their view again this time stronger and louder.
I fought back my impulse to ‘take sides’ and focus on what one side was missing. Instead I decided to ask a question to move the conversation forward:
Me: “[To Manager A] If we agreed to go with the idea of a project manager, could you say what that would look like to you? How much budget do you think would be needed?”
Manager A: “I think we’d need to use 5% of the budget”
Me: “[To Manager B] How does that sound to you? What issues would you see if 5% of the budget was used?”
Manager B: “I’d assumed it was more than that. If that’s all it would take then that works for me”
One well-placed question changed the nature of the discussion. The reduction in tension in the room was obvious.
My question was designed to take the other person “down their ladder [of inference]” and produce more specific observable data. By doing so it uncovered some assumptions about what exactly was involved.
Have you found switching from backing one side to asking questions about the other side’s ideas has helped unblock conversations? Share your views in the comments.
Hi, I’m Benjamin. I hope that you enjoyed the post. I’m a consultant and coach who helps IT teams and their managers consistently deliver the right software solutions. You can find out more about me and my services. Contact me for a conversation about your situation.
Image Credit: newneonunion on flickr
Ineffective pushback to a pushy manager?
How do you deal with a manager who believes that a software development team needs to go faster and should be pushed? I want to review some of the responses to my earlier blog and test the idea that they would create a productive conversation that would lead to effective outcomes.
How does our advice look if others reflect it back to us?
What were the responses?
I got responses from the the earlier post’s comments, twitter and the DZone Agile centre that were mostly from the team’s perspective.
I believe that the responses were intended to be helpful to someone in the manager’s position and raise some important issues. I’ve seen the results of teams accepting a request to “push harder” and in the majority of cases these have been ineffective, demoralising and created more problems down the track. My intent with the earlier post was to encourage a manager with these views to find a way to discuss differences in views in public in order to jointly design productive ways forward.
When handling issues that generate strong points of view it’s important to focus on not just ‘what is right’ but ‘how can I communicate this effectively?’
I’ve summarised some of the responses under headings from the three assumption level ‘rungs’ of the ladder of inference
Explanations:
- Thinking that pushing a team to go faster is a dysfunctional view and implies little intention to help
- The causes of poor performance are a management issue
- It’s probably not a speed of development issue, usually it’s about prioritisation and communications
Evaluations:
- There are too many assumptions in the question “how can I push the team to go faster?”
- Just going faster is the wrong goal
- Going faster or pushing wont help you reach your goal
Predictions / Proposals for Action
- Pushing has never worked and will never work
- Talk about it differently – say “pulling or enabling” to remind you that it’s about you helping remove impediments
- Focus on removing obstacles not “pushing people”
- The first step is for you to ask the team what you as a manager can change or what you can do to help.
- Ask yourself “is it a pattern that I keep having to push teams to go faster?” If lots of projects require a push then it’s not the team that’s the problem, it’s your planning!
Unjust high-level negative assumptions?
Looking at the comments from a manager’s point of view, they come across as high-level assumptions that are often negative towards the manager.
My assumption is that the responses were in reaction to the perceived unjust negative evaluation implied by a manager even considering “how could I push a team to go faster?” (the headline of the earlier post).
This highlights the importance of a manager with these views clarifying what’s behind them, and sharing them with specific concrete examples, to avoid creating defensiveness in the responses and becoming stuck in a point-counter-point argument.
It intrigues me that some of the responses may have created the same impact for a manager that they felt manager’s views had on them.
What would a manager think if told these views?
I realise that many of the responses were not intended to be directly said to the manager, but if they were I believe it would create defensiveness in the manager.
I doubt that the manager would feel listened to or understood.
The views were mainly stated in strong, rather than tentative terms. There was no mention of asking for more detailed observable data from the manager or any inquiries into what was behind the manager’s view.
How would people would avoid these negative views “leaking out” into the conversation through body language or tone of voice? As a manager (share your views in the comments) I could imagine thinking:
“These responses show people reacting defensively before they’ve listened or understood my view. They are telling me I’m wrong to think this way and I should start by asking how I could be different. It just shows that you can’t talk to a team about these issues”
Skilled unawareness and skilled incompetence?
Some comments advised the manager to take the team’s perspective and ask the team what they might be unintentionally doing to hinder the team and how they as a manager could help. This is useful as other people have a great ability to spot gaps or inconsistencies in our behaviour. Learning how to honestly ask for help from others is a worthwhile practice.
Yet, there was limited evidence in the responses of following that advice and thinking things through from the manager’s perspective and asking how they might be unintentionally contributing or how they could help.
This is an example where people, acting with good intentions, may be skilfully unaware of the fact they’re not following their own advice to others. This relates to the skilled incompetence demonstrated at a recent Agile workshop
I’d welcome your views in the comments. How productive do you think the responses would be if communicated to a manager? If you wanted to respond more productively to a manager who thought it was necessary to push the team what would you say or do?
Hi, I’m Benjamin. I hope that you enjoyed the post. I’m a consultant and coach who helps IT teams and their managers consistently deliver the right software solutions. You can find out more about me and my services. Contact me for a conversation about your situation.
Image Credit: Steve-h on flickr
How can I push the software development team to go faster?
A common challenge I’ve heard from Development Managers or Product Owners is “how do I push my software development team to go faster?” Here are ideas on how to approach this topic and have more productive conversations.
Understand your own mind
Start by clarifying your own mind, particularly your intention and motive for trying to get the team to go faster. If there increasing external pressures on the project, or it’s becoming clear that it wont be possible to get everything you hoped for by the due date then these are worth clarifying and sharing with the team.
Take the time to understand where you’re coming from and why.
This step may seem obvious, but it’s worth slowing this down and even talking it through with a mentor or trusted peer and asking them to play devils advocate and try to see things from the team’s perspective. It’s much better to get clear on your own intentions and motives than to mop up from an argument later.
Focussing on “fast” may have unintended impacts on quality
As the old saying goes, “be careful what you wish for” because you may get it, but at the expense of other goals. Sometimes to go faster you may need to use indirect or oblique strategies, such as removing the causes of bad quality or delays.
Seek to understand the situation by looking for evidence
If you think that the team is going slower than it could be, then get clear on the evidence you’ve seen or heard that leads you to this view. If you tell a team “I think you can push a bit harder and work faster” but can’t use specific examples that they recognise and understand then it’s likely they’ll feel unjustly accused. See my post on handling a team member who talks ‘too much‘ for an example of using directly observable data.
If you can’t be specific about why you think the team could be going faster, then be open and say so – “this is just a hunch” – You could ask the team to help look for evidence, by asking “If you were performing under or over-capacity, what would we look for as evidence?”
Talk to the team, sharing interests and concerns
Talk to the team about why you want to help them get more done. Share your intent for bringing it up. Start by sharing what you’ve seen or heard. Ask them what their view is of the evidence you’ve got? Do they see it the same or different? If they see it differently then get curious and ask them what they see that leads them to their view.
Sometimes the conversation can get bogged down under an escalating game of “no, your approach is bad for this reason, we should do my approach”. One way to avoid this conversational log-jam is to focus on the interests behind the positions, or more simply, ask them what they like about the solution they’ve proposed.
I’ve found the best way of encouraging more productive conversations is to learn and model these more effective approaches yourself.
Jointly design ways to tests disagreements and move forward
If there’s a strong disagreement between you and team about the level of productivity, then focus on jointly designing ways that you could move forward. Think about what data would persuade you from your point of view and ask the same of the team. Use work that is about to begin and come up with a way of collecting data that would make future conversations clearer.
This is a topic I may come back to in future and look at it from the team’s perspective.
Image Credit: gentlemanhog, on Flickr
Hi, I’m Benjamin. I hope that you enjoyed the post. I’m a consultant and coach who helps IT teams and their managers create more effective business results. You can find out more about me and my services. Contact me for a conversation about your situation and how I could help.
Removing the bubbles: solving bottlenecks in software product development
A challenge with software product development is visualising the work so that you can spot where there are delays in the process of converting ideas from “concept to cash”. This post shows how a cumulative flow diagram helped identify a pattern of queues over time. Removing these queues had many benefits such as fewer errors, increased team communication and improved team capacity.
Make the work visible
The first task is making the work visible. In knowledge work, such as software development, it is difficult to see the work being done, which is why a visualisation approach such as kanban can be so useful. Here’s a view of a kanban board from an earlier client team:
The kanban board is useful for a “moment in time” view, but it’s not possible to easily see patterns that might develop over time. Looking at the kanban board on a particular day doesn’t make it easy to answer questions like these:
- How long have these work items been waiting in this column (stage)?
- How long does it usually take for work items in this stage of the process to complete?”
- How often do we see queues in this step? How long do they last for?
- Are these queues a special event or do they happen regularly (touching on the difference between common and special cause I’ve mention in an earlier blog)
To find these answers and look more clearly for patterns over time we built a cumulative flow diagram (CFD, also called a ‘finger chart’) by counting the number of post-it notes in each stage (column) in the team’s process after each daily stand-up. Unlike my earlier post on using three forks and a hand-drawn chart to help a team improve in this case we used an Excel spread sheet.
Visualise the work over time to better understand queues (‘bubbles’)
The cumulative flow diagram for this team helped make visible that there were consistent queues of work in the functional testing and acceptance testing processes over time. These queues are visible as “bubbles” that develop in the cumulative flow diagram. See the highlighted in orange and red stages below (click the image for a larger version).
Do the detective work necessary to understand what causes the queues (‘bubbles’)
Around two-thirds of the way through the above chart (which covered about 36 weeks) we decided to focus on studying what was causing the queues to develop in functional and acceptance testing.
The functional testing involved someone other than the person who developed the functionality (user story) validating that it worked functionally (there were no obvious errors). Once functional testing was complete then the acceptance testing stage was performed by a business analyst or the product manager.
The team were releasing to production every second Wednesday. On the middle Wednesday the person who did the functional testing switched to doing the integration testing (ensuring the features which were created as a package to go to production worked individually and combined, as well as running a set of manual regression test scripts to make sure that the new functionality hadn’t had any impact on the rest of the website). During the week spent on Integration testing, no functional testing was done, which we believed was the cause of the queues or orange bubbles on the chart.
Creating a new policy to reduce the queues (‘bubbles’)
We sat down with the person who performed the Functional and Integration Testing and mapped out the schedule of their work across the fortnight between releases (see the hand-drawn diagram we came up with below).
We also mapped out a new “policy” that described what the person doing testing did for for the week spent integration testing:
While performing the Integration Testing in the week before the release, if there are any work items in the Functional Testing column, spend up to an hour each day doing them.
We experimented with the new policy for the last third of the cumulative flow chart. The cumulative flow diagram showed that the queue (bubble) in the Functional Testing (orange) step virtually disappeared, as did the queue in the Acceptance Testing (red) stage. The CFD not only highlighted the initial problem, but it also validated the experimental change we made in policy resulted in an improvement (it allowed us to answer the critical question – “did the change we made to our process result in an improvement?”)
It’s the system!
This example demonstrates how changing the way the work is structured can produce improvements without having to change the work that team members were doing. This example shows that the queues caused by the way the work was structured (e.g. the system we had designed) and not the work of the team members. It speaks to Deming’s ‘provocation’ that “95% of the variation [in how long the work takes] is due to the system and not the individuals”.
Benefits
There were many benefits to the changes that we made above:
- Removing the queue in functional testing meant that if a problem was found then the developer got faster feedback. Getting feedback faster reduced the time it took a developer to “get their head back into the issue” and fix the problems. It also improved the communication between members of the team – the developers were more likely to speak to the person who did test at stand-up about the work that was coming because they knew it would be tested quickly, rather than potentially sitting in a queue waiting for a week.
- By reducing the bottleneck in Functional Testing also reduced the same bottleneck in Acceptance Testing.
- The reduced “thrashing” from having issues discovered close to the release date meant the team’s capacity to do work increased.
- As there were fewer queues it reduced the pressure on team members, helping them feel less rushed which improved the quality of life for the team, reduced “rushing” leading to better quality and team morale.
Hi, I’m Benjamin. I hope that you enjoyed the post. I’m a consultant and coach who helps IT teams and their managers create more effective business results. You can find out more about me and my services. Contact me for a conversation about your situation and how I could help.
Benjamin Mitchell's Blog 