Simple OVER Complicated

Mark Twain famously wrote “I didn’t have time to write a short letter, so I wrote a long one instead.

A more contemporary version might be “I didn’t have time to write a simple depiction of Agile, so I wrote a complicated one instead.

A more truthful contemporary version be “I wanted you to think of me an expert so I created a complicated depiction of Agile, especially as I did not have enough experience to create a simple one to handle the complexity of the context.”

This might explain the SAFE diagram and thw Deloitte Agile diagram.

Simple in Practice

Simple is vital for adopting Agile at the organisational level. Tony Grout, Lisa Long, myself and many others spent significant effort at Skype implementing and supporting a process to coordinate two hundred product owners and three hundred development teams.

Initially people struggled with just understanding the process. Then once they understood it, there was a desire to improve the process. This usually involved adding to the process, making it more complicated.

Tony, Lisa and I had a single design principle to guide us. The process should be so simple that no one should be able to use the process as an excuse for not following it. Anyone not following the process would look foolish if they failed to do it properly. This was because we knew there might be people who opposed the introduction of the process.

Opposing complicated-ness was difficult and we had to be constantly vigilant. For eighteen months, the process evolved. Each retrospective, the group would say the best thing was the “preparation” and the thing they most wanted to improve was the “preparation”. The initial meetings took three days with approx sixty people face to face in Tallinn, London and Redmond. The last meeting I’m aware of involved about twenty people on a conference call for two hours. Much of the quarterly meeting was moved to the “preparation” activity. We had started trying to create a week by week plan for the quarter with everyone in the room. We dropped the planning and focused on creating an ordered backlog based on the available capacity in the teams.

Although the tight knit team running the process increased the level of automation, the product owner team had only two simple instructions:

  1. To get an estimate from the product owners of all parts of the organisation needed to help them deliver their initiative. This meant as a minimum they had to have a conversation with the other product owner. We just did not specify what the conversation covered. We gave guidance that the conversation should last about ten minutes, and the product owner providing the estimate might want to discuss it with the tech lead and test lead, but not the team. We faced a constant challenge with teams wanting to provide ever more accurate estimates.
  2. They had to create an ordered backlog based on the capacity available to the teams. We did not tell them how to come up with the ordered backlog, only that they had to come up with one.

The success of the process was based on a simple process that two hundred product owners followed.

The key point is that there is a natural tendency towards complicated and it requires effort to keep things simple.

Simple in Communication

Simple communication requires practice and preparation. Communication goes through three stages, excitement, boredom and effectiveness.

  1. Excitement – During the excitement phase, we love a new idea and every time we explain it, we embellish the explanation with extra details and anecdotes. Our description of the idea becomes more and more complicated and we feel the need to add more and more “important” details.
  2. Boredom – After we have explained the idea a number of times, we get bored of it and start to drop the “important” embellishments. Our boredom with the idea leads us to drop truly important details to the explanation which results in confusion and additional effort. We learn what is genuinely important to our explanation which cannot be dropped, and what is unimportant and can be dropped. Our laziness leads us to the perfect explanation.
  3. Effectiveness – Eventually we reach the point where our laziness has led us to an explanation that is as simple and short as possible.

This process requires the need to practice an explanation many time. The best way to practice is one on one. People are less likely to ask clarifying questions in a group, and they are also more likely to ask challenging questions. You need to practice with people who do not know the material, and people who know it well… Both groups will give different but valuable feedback.

So aim for simple, and understand that complicated is a sign of a flawed understanding. As Einstein said “Everything should be as simple as possible, but not simpler”.

About theitriskmanager

Currently an “engineering performance coach” because “transformation” and “Agile” are now toxic. In the past, “Transformation lead”, “Agile Coach”, “Programme Manager”, “Project Manager”, “Business Analyst”, and “Developer”. Did some stuff with the Agile Community. Put the “Given” into “Given-When-Then”. Discovered “Real Options” View all posts by theitriskmanager

One response to “Simple OVER Complicated

Leave a Reply

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

You are commenting using your 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 )

Connecting to %s

%d bloggers like this: