Thinking/Doing Loops

Ryan Cooper, who recently attended one of my agile training courses said:

It doesn’t make sense to separate the thinking from the doing.

So the real question is: why do we do this so often?


Levels of Separation

It is probably good to note that there are levels of separation. If you’re in a big bureaucratic organization you will find hugely separated thinking and doing.

For example, at one large organization that I know well, there is a part of the organization dedicated to determining the best possible process to follow for all the different types of projects that are run: software projects, business projects, marketing projects, etc. The people in this process group sit together and think about all sorts of interesting things like how to meet regulatory compliance constraints, how to measure things really well, how to avoid most mistakes, how to make sure that there is a careful balance of responsibilities, how to make sure that everyone who cares about a project gets a say, and how to make sure that everyone who cares about a project can throw in their version of the kitchen sink. These people get around to interviewing the managers of the people who actually work in these projects… maybe once every six months.

The people “working” in the process group are almost completely separated from the reality of the people doing the work. The feedback cycle is at least twelve months. Let’s say that a project starts out using Version N of the process defined by the process group. The project runs for six months. The process people interview the manager of the project and incorporate the feedback in Version N+1 of the process which is released into the wild six months later.

The trouble is that the twelve months for the feedback cycle is actually the least bad it could possibly be. More likely it looks like this: six month project? Too small, the feedback isn’t terribly important. Two year, forty person project? That’s more like it! Let’s get lots of feedback in the post-mortem for this project! Project starts with Version N of the process. Thirty-six months later the project finishes (if lucky!). Post-mortem done. a few months later someone from the process group receives the post-mortem report (200 pages of boring, poorly written text). The process group decides that the $100 million worth of feedback deserves its own project. The process group launches a major process revision project based on the post-mortem report. One year later, the process group releases Version N+1 of the process. Total elapsed time for feedback: fifty+ months! Total waste of time: yes.

Okay, so that’s a worst-case scenario.

There are lots of smaller ways that we separate thinking from doing.

Individual

The most direct pairing of thinking and doing happens at the level of the individual person. A person’s own thoughts and creative efforts are directing their actions, and they are observing and learning from those actions to change future thoughts. This feedback loop is the easiest and most natural (although sometimes we forget to learn from the results of our actions). Sometimes, this feedback loop is so tight that we get into a state of flow, the “zone” and it seems as if our actions and our thoughts are perfectly at one.

This level is limited in that many thing cannot be done by the efforts of a single human being. So we move up a level.

Team

The team works closely together so that thinking and doing is separated at most by trusted high-bandwidth low-latency communications such as a few people working together at a whiteboard, or two people working at a computer together. All the members of the team have equal participation in the thinking/doing loop.

Again, it is possible for a team to get into the “zone” and become a high-performing or “real” team. People on teams like this often can’t remember who thought of what great idea or who executed some particularly amazing piece of work. Individuals offer their best talents, skills, experiences and are receptive to the offerings of the other team members.

This level of separation of thinking/doing does present some challenges: it is more difficult to get into a state of flow as a team, it is easier for the work to be disrupted by the environment, and sometimes the communication breaks down.

Group or Organization

There are some rare organizations which maintain an incredibly productive state above the team level. Toyota is oft-cited, but there are others too such as the “Good to Great” companies.

More often than not, however, groups and organizations fall into various degenerative types of thinking/doing separation. In software development, this is typified by the handoffs between people doing requirements to different people doing architecture to different people doing analysis and detailed design to different people doing development to different people doing testing. And that’s not even taking into account project managers, managers, marketing, sales and customers! Yikes! No wonder phase-based software development is so painful!

Obligatory Conclusion

Agile methods help tighten up the thinking/doing loop by requiring cross-functional teams with product (what) and process (how) and technique (work) skills and authority actually on the team.


P.S. This is an expansion on the Cycles of the Mind stuff.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail
This entry was posted in Uncategorized and tagged by Mishkin Berteig. Bookmark the permalink.

About Mishkin Berteig

Mishkin Berteig is a Baha'i, a father of four, a husband and an experienced Agile consultant and trainer. Mishkin is a Certified Scrum Trainer (CST) with the Scrum Alliance, a certified Master of OpenAgile wight he OpenAgile Centre for Learning and a certified SAFe Program Consultant (SPC) with the Scaled Agile Academy. Mishkin has a technical background including a B.Sc. in Computer Science and worked as a Chief Architect reporting to the CIO of Charles Schwab, but gave it up to be more Agile.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>