Software Team Sociology: February 2021

he plan–do–check–act cycle is a great way of structuring what you are doing to incorporate feedback and learning into your results. Its great and I use it all the time, however it is an example of single loop learning. It is a good starting point, but if you stop at the PDCA cycle you are missing out.

What you are doing and what you are learning does not exist in isolation but as a part of a wider context. Paraphrasing the well worn marketing tip "Our customers do not want drills bits they want holes", that is, smaller goals exist to further larger goals. Periodically zoom out to that wider context and re-assess based on what you have learned.

Does what you have learned during your first attempts mean you need to change

The theoretical framework you use to understand the topic
The learning techniques you are using to master the topic
The skill you are learning e.g. whether learning this topic will still help you meet your wider goals or do you need to change to learning a different skill.

Adjust goals, decision-making rules, strategies and mental models in the light of experience.

If you are having trouble meeting your goals then instead of beating your head against the wall, look at why you are pursuing that goal. It is probably part of a larger goal. If you can not make progress on the original goal perhaps you can make progress in the larger goal by taking a different approach.

The 5 whys may help you identify the larger goal. are you concentrating on the drills or the holes?

The Pivot

This is why the pivot is popular in the startup culture.

If there is a lack of enthusiasm for the product by potential customers or an inability to translate enthusiasm to willingness to pay, they will change the product, the type of product, how they sell the product, who they sell it to or the business model.

This willingness to reassess fundamental assumptions is an example of double loop learning.

Double Loop Learning in My Own Career

The Case of the Endless Iterations

Note:
a sprint or iteration is a fixed period or timebox which developers use to help plan their work (it is usually 1 to 4 weeks)
a backlog is a todo list of work items used for planning
a burndown chart shows how quickly work items are getting done.

One of the teams I was coaching was having three problems

They kept abandoning work items they had committed to during backlog refinement and sprint planning, changing their minds from sprint to sprint about the backlog.
They were accomplishing work at the start and end of sprints but nothing was happening in the middle.
They kept on wanting to extend the sprint, claiming they had not finished the work.

In summary they were bad at starting the sprint, they were bad at ending the sprint and they were bad at maintaining focus during the sprint. Although the team had made improvements in many other areas I had not had any luck directly improving the above mentioned three problem areas, so I decided to tackle the problems indirectly. Instead of helping them play the current game I would change the game.

Inspired by eXtreme Programming's recommendation that if you are bad at something you should do it more frequently I convinced them to change the sprint length from two weeks to one week. That may not seem like a big deal but one week sprints can be problem if

Your work items are too big, The majority of items should take a day or less with a one week sprint, while you can get way with larger items with a longer sprint.
Your sprint ceremonies are inefficient, dragging on, causing you to be bogged down with administrivia
Your testing, integration and delivery pipeline has long delays and onerous manual steps, reducing productivity.

Thankful the team had made dramatic improvements in this second trio of issues paving the way for a smooth transition to one week sprints. There was an almost immediate improvement.

The team had an easier time predicting what they would do in the next 5 days instead of the next two weeks. Abandoned work items dropped by a factor of twenty.
The flat horizonal section in their burndown chart disappeared. They were getting things done throughout the sprint instead of just at the beginning and end.
They stopped asking to extend the sprint, because it felt more acceptable and less of a big deal to just add uncompleted work to next weeks sprint. Sprints were less intimidating.

By changing the context I reduced the impact of these weaknesses of the team so they could focus on their strengths.