Roles and Irresponsibilities
Organizations are built around structures and boundaries. 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.
Boundaries themselves are flexible – they are not a line, a Boolean definition whether you are within or beyond the boundary – rather it is a range. 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 impact the team dynamics – their influence originates beyond the team.
The funny thing is that if you have responsibilities, and others also have responsibilities, this also defines what you are not responsible for.
Take the following example:
Alfred is a senior programmer (role) and 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 senior yet (role) and also a member in 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 (maybe statics is more appropriate in this case):
Alfred got sick one day, and surely enough on that very day the build broke. Beth started rolling back her recent changes, but that didn’t help. Surly 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, who is a tester (role) and also a member in 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 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 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. I 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; 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 evolutional or completely different.
Getting a faster tester may help in the short term, but after a while (few sprints down the road) you are likely to hit the same wall: two improving developers against one exhausted tester.
Coming back to the structure and boundaries: Responsibilities help us see boundaries more fixed than they really are. We make up rules to defend those boundaries. Moreover, while they support the roles within the structure, these responsibilities may hide other assumed roles that can help us work better as a team. These assumed roles depend more on the idiosyncrasies of each of us as individuals and less on the roles given to us by the official structures of the organization.
Such roles evolve through dynamics within the 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 these assumed roles, inhibiting the team’s development.
By softening the definitions of responsibilities we allow ourselves to see that oversimplifying the structure and boundaries actually prevents us from trying out what will help us work better as a team.
Want to hear more? The theme for Agile Practitioners 2013 conference is Agile Beyond the Team. Specifically, Gil Zilberfeld will be talking about the Cynefin Framework in this context. To get an idea, watch this short video: