RSS

Monthly Archives: August 2014

What is the problem you are trying to solve?

I had an interesting initial conversation with a couple of IT Directors this morning. One of their questions stood out for me: “Our teams aren’t meeting their commitments. What should we do to fix the teams?”

My first internal reaction was, “You don’t need to do a thing to ‘fix’ the teams.” My issue with questions of this ilk are:

  1. Why do managers assume the problem is with the team or teams? Remember, half-a-century ago, Deming pointed out that 95% of the problems are systemic problems. And guess who is responsible for the system?
  2. It’s easier to blame others than to take the time to reflect and introspect about how we ourselves are creating the conditions for these problems to come into being — problems we then keep complaining about.
  3. Why do managers (and team members as well) not spend a few minutes thinking about what the problem really is — the root cause and not just the manifestation — before leaping to conclusions?

In this case, there are numerous things that could be keeping the teams from meeting their commitments — lack of skills, lack of appropriate training, over specialization, silos, handoffs, interference from without within the sprint, pressure to commit to more than appropriate, changing priorities, lack of alignment with other groups these teams may be dependent on, technical debt, dearth of testers, large batches with little flow — stories being delivered towards the end of the sprint, large stories, unclear stories, unnecessary steps, non-value add activities imposed on the teams, delays and waiting, and so on and so forth. Without understanding what is actually causing the problem, it’s very likely that you’ll end up solving the wrong thing; thereby, creating even bigger problems.

I use a simple diagram to clarify the issue and teach techniques like 5 Whys, Diagram of Effects, ToC Thinking Tools (especially the CRT), etc. to help teams and managers understand problems and fix root causes so the problem goes away once and for all.

Analyzing a Problem

Analyzing a Problem

How do you handle such situations? Do you have favorite techniques and tools you use? And how much time do you spend teaching problem definition and problem solving techniques?

 
Leave a comment

Posted by on August 20, 2014 in Agile, Improvements

 

Tags: , ,

Practice “X” doesn’t work for us so let’s throw it out.

A few months ago I had an opportunity to informally assess a team that had been doing agile (using the term very loosely here) for 4 months. During my 1-on-1 conversations with the team members, I kept hearing the same refrains along the lines of, “The <choose an agile practice or ceremony> doesn’t work for us so let’s stop doing it.”

If a practice isn’t working for a team and they want to change the practice that’s fine as long as they recognize why it isn’t working. But this group had a knee jerk reaction to throw practices out instead of inspecting, reflecting, and adapting. The questions that they should have asked themselves before reaching a decision:

  • Other teams sitting nearby seem to find this practice very valuable. What are we doing differently?
  • Are we doing this the right way?
  • Did we inadvertently modify the practice to fit our context without realizing the benefits we would lose?
  • Did we try and learn from the instances where the practices didn’t seem to bear fruit? And did we then change the way we worked?
  • Were we disciplined in following the practice or using the technique? Or did we cut corners or drop-off bits because it seemed too hard?
  • Do we have a tendency to blame the technique/practice/method first and not even think about how we are contributing to the problem? Do we see failures as problems with the practice instead of looking at failures as feedback mechanisms on our approach?
  • Is the practice not working because we have serious organizational dysfunctions that are getting in the way?

Have you encountered similar behavior before? How did you handle such situations?

 
1 Comment

Posted by on August 20, 2014 in Agile

 

Tags: ,

The Daily Scrum — More Than Meets the Eye

The daily stand-up is a deceptively simple way of digging deep into what is happening within the team. It is a lot more than just the three question; it is a mechanism for identifying the areas of spin and churn and also for ensuring that everyone understands:

  • What is blocked?
  • What is being worked on?
  • Who is working on X?
  • When will X be done?
  • What am I doing/supposed to be doing?
  • What are everyone’s top 3 priorities?
  • Is anyone struggling with their task? Can I help?
  • What will be done today?
  • What is ready to test?
  • What issues/impediments need to be discussed?
  • What is critical?

The daily scrum is also an opportunity for team members to share briefly — details can be discussed in an off-line session — what they learned within the past 24 hours that others could benefit from. Finally, it’s an opportunity for team members to ask themselves, “What can I do right now to advance tasks to a done state on the highest priority incomplete stories?”

