Organizations are built around structures and boundaries. For example: when you join a new workplace you meet your new manager. Sometimes your manager has another manager, and the other manager has their manager, and so on. This is the structure – in this case a hierarchical one.
Within this structure there are boundaries. You learn pretty quickly what you should be talking to your manager about and what not to. In some organizations you should be telling your manager when you are going to buy a new piece of hardware; in other organizations you might have to ask for permissions; and in others you just buy it, no questions asked. These are examples of the boundaries. So what is the linkage between structures, boundaries, roles and responsibilities?
Boundaries themselves are flexible – they are not lines, Boolean definitions whether you are within or beyond the boundary – rather they are ranges. If you are at a customer site, and your manager is unavailable, and you must buy that piece of hardware, you will buy it – even if permission is normally required in advance.
That thing that will normally define your place within the structure and the boundaries within which you operate is your role. And with your role, quite often, come also responsibilities. It even has a nifty name: R&R (and no, it does not mean Rest and Recuperation in this context; R&R stands for Roles and Responsibilities).
This idea is derived from the contributions of Open Systems Theory to social systems, notably the work of Kurt Lewin early in the 20th century, and is still evolving today. In our context, roles and responsibilities that are defined at the organizational level often impact the team dynamics, and influence the team and beyond.
The funny thing is that when you have responsibilities, and others also have responsibilities, it also implies what you are not responsible for.
Take the following example:
Alfred is a senior programmer (role) and a team member (another role). As such, he is in charge of the build server and the source control when they break down (responsibility). Beth is also a programmer, but not a senior yet (role) and also a member of the same team (another role). As such, she is coding like the other programmers in the team (responsibility) but she is not allowed to handle the build server without Alfred’s supervision.
Now let’s take a look at some of the dynamics in this team (and maybe statics is a more appropriate term in this case):
Alfred got sick one day, and sure enough, on that very day the build broke. Beth started rolling back her recent changes, but that didn’t help. Also surely enough Beth discovered that another team checked in changes that depend on a newer version of Hibernate, that do not exist on the build server. Paradoxically, the responsible thing for Beth to do is irresponsible according to her R&R, emphasis on the 2nd R.
Let’s make it more interesting:
Meet Charles, a tester (role), and also a member of the same team (another role). Charles is writing the test plans and scenarios every sprint and executes them throughout the sprint (responsibility).
Everything was working great until recently Alfred and Beth started using Junit. Well, “great” is a funny choice of word because until three sprints ago Charles would typically not finish testing all the stories because he found too many bugs before he could start his own test scenarios. When Alfred and Beth started with Junit, the first sprint was a nightmare for him: not only there were the regular gazillion bugs, but the stories finished development even later than usual, and testing started very, very late in the sprint.
The second sprint was fantastic for him! The first story finished with hardly any silly bugs, and Charles could test his scenarios right away. Surprisingly, Beth and Alfred could fix the bugs very quickly, and, in the second story, Charles opened the browser on Beth’s machine, and they squashed those bugs together there and then. It was (pardon the language) fun!
Then came another sprint with a new experience for Charles. Alfred and Beth finished their first story very quickly, and Charles started testing. Beth was already deep into the second story and did not appreciate Charles taking her out of her ‘zone’. Charles finished testing, documenting all the defects, just in time to start testing the second story. By the third story, Charles had to test the defect fixes on the first story, delaying Alfred and Beth from finishing their work. It was obvious that Charles was not accommodating to the advances in new ways. Maybe he should even get replaced with a faster tester, to keep up with the programmers.
What’s wrong with this story? The problem is that if Charles is responsible for testing, obviously Alfred and Beth are not. It would be a waste of time to place a highly skilled programmer on testing. Rings a bell, anyone?
Getting a faster tester will likely not solve this problem. Testing and solving bugs probably will. It would be worthwhile to try out – to experiment if testing as a team will improve the overall team performance. Let’s say that a programmer is testing at 50% efficiency than a tester (yeah, ok, developers don’t think testish, so they just run scenarios written by Charles. We can live with that simplification for now). If both Alfred and Beth are testing together with Charles, it’s as if you have ~1.75 testers in the team instead of just 1. Why 1.75 and not 2? That’s to satisfy typical skepticism and apply the Law of Diminishing Returns.
You may or may not like this idea. This is fine; of course, there are other ways the team could address this issue. The main point is that it asserts a hypothesis regarding a solution, and checks it through an experiment. If the results are good – you keep the practice. If not, you make another assertion – either based on the previous or completely different.
Getting a faster tester may help in the short term, but after a while (few sprints down the road) they are likely to hit the same wall: two improving developers against one exhausted tester.
Coming back to structure and boundaries, roles and responsibilities: Responsibilities “help” us view boundaries stiffer than they really are. We make up rules to defend and avoid the boundaries. Moreover, while responsibilities support the roles within the given structure, they may also hide other implicit roles that can help us work better as a team. These implicit roles depend much on the idiosyncrasies of each of teammate as individuals and less on the roles given to them by the official structures of the organization.
Such roles evolve as part of the dynamics within a team: Who is the devil’s advocate in our team? Who is the innovator? Who’s the order freak? Charles, for all we know, could be the best friend of the user, getting better specifications of the desired software. But his responsibilities may shy away from these implicit roles, inhibiting the team’s evolution.
By softening the definitions of responsibilities we allow ourselves to see that oversimplifying the structure and boundaries actually prevents a team from trying out what will help them work better as a group.
As leaders – Scrum Masters, managers, team-leads and so on, we want responsibilities to change according to changing needs, regardless of individuals’ roles.