A Simple Idea Towards Greater Team Self-organization

I have a simple idea that I believe will facilitate greater self-organization within teams: Frame the work of the team in terms of activities rather than individual roles. By focusing on activities rather than roles, it becomes more obvious how team members can contribute to the success of their team thus facilitating greater self-organization within their team. When teams focus on roles they inherently and unconsciously limit tasks to specific people whereas focusing on activity opens that task up to any team member who has some ability to contribute to the completion of that task.

Let me give you an example. Digital task boards have become ubiquitous in product development among agile teams. The simplest task board would describe workflow states in terms of “To Do”, “In Progress” and “Done”. Many agile teams expand this to describe their workflow with additional states such as “Development” and “QA”. In the past, I have challenged teams to change the naming of these workflow states to more accurately describe the activities that they are doing in each state. What does it mean that something is in “Development” exactly? What does it mean that something is being “QA’d”? By adjusting their workflow states to focus on activities such as “manual testing”, “test automation”, “test case creation”, “test case execution” instead of “QA” and discussing their work in terms of these specific activities, would it not become more obvious to all team members what work is left to do and how each team member may be able to contribute outside of their role specialty? This is, in fact, the first Core Property of the Kanban Method: to visualize the workflow (https://scrumandkanban.co.uk/the-basics/kanban/).

SIMPLE…RIGHT?

Sounds simple, right? Maybe not. I have encouraged two different teams across two different organizations to adopt this approach, with little success. It’s not that the teams didn’t improve in their product delivery or have clearer more focused communication, it’s that teams were unable to stick with the change. The first team I encouraged to adopt this approach tried it on for a few weeks. It seemed to work well as it was easier to understand where the team was at with meeting their goals for the sprint and their daily Scrum meetings made more sense (at least to stakeholders, myself included). However, this team eventually reverted back to framing work the “old way” – in terms of their individual roles. The second team that I suggested this idea to, thought it was a good idea and wanted to try it but never did make the change. Hmmm…

So, why is this difficult for teams to do? I suggest two reasons: 1) change is hard and 2) organizational structure is difficult to overcome.

CHANGE IS HARD!

After years of framing work and even basing their identities in their roles, it is very difficult for team members to make the shift to frame their perspective or work in terms of activities. Think about every new habit you’ve ever tried to start, or old ones you’ve tried to quit. We humans have a surprisingly low success rate when it comes to changing our habits. It takes mental energy to change our habits - even a simple change can cause mental fatigue. For the teams that I’ve worked with to change how they frame their work, it was easier to stick with their default way of working than to figure out this new way while still trying to get their work done. It’s like arriving at work and not remembering the details of how you got there. It’s the same trip every day, so your brain allows you to go on “cruise control” and only alerts you to reengage in the process if something out of the ordinary happens.

Additionally, the suggested change was mine and not the team’s. As a coach, I try to focus on helping teams and organizations discover for themselves the experiments and changes they can make to improve. I do also suggest changes to try out, especially when working with teams and organizations new to a particular concept. In both cases where I tried to get teams to reframe their work, it was my idea and my suggestion, not theirs. Perhaps, ironically, I violated the team’s autonomy and self-organization by pushing for a specific change. Helping them design their own experiment when there was an obvious need for the team would have been more likely to succeed.

OVERCOMING THE ORGANIZATION

With such a simple change, what role could the organization possibly have had to cause the change to fail? One of the reasons I see is that we have been conditioned to think in terms of role. Team members are hired into organizations by role and are given a specific job title. It’s not a big leap to imagine that team members will work within their job role more often than looking for opportunities to contribute outside of it. This too, has inertia and momentum behind it just like our habits and takes energy to overcome.

Organizations also tend to have standard ways of working. The aforementioned digital task board is typically and most easily setup once for the organization with each team adopting the same workflow and workflow states. From an outside stakeholder’s perspective, it makes the most sense to standardize the workflow for the organization, so that we’re all speaking the same language. Unfortunately, this contradicts one of the tenets of Scrum teams that, “Self-organizing teams choose how best to accomplish their work...” (Scrum Guide – July 2016). The task board can be adjusted to be unique to each team, but this takes effort which, depending on the tool, can be significant.

MY FOCUS

So, what can be done about this? Well, in my role as an Agile Coach, I work with teams to help them discover improvements they can make towards greater self-organization. Where are there opportunities for team members to work across roles in order to help the team achieve its goals? In what ways is the team being slowed down? Do we have all of the right people on the team?

When working with organizations and those outside of the teams, I focus on helping them understand the impacts of decisions and policies on the autonomy and self-organization of their teams. How will this decision support or promote the self-organization of our teams? In what ways has the organization limited the team’s ability to self-organize?

YOUR TURN

Despite my past setbacks, I haven’t given up on the idea of trading role descriptions for activity descriptions and would appreciate hearing about your experiences. Do your teams discuss work and workflow states by activity or by role? Have you (or will you) try visualizing your workflow by activity and share your experiences here? Given my experience, perhaps this sort of change is a myth that’s been busted (to steal from the Myth Busters TV show), but I still feel that it’s plausible and will continue to explore its impact on team self-organization.