So, if your team doesn’t meet daily for the stand-up, their answers to, and their understanding of, the above questions will be stale and will detract from their ability to get stories done quickly.

 
Leave a comment

Posted by on August 14, 2014 in Agile

 

Tags: , ,

Focus on what is possible and has the best chance of making an impact

As a coach, you’re most likely never going to have an ideal situation where everything is the way you’d want and everyone thinks and behaves the way you’d like. Instead, you have to quickly assess the situation, come to grips with it, and then do whatever you can to move the client forward. Your goal should be to move the client up a notch — e.g., from a 3 to a 4 (on a 10 point scale) — as soon as possible instead of worrying about perfection (10). Focus on achieving the things that are possible, taking into account all the political rivalries, constraints and dysfunctions that exist in any organization, and don’t waste time on pursuing the impossible. Likewise, your recommendations should focus more on what’s possible and has the best chance of making an impact – instead of on what’s theoretically “right.”

Start where you are. Use what you have. Do what you can.
— Arthur Ashe, World #1 Tennis Champion. 1943 – 1993

 
1 Comment

Posted by on August 12, 2014 in Agile

 

Tags:

Inside-out vs. Outside-in approaches to improvements

Inside Out — The usual approach is to look at our existing problems (usually operational) and solve them or to look at the existing processes and change them to make them better, faster safer, or cheaper, in order to better serve customer needs. However, the link between the problem being solved, the proposed solution, and the customer need is frequently tenuous and usually based on unshared, unexamined, unproved assumptions. More often than not, the time and effort expended does not justify the eventual outcome.

Outside In — Start with the customer’s goals, determine what capabilities we need to meet those goals, and then what actions we need to take to build those capabilities. Actions could be changes in leadership styles, process modifications, or changes in organizational structures, rules, policies, norms, etc. This works really well for organizational transformations. For product development, techniques that can be useful are Gojko Adzic’s Impact Mapping and Tom and Kai Gilb’s Stakeholder Value & Product Quality Requirements defined in Evolutionary Project Management.

 
Leave a comment

Posted by on August 10, 2014 in Improvements

 

Tags: ,

Are you fixing the right problems?

Just because your team is faced with a number of problems doesn’t mean you should solve all those problems — that might be pretty wasteful, actually. Instead focus on and solve those few problems that are keeping your team from achieving the next milestone, or the desired measurable objectives; ignore the rest.

And when you do attempt to solve a problem, make sure you are tackling the root causes and not the symptoms. Poor inadequate solutions often lead to other bigger problems. Remember Sevareid’s Law, “The chief cause of problems is solutions.”

 
Leave a comment

Posted by on August 10, 2014 in Improvements

 

Tags: ,

Kaizen in a nutshell

Kaizen is continuous improvement of people, processes and systems. Continuous in the sense that everyone has a mindset of **always** trying to get better — kaizen is neither a one-off or infrequently scheduled event nor a sprint tacked on right before a software or product release. Neither is it a project management approach. It is, however, a scientific method that uses the PDCA/PDSA experiment cycle and builds people’s capability of spotting and eliminating waste and solving problems. It is also a philosophy and a way of being — recognizing that there is always room for improvement and that everyone in the organization can contribute to improvement.

Gemba Academy’s “Ten Commandments of Continuous Improvement” summarize the philosophy well.

The 10 Commandments To Continuous Improvement are:

    1. Open your mind to change
    2. Think “Yes we can, if…”
    3. Always attack the processes, not people
    4. Seek simple solutions
    5. If it’s broken stop and fix it
    6. Use creativity, not capital (Use your wits not your wallet)
    7. Problems are opportunities in disguise; welcome them as gifts
    8. Fix the root cause: ask “why” five times (instead of who)
    9. The wisdom of many is better than the knowledge of one
    10. There is no final destination on the improvement journey

Remember, Kaizen is small gains that add up over time. 1% improvements in things you do may not seem like much now, but the cumulative gains build-up over time.

 
Leave a comment

Posted by on August 10, 2014 in Improvements

 

Tags: