Heynemann – Just another dev

Introduction

Much has been discussed on this topic with even a website devoted to the subject. It had never caught my eye before reading Lean Software Development: From Concept to Cash, which is seriously one of the best books for insight on the craft of software development. Mary and Tom Poppendieck really know what they are talking about.

In my previous post I discussed how their book opened my eyes to W. Edwards Deming’s research into Profound Knowledge. Today I’d like to discuss a scientific approach to solving problems. This approach really got me interested since I believe that software development is more of a science than it is art.

Mary and Tom classify the problems that arise within organizations in systemic or not. The path to an excellent organization is to solve the systemic problems, thus enabling the company to deal with the non-systemic ones that will eventually appear.

“Ok, let’s fix all our problems at once then!” – No, that’s not the general idea. The idea here is to establish a culture of problem solving. Pick the worst offender, deal with it in a scientific manner and schedule the next problem solving “iteration”. It is key here that the problem solving process is not too frequent and not too sparse, otherwise it would generate disbelief in its purpose.

I’d like to contrast this with retrospectives. I’ve been in more retrospectives than I can remember. Most of them go along the ways of: what does really bother us, what do we want to do about it and let’s pick some items to work on the next iteration. There’s nothing wrong with that and I’m a *BIG* fan of retrospectives. I just think that there might be a better way to approach the actual problem solving (together with retrospectives, not to replace them).

A Disciplined Approach

I’d like to state that I’m borrowing heavily from Mary and Tom’s book on terminology, mainly because I honestly can’t say it better than they do. So if this post gets you interested, buy their book, read it and live happily ever after. First I’d like to quote them on this subject:

A disciplined approach to problem solving moves a team from wishful thinking to new knowledge, specific countermeasures, and permanent results.

Tom and Mary Poppendieck on Implementing Lean Software Development – From concept to cash (page 169)

What does that mean? As I said when talking about retrospectives, I’m assuming that the teams I worked on were always wishing that they could improve and do better. The key thing is how to turn those wishes into something specific and permanent. Turns out there are some very specific steps (borrowed from aforementioned book):

1. Define the problem
2. Analyze the situation
3. Create a hypothesis
4. Perform experiments
5. Verify results
6. Follow-up/standardize

Let’s see how we can go on about each of those.

Define the Problem

I often hear (and sometimes say) that “I want to deliver more” or “I want to pay tech debt” or some other broad-scoped wish. While those are broad, they are a good starting point in order to define a problem to be solved.

Identifying the problem could be as simple as to say that the team wants to find a way to improve test coverage.

Analyze the Situation

This step serves the purpose of providing enough information to the team for a confident decision on a set of experiments.

Usually gathering data that is as close to the problem as possible would be the best guess, meaning that if you are looking to improve test coverage, checking the codebase, previous attempts and the actual current coverage are good candidates.

Also this is the time to refine your problem. “Do we really need to improve coverage as opposed to improve test quality?” or “Do we need to add more acceptance tests or should we convert the current ones to functional or unit tests?”. These questions will also help into forming a hypothesis and a set of experiments.

Create a Hypothesis

A critical part of the scientific method, and one that is often overlooked by teams racing to solve problems, is to form a hypothesis that can be tested.

Tom and Mary Poppendieck on Implementing Lean Software Development – From concept to cash (page 171)

The hypothesis needs to have testable outcomes, like “After one week of refactoring our codebase, we expect to have less code and an improvement in coverage of 25%”. I definitely think I need to practice more of this problem solving discipline in order to come up with better testable hypothesis, so bear with me for a moment.

Perform Experiments

This, IMHO, is one of the most overlooked areas of problem solving in the companies I worked for. Usually the teams I worked with agreed in one solution to the problem and diligently worked towards that goal.

The thing we missed is that there’s not only one solution to a problem. Each different solution will help you one way and let you learn a different facet of the problem. Thus all the solutions to the problem that your team can come up with are well worth trying. I think we might be surprised how many times the least intuitive solution yields the best results.

Experiment is the step in the scientific method that arbitrates between competing models or hypotheses.

Wikipedia – Experiment

Even though the definition of experiment is arbitrating between competing models or hypotheses, the process of learning what works and what doesn’t provides invaluable insight into the problem. Usually the problem will be solved by a set of solutions (each one tackling one facet of the problem).

Verify Results

This is the point where you verify that your experiments have proven your hypothesis, meaning that the testable conditions of your hypothesis were satisfied. It’s also worth taking notes of the major actions/points that actually proved your hypothesis.

The data from this step will serve as input for the next step, Follow Up/Standardize.

Follow Up/Standardize

This is the part of the scientific method where you gather all your data and present the results to the interested parties. If you improved on delivery time, work new SLAs with your clients. If you improved the codebase and that helped you move faster, make sure that people depending on your work know that.

It’s also a very good idea for the team to charter an A3 sheet of paper with all the data and actions took in this process. This A3 can then be used when talking to the interested parties to show how the team worked to solve this issue.

Conclusion

I really liked this way of tackling issues with the development process. Usually we are too involved in day-to-day stuff to take one step back and analyze if we can do things better. A Kaizen event is usually a good candidate for the problem solving process. I’ll discuss the Kaizen events in another post, though.