Dream Team – Part IV – Problem Solving

Posted: 4-8-10 in Agile Techniques, Dream Team, LEAN, Series
Tags: , , ,

Introduction

So far our team has decided on a set of values and we saw how they discussed the first one.

Now we join them as they get back from Starbucks to discuss again their values.

Problem Solving

The meeting starts again and once more I’m in charge of keeping time. John starts:

http://www.flickr.com/photos/ell-r-brown

Credits to Ell Brown

John – Hi guys! Welcome back! That was a nice coffee break. There’s something I’ve been thinking about and I’d really like to talk with you guys about.

I would like to discuss how each of you feel about problem solving. If we are to keep continually improving we need a systematic way of solving problems. At least that’s how I feel.

Jake - What do you mean by systematic?

John - I mean we need some way to archive the knowledge we gathered and the solution we had for each problem. This way we don’t need to repeat ourselves when solving the same problem, or even when some other team in the company wants to solve it. I read about how Lean companies do it with A3 report cards and I really liked what I read.

Susan - Even though I never worked with a formal way of solving problems, I often thought that we should have a way of publishing our findings when we decide something.

Christian - Can you give an example?

Susan - Sure. In my last project we were using Python as our main language. Some team members had experience with Django, while others preferred to use a more low-level framework like CherryPy. Preferences aside, we were expected to provide real-time dynamic data to more than a hundred thousand concurrent users, so performance was a key constraint for us.

Jake - Wasn’t there a benchmark you could use to decide?

Susan - We didn’t find one, so we ended up doing a thorough comparison of some Python Web Frameworks with many different production settings (Apache, Nginx, you name it). The results pointed us in the right direction.

The thing is that even though it was very cool to learn all that on a personal level, I feel that we didn’t leave behind any trail of this knowledge to other teams. Probably others have done this already, as was reported by our production team. If we don’t have a formal way of solving problems like this, we are bound to repeat this effort time and again.

John – I couldn’t have summarized it better. Thanks Susan for explaining what I meant. That’s exactly it. Knowledge generation is a problem that I really care about. What about you guys? What do you think?

http://www.flickr.com/photos/acidwashphotography

Credits to Dan.

Jane - We have that in the Design team. We always leave behind reasons and the discovery made to achieve a certain standard. I thought that you guys did that as well. I most certainly think we need to standardize how we decide things. This is key even within our team.

Imagine me and Christian finish some UI definition together and we want to share with you guys. I expect that you’ll want to know what were the assumptions and everything that led us to define the UI in the way it was defined, right? In order for that to happen there needs to be some mechanism to formalize knowledge. I really like this A3 thing, since I love sketching with pen and paper.

Christian - I don’t have much to add except that whenever I work in Open Source Projects, each project has its own way of preserving knowledge. Wikis, evolution proposals, docs, release notes, you name it. The key thing is that all successful projects share this trait in common. They all keep their knowledge at heart. I think we should do the same. I’d realy like to try this A3 technique, if we can change it later if we don’t like it.

Joseph – Hey, that’s brilliant. We agreed already on changing any process that does not work to something better, didn’t we?

All - YES!

John - Ok, we have a way to solve problems, but how are problems going to affect our work. I hear Susan has already worked here in the company using Stop the line methodology, right?

Susan – Yes, I did. And it was GREAT! The team used the motto: “The best time to solve a problem is RIGHT NOW!”. I learned later that this translates to the Jidoka principle in LEAN methodologies. It means that whenever we have a problem we stop working in whatever we are working to solve that problem. It seems counter-intuitive, since we’ll be “less” productive due to solving problems. The thing is even though this slows us down a little in the beginning, it speeds us up GREATLY in the long run.

Christian – What about bugs? Do we keep them in a bug tracker?

John - I reckon that if we keep solving bugs whenever we find them or whenever people report them, we should have 1 or 2 bugs open at any given time tops. Who needs a tracker to track 1 or 2 items?

Christian - Makes sense.

Joseph – So we as a team agree that whenever a problem arises the proper number of people in the team should stop as soon as possible to fix it and then find a way (at first an A3 report) to leave behind the knowledge on how it got fixed and why. Is that it?

All – Yep.

Joseph - Ok, I think we got our second value. The best time to solve any problem or defect is now.

Conclusion

Software Craftsmanship is a creative activity. As such we are confronted with problems and issues every day. It seems to be a good thing to just archive the issue in some way (bug tracker, tech debt card or any other way you can think of).

The problem with this is that the issues start building up and work starts to slow down. If you keep stopping the line whenever you find a problem, eventually the number of issues will decrease astoundingly. When the number of issues decrease, the speed of the team increases.

Refactoring code is one way to stop the line whenever you see code that is not clear. Fixing a bug you found while on another story is a way to stop the line. Acting on an integration problem with the customer is a way to stop the line. Introducing an improvement in the process is a way to stop the line. Anything that solves any problem RIGHT NOW is a way to stop the line.

There must be a way of publishing the results of problem solving in a way that people can benefit or refer to in the future. This leads to a better knowledge management and improved collaboration within the company. One suggested way of doing this is how scientists currently do: the scientific method. Since I already discussed it, I won’t say anything further.

If anyone has any suggestions on problem solving or stopping the line, please leave comments.

About these ads
Comments
  1. iashishi says:

    Loved your article. Thanks!

  2. heynemann says:

    Thanks iashishi! It means a lot!

    Cheers,
    Bernardo Heynemann

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s