February 4, 2012

Posts Comments

BigVisible Blog

Moving beyond the 5 Whys

December 19, 2011 By Alex Singh 1 Comment

The 5 Whys technique is a critical component of the Toyota Production System. Taiichi Ohno, described it as “the basis of Toyota’s scientific approach … by repeating why five times, the nature of the problem as well as its solution becomes clear.” The underlying premiss behind the method is that a questioner can trace the chain of causality by drilling deeper. The questioner begins with the problem statement and repeatedly asks “Why did that happen?” multiple times to clarify cause/effect relationships.

In software development, however, the technique has some shortcomings:

  • Problems and their causes are not always linear and you cannot always trace a symptom directly to a root cause by asking the 5 Whys.
  • Sometimes causes are separated, in a significant manner, by time and space from the effect; this makes identification of the relationship difficult.
  • Practitioners at times aim for the single root cause, but each question could elicit many possible root causes.
  • The 5 Whys technique works well in simple and complicated environments; not so well in complex and chaotic conditions (see the Cynefin framework for definitions). Multi-causality, contributing factors, and not-so-obvious variables if ignored can lead the questioner to the wrong conclusions.
  • Results are highly dependent on the questioner’s ability — stop too soon (at the symptom level) and you don’t reach the lower level root causes; stop searching after the first right sounding answer and you miss out on other plausible causes; treat a long-lived and unchallenged statement as fact and you limit avenues of investigation.
  • The questioner’s level of knowledge is a limiting factor — ignorance can cause people to overlook causes they don’t already know about.
  • Results aren’t repeatable and different people can identify different causes for the same problem.

It’s important to realize that we have more than the 5 Whys method in our toolkit. We can flow chart the process, use the Current Reality Tree (CRT) thinking process, or use Gerry Weinberg’s Diagram of Effects (my favorite). Which techniques do you use?

Filed Under: Agile Coaching, Experience from the Field, Facilitation, Tools Tagged With: , ,

The ScrumMaster ’3 step’ Dance.

December 11, 2011 By Mike Dwyer 2 Comments

The other day, someone asked.  “So how do I do this servant leader role ? How do I develop self-organized teams,  not use command and control, and still have the capability to meet organizational expectations?” It’s not the first time, in fact it may be the most persistent question asked over the past ten years.  I don’t have a silver bullet answer, but I can share with you what I found worked for me and I share with the people who come to my classes.  I call it the ScrumMaster ’3 Step’ Dance.  It’s not hard to do, the difficulty is in finding a rhythm that suits you.

Step 1. Lead from the front using the leader part of servant leader. Use this when the team is lost, going off the rails or about to run back into the burning barn of traditional project management.  As soon as the team gets their bearings, starts being honest with themselves, or chooses not to get burned again, move immediately one step back and to the side.

Step 2. Coach from the side. Be there on the sideline giving support, offering suggestions and providing guidance. Shift to Socratic method.  Once the team gets their confidence back, take another step back, moving behind the team.

Step 3.  Mentor from the rear.  look for patterns, learn how the team(s) are moving ahead through their challenges so you can lead them when they ask for help.  Remember you are now a firemen always ready to go when the team rings the bell.  When you get to the fire you’ll know which steps to take.

Filed Under: Agile Coaching, Agile Transformation, Leadership Tagged With: , , , , ,

Candy Driven Development

December 5, 2011 By David Bland Leave a Comment

Ever walk into the kitchen of a technology company? Chances are you’ll find a mind boggling supply of candy, snacks, treats and a variety of caffeinated drinks. One could just pass this off as the bad eating habits of pale geeks who go home after work and live in their parent’s basements, but I’m beginning to believe something deeper is at work here.

New research leads me to believe that we may be collectively suffering from ego depletion.

Ego depletion is the idea that self-control or willpower is an exhaustible resource that can be used up. Interestingly enough, sugar (or glucose) intake helps us prolong our ability to make decision after decision throughout the day.

Initially it sounds far fetched, until you think about all of the decisions you make throughout a work day and how they correlate with your sugar intake.

Consider the number of decisions you had to make in order to get to work this morning. Now once you’ve sat down and booted up your machine, imagine how many decisions you make before you start to even code. After you’ve started coding (or writing your tests if practicing TDD) imagine how many decisions you continue make in the span of just 1 minute.

If you do the math you begin to realize that you make a staggering amount of decisions throughout the course of just one work day. Many of these decisions are under pressure with serious implications.

In addition to ego depletion, research has found that these decisions can be broken down into pre-decision and post-decision processes.

A prolonged period of pre-decision is not ideal for a team that thrives on quick feedback loops.

I believe we can use this new found research to help our teams be in situations where they can make the best decision possible.

Daily Standups - Urge agile teams to have the daily standup in the morning if possible. It is our daily plan and we need our team focused as we make decisions on what we are about to do.

Retrospectives - Bring candy or snacks into the retrospective. Team members are more likely to forget their manners when suffering from ego depletion. It isn’t just people, it even happens with man’s best friend too.

Iteration Demos - Schedule these early and bring muffins, donuts or pastries along with some form of juice. If the Product Owner is accepting the work, he or she needs to have the mental fuel to make the tough decisions.

Feedback Loops - How long does it take to compile and run tests locally? How long does it take to deploy a build to test or production? How long does it take to get an answer from the business on feature question? All of these affect pre-decision time spans and deplete willpower.

I believe if we can align our agile and scrum coaching techniques with these findings, the result will be a team that is in an environment where they can repeatedly make good decisions.

Filed Under: Agile Coaching, Agile Transformation, Product Development, Project Management Tagged With: , , ,

Three Simple Tools for New Teams

November 30, 2011 By Scott Dunn, CST, PMP 1 Comment
When I am delivering Certified ScrumMaster (CSM) classes or starting up new agile teams, I share three simple tools that really help collaboration: creating a working agreement (also called team agreement), the art of the possible, and the fist of five. Based on feedback, these three items are often some of the important tools that team members take back and use immediately. Below is a simple way to introduce these by facilitating creating working agreements with your agile team.

Photo by Greencolander via Flickr.

Before you kick off your new agile team, get the team together and let them know the goal is to come up with some team agreements so that we all agree on how we’re going to work together. You might have some ideas, but first go around and hear others first. If you’re in a large group, pair up, otherwise each person can individually write down one statement about how their time together should be – everything from working hours to working conditions. Now collect these and put them on the wall, under the title “Working Agreements.” For general work, I often hear: take personal calls out of the working area, headphones on for music, keep your chat program on, put a flag or sign up if you don’t want to be interrupted (for less than an hour), shower regularly (seriously), no eating fish at your desk (yep, that too). Some common ones for meetings that I’d recommend are: one conversation at a time, start and end on time, electronics by exception (that is, no cell phones or computers unless it’s an emergency and everyone understands that), and have an attitude of the art of the possible.

The art of the possible means keeping an open mind that something covered here could work or might be true, even if you disagree, instead of an attitude of “that could never work here” (even if that is your experience). There’s always a first time, and the difference of our attitude, effort and approach differ vastly when something “just might be” possible, rather than impossible. MacGyver believed in the art of the possible.

Now that we have everyone’s recommendations, decide on what the final working agreement list will be. My preferred way of collaborating on quick yes/no group decisions is with the technique called the “Fist of Five.” When you’re in a group deciding on something (such as where to go to lunch that day), you can simply say the recommendation and then have everyone hold up one to five fingers. The number of fingers represent where they stand: 5 means they love the idea, 4 means they like the idea, 3 means they’re not that happy but they won’t get in the way, 2 means they have some questions or concerns that if answered they’ll get on-board, and 1 means “No way, ever, never!” (and make sure the one finger is the index finger…) Fist of five is a great way to hear everyone’s voice and quickly see who’s not in agreement and why (and then work to get them in agreement).
I hope these tools help your team get off to a great start.

Filed Under: Agile Adoption, Agile Coaching Tagged With: , , , , , , ,

Impediment Colored Glasses

November 19, 2011 By David Bland 1 Comment

impediment – a hindrance or obstruction in doing something: “an impediment to progress”.

When you are an acting ScrumMaster or Agile Project Manager, it is common to seek out impediments so that you can help to remove them. Before you know it, impediments seem to be all around you ranging from the individual, team and organizational levels. A person can quickly feel consumed and overwhelmed by this new found responsibility.
Impediment Colored Glasses
A few years ago I was having a conversation with a colleague about all of the impediments I’d uncovered and how I needed to remove them as soon as possible. About half way through the conversation he interjected “These are not impediments, these are merely the tasks we need to complete our user stories”.

Then it dawned on me, I was so focused on removing impediments that I had begun to view our tasks as blockers to progress.

I was wearing impediment colored glasses.

Luckily for me I was pulled me back into reality before I started having conversations with the team on how every task was a blocker. I may not have made it out of the team room alive.

So how can you determine what is and what is not an impediment?

Tip #1 – People are not impediments
As tempting as it may be, do not label people as impediments. Once you label a person, you begin to subconsciously dehumanize. People can certainly be challenging to work with, but once you cross that bridge to labeling them as blockers it can be difficult to bring them back. If you find yourself doing this, you may very well be wearing impediment colored glasses.

Tip #2 – Impediments are often types of waste
If you find yourself struggling to determine whether something is or is not a blocker, try comparing it to the common types of waste in lean.

  • Transport
  • Inventory
  • Motion
  • Waiting
  • Overproduction
  • Over Processing
  • Defects

These types of wastes do not always line up 1-to-1 with your blockers, but they can be a helpful guide in determining whether or not you are off base with your assessment.

Tip #3 – Ask your team what they think
It was a team member who pulled me back into reality, however not all team members are assertive. Who’s to say that the ScrumMaster is the sole designator of impediments? Ask your team what they think. It will give you the opportunity to do a bit of root cause analysis. Quite often, what you see as a blocker is only a symptom of something deeper.

These are just a few tips that I’ve found useful navigating the treacherous landscape of impediments.

What else has helped you identify blockers with your team?

Let us know in the comments below.

Filed Under: Agile Coaching, Collaboration, Experience from the Field Tagged With: , , , ,

The Journey from Analyst to Product Owner

November 7, 2011 By Brian Bozzuto 4 Comments

I owe a special thanks to my colleague Jason Novack for pairing with me recently on a presentation to the Boston International Institute of Business Analysts (IIBA) about making the leap from business analyst to a product owner. It was a great experience that really got me thinking about some of the journeys I’ve seen analysts go through as they moved into Agile teams and began playing the role of Product Owner. This blog encapsulates some of the concepts we came up with in that discussion and the archetypes I’ve seen for behaviors that these people go through, specifically analysts from large organizations that find themselves dropped into the role of product owner.

[Read more...]

Filed Under: Agile Adoption, Agile Coaching, Agile Transformation, Leadership, No Tags, Product Development Tagged With: , , , , , ,

The Math Behind Agile and Automation

October 11, 2011 By Jim Elvidge 3 Comments

Every once in a while, we encounter individuals on our teams who have a healthy dose of skepticism about these new Agile practices they are learning. For those who tend to be scientifically-minded, or need more evidence than just a good story, I have found that it is important to give them real data to look at.

As an example, it is interesting to combine the usual Cost per Defect curve for a software project with a histogram that maps the probability or frequency of finding defects to the corresponding project phase. The result is mathematical support for both Agile as well as the value of Automation and good Agile QA practices.

Figure A below shows the typical Cost curve for a waterfall project (source: The Economics of Testing, Rice Consulting) along with an overlay showing the probability of finding defects in various phases of the project.
[Read more...]

Filed Under: Agile Adoption, Agile Coaching, Experience from the Field Tagged With: , , ,
« Older Posts
Newer Posts »