Becoming agile

Agile, through the storms

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.

Photo by zigazou at

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:

Single Post Navigation

10 thoughts on “Roles and Irresponsibilities

  1. Great post. In my opinion, if each member of the understands their one overarching responsibility, “get the optimal product done and into the customer’s hands”, then the conflicts between the subordinate responsibilities are easier to resolve.

  2. Very true, Gene. The trouble is that organisations have structures that frequently collide with this primary task. Some call it politics, although to me this implies intent, which is rarely the case. Instead, often unconscious dynamics create these structure to deal with various anxieties. You can read about two such case-studies I describe in an article issue 11 of Agile Record magazine ( , page 22-24)
    In these cases, an individual (development manager, product manager) took responsibility of the situation in order to alleviate a dysfunctional relationship between product manager and the team.
    From the onset, everyone did their best to make it work – according to their R&R. The intervention made to the process or structure changed it closer to the primary task you describe.

    • Oh, yes…very familiar with the conflicts that can take place, both the personal ones and the true political ones. Sometimes, as your examples show, it takes intervention to either get people on the same page or remove their ability to sabotage things.

      Sometimes these conflicts are the unintended result of structural dynamics. Unfortunately, there’s also a breed of management who actively foster such conflicts. That can lead to far deeper problems.

      • “Breed of management” suggests that they were educated to or have evolved into that type of management style.
        In my view this fits nicely into the retrospective prime directive suggesting that these manager make these walls to the best of their understanding. To me it also suggests that there is an opportunity, difficult as it may be, to adapt and to change.

      • In some cases that might hold true. Inexperience may cause someone to think they’re promoting “healthy competition” when they’re actually allowing counter-productive activity. There’s also those who deliberately use a divide and conquer strategy to prevent subordinates from eclipsing them. That style of management is toxic.

      • Sadly, I agree.

  3. Thanks for the post (and the interesting followup discussion).
    Just to clarify discussions about such conflicts of responsibility, I think it is useful to use the terms “Responsibility” for what’s really the best way to serve the desired shared goals, and “Accountability” as the part that is the official “R&R”. It doesn’t work with the acronym, I know… This is a distinction Christopher Avery highlights in his Responsibility Model, where a major theme is that Responsibility doesn’t equal Accountability, which resonate highly with your post.

    • Absolutely! I also advocate the term Accountability in this context. Having said that, not being accountable is sometimes also interpreted as “irresponsible”. It is the role of the leader (e.g. Scrum Master or manager) to identify such pitfalls and reflect the effectively.
      Thanks for the observation!

  4. Pingback: Roles and Irresponsibilities - Project Management, Email Management, Agile Productivity Tools -

  5. Pingback: Becoming Agile - Project Management, Email Management, Agile Productivity Tools -

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: