Software Team Sociology: February 2021

Saturday, February 6

Double Loop Learning

hat 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 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 or decision-making rules in the light of experience.

If you are having trouble meeting your goal 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.

An example from my own life

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.