#NoBigProcesses — It Needs a Little Something!

In my previous post in this series, #NoBigProcesses — Two Key Activities, I asserted that all software development can be boiled down to the two key activities of actually shipping something, and then reflecting on how we worked in order to improve our ability to work together and ship. With that established, how do we go about adding to our initially very limited process when we feel there’s a need to do so? Let’s start with an analogy.

I like to cook, and when trying a new dish that I haven’t prepared before I almost always stick to the recipe that I’m following. After all, at least one other person on the planet has tried the recipe and thinks that it was good enough to write about!

After eating this new recipe, I’ll think about any ways that I might change it to be more amenable to my or my wife’s palate. Was it too spicy? Was it too bland? Was there just something missing? Did the flavours overwhelm you and need to be dialled back in some way? For example, I love bold flavours when making chili, but my wife doesn’t want it to be too hot from a spiciness aspect. So, I add more cumin and chili powder (which isn’t usually very hot) and only a little cayenne. I can always add some hot peppers to my serving when eating, but I can’t take them away if I cook them into the chili!

Eventually, after making a certain dish many times, a written recipe isn’t even needed — I just know what ingredients are necessary, what proportions, what cooking times, etc. Even then, though, I might tweak things a little if I discover that I’m out of a certain spice or other ingredient.

This approach can be used as an analogy for how I’m advocating that we work in delivering software. First, ship something — make the dish! Second, reflect — did we like the dish and are there any changes that we think we could make to improve it next time?

But here’s the key point of process improvement — only add when you feel something is missing that would provide tangible value!

First and foremost, ship something! Once you’ve ascertained that some form of software is required, build the absolute minimum necessary needed to obtain feedback, then use that feedback to steer your efforts. Reflect on how you worked in order to improve your process.

But here’s the key point of process improvement — only add when you feel something is missing that would provide tangible value!

This is where I channel my inner toddler to ask a gazillion questions about adding any new activity to a process. Examples are:

• Will a new activity or step really, truly improve how you deliver right now or in the very near future? How would you know that you improved?
• Will the new activity improve some measure of quality? How would you know if it did?
• Will it solve a problem that the whole team has, or just one or two people?
• Will it make your customers happy?
• Will it make your stakeholders happy?
• Will it make the team happy?

Simply adding something (or removing it, for that matter) without an idea of how you’ll know that it made a positive difference is the same as just randomly guessing at the outcome.

To use the cooking analogy, suppose we wished to reduce the spiciness of a dish because it was too hot for our palate. That’s relatively easy — we can reduce the proportion of peppers or even eliminate them altogether! Suppose, however, that we wanted to allow the smoky flavour of chorizo sausage in a stew to stand out. How would we do that?

Well, we experiment!

To use the scientific method, we would first form a hypothesis. For example, perhaps if we reduce the amounts of other seasonings in the stew, the flavour of the sausage would become more apparent. Then, we devise an experiment to either validate or disprove our hypothesis, so we would actually make the dish. Finally, we run the experiment and observe the results. We eat the stew!

Based on our observations made while eating we would decide if our hypothesis that reducing the amounts of other seasonings met our expectation that we would taste more of the sausage’s flavour.

To apply this analogy to the process a team is using, again we would first form a hypothesis. For example:

• Using the 3 Amigos technique will provide improved shared understanding across the team for each piece of work we do.

Next, we devise an experiment:

• For one week, we will continue without using 3 Amigos. We will track the number of questions asked within the team and to the business people about the work, the number of issues found during testing and how many changes were requested by the business people before the work was accepted.
• After that, we will use the technique on all work for 1 week. We expect that, compared to the baseline week, there will be fewer questions asked, fewer issues reported from testing and the business people will accept the work with fewer requested changes.
• After both weeks are complete, we will poll the team and business people for their level of satisfaction with the work itself and with the new way of working.

Then we run the experiment, in this case for two weeks. We ask ourselves, did we see the expected results? Did we see any changes at all? Based on the actual outcomes, should we proceed with adding the 3 Amigos technique to our process? And, finally, could we have run this experiment differently so that we could test the hypothesis more quickly and/or more effectively?

Happiness is also a leading indicator of success!

Note as well that the last three points of the questions I provided as examples of channeling my inner toddler all mentioned the “happiness” of some person or group associated with building the product. While happiness is qualitative rather than something quantitative like the number of issues, it can still be measured in a relative sense by simply polling the group about their satisfaction after some change. In our example, it would be after trying 3 Amigos for a week.

Happiness is also a leading indicator of success, whereas financial performance, velocity and counts of defects are lagging indicators. Indeed, in the linked article, note that Customer Satisfaction is used as a leading indicator by organizations such as 3M, Dell and Sprint. In our world, that equates to the people who will be consuming our work and the people on the team itself!

Ultimately, we want to ensure that we aren’t blindly adding anything to how we work. Changes to our process need to be deliberate and measurable. We need to understand what benefits we expect to see from a change, and measure that those benefits were realized. If they’re not, we may consider rolling the change back rather than keeping it.

After all, the goal is not to have process for the sake of having process, it’s to have steps & activities in the process that benefit the team, stakeholders and consumers of the work. Each of those steps and activities should have a measurably positive impact on the team’s ability to Ship and/or Reflect on their work in order to improve.

The next post in this series is, “#NoBigProcesses — So Where Do I Start?”.