Transforming embedded

Dancing with complexity

Dancing with complexity

This article is a continuation on the article on Working with complexity In that article we talked about that you need to work in the right mode based on the complexity of your work. The basic conclusions are summarized in the table below.

The challenge we are going to talk about in this article is how to dance between individual work and collaborative work at the right time as a team and organization. If you learn to do this, you will always be both efficient and effective. The three dance moves you need to learn are called schedules, checks and triggers.

Schedules

The first way is to do it by a . A schedule is when you decide to do collaborative work at certain times.

One example is in the agile practice of Scrum where you have a session called Backlog grooming each sprint where you collaborate on stories and break them down into unambiguous pieces which individuals can work on. If you succeed, you can efficiently work individually until the schedule calls you back for the next collaborative session.

The schedule does not have to be on the scale of weeks, it can also be on the scale of a day. For example, you can decide that you are working together in the morning and then splitting up to work individually in the afternoons.

Or, if you are an individual who is swamped by people coming over with questions all the time, you can split your day between individual and collaborate work. For example, allowing questions the first 15 minutes of each hour and then working uninterrupted with focus for 45 minutes.

Checks

However, all tasks are not as unambiguous as expected and we need to be able to deal with the unexpected too. The second way is a checkand is related to a schedule. A check is something you do while being in a meeting to check if you need to start, or continue, collaborate on a task.


In Scrum you have several checks such as daily standups and demos. In a standup for example, which is not collaborative in its basic setup, you can have a check which could trigger collaboration after the standup. For example, one could be that there has been no progress around a task. Or in a demo, if you and the customer are misaligned, you need to start a round of collaboration to decide the next step.

The frequency of checks is very dependent on the complexity of the work. If your work is very unambiguous, you might be fine with a waterfall process with a phase gate as a check once you think you are done. If it is not, which it seldom is in software, you might need even daily meetings.

Triggers

The third and final way is a trigger. A trigger is a previously decided condition that makes us move from individual to collaborative work mode.

The classic example comes from Lean and is the Andon Cord in Toyota. It is the cord a worker on the assembly line can pull at any time when she discovers a problem. Pulling the cord stops the line and help arrives rapidly to sort out the problem together with the worker.

For knowledge work and engineering, one example of a trigger can be that there have been more than two misunderstandings in an email chain which is acted on by having a face-to-face meeting instead. Another can be that a continuous delivery pipeline has been red more than an hour. Or that a nonstandard customer request is received. Or that a critical bug is found at a customer site. Or that you lie awake during night thinking about a problem two nights in a row. And so on.

The triggers can both be very general and very specific to the work that you are doing. They can also be on any level from the whole organization, to the team and further down to the individual level. By mapping up these triggers, you make sure that no found issues are left hanging or even forgotten.

Bringing it all together

To be able to act on these triggers and checks though it is important that the people you need to collaborate with all are available rapidly. If everyone is booked for the next two weeks (including all conference rooms!), this makes it impossible to act on the check or trigger. One way to do that is to have an organizational schedule which does not allow any meetings to be planned ahead between i.e. 1-3 pm each day. Basically, you need slack in the system to be able to act on unexpected events.

Importantly, these schedules, checks and triggers does not only have to start collective work on a work item. It could start team activities as well. For example, if a team member does not think that the team lives up to their values or are not doing work in alignment with the mission and vision, this could trigger a discussion on where we are as a team.

With your new understanding of how to combine individual and collaborative work, what will you do? What triggers will you set up? Do you have an environment where people feel safe to trigger collective work when they are unable to complete it themselves? Do the schedules match the known complexity of the tasks? And how often do you do checks?

If you get this right, you are setting yourself up for a great boost in both productivity and outcome for your organization.

Above article is partially based on theories on Dynamic Work Design by Nelson Repenning, MIT.

This article was also published on Transforming Embedded here.