Roles in a self-organising team

One of the things that I'm asked to do fairly regularly is define the roles for an agile team, be it for Scrum, XP or some other flavour of agile. I usually end up doing this based on required skills, but my first impulse is to refuse, because I don't believe that a self-organising team actually has roles and I think that defined roles limit both the individual and the team. Let me examine that point before I explain how I do go about defining roles and why.

There is one role on a self-organising team - team member. The responsibility of that role is to bring all their skills to bear on the team's problems and organise their contributions to maximise the team's effectiveness.

When something needs to be done on an agile team everyone on the team should be able to see it, and in many cases it will be obvious which individual or individuals are the best suited to getting it done. The simplest approach is to allocate tasks based on skills, but the team might decide to use other criteria as well - they may need to grow their capacity in some area and decide to give the task to someone with less experience to give that person some practice; they may have limited capacity and be forced to give the task to someone who needs to learn the required skill, usually with mentoring from someone on the team. There will also be team-specific and project-specific reasons for not allocating tasks based simply on skill set. The important thing is that the reasons are well-articulated, and that the team member accepts responsibility for the task rather than having it arbitrarily assigned to them.

Although multi-skilled teams are normal and effective, provided the team is dedicated to achieving a result, has sufficient time and is reasonably self-aware you can imagine any arbitrary skills starting point. We could take a team that consisted entirely of testers and give them some work to do. The first tasks they encountered would require some analysis, so someone from the team would need to do this. They wouldn't complete the analysis as quickly or to the same quality as someone with the relevant experience, and they might not enjoy it as much. They might also need to get outside expertise (training and/or mentoring), but they would get through the work eventually. The team might find someone who wanted to grow into this role and make them the primary analyst, or they might decide that no one enjoys it and the role should be rotated through the team (this is probably less efficient, but it explicitly ranks satisfaction and retention ahead of efficiency). The same pattern can be repeated with development and anything else the team needs to get done.

Don't get me wrong - this is clearly a slow path to success and I wouldn't recommend it, but it is a valid approach. It's a contrast to the behaviour I see more often, which is "I can't do X, because I'm a Y". "Can't" is definitely the wrong word - finding the right word will determine how you respond to this assertion. If the person is really saying "I don't like doing X" then keep the assignment short and try to find some other way to make it attractive. If they're saying "I don't know how to do X", then they need training, guidance and support. If they're saying " I won't do X" then they probably shouldn't be part of the team.

That's why I don't like roles - why do I provide descriptions of roles and responsibilities? It's because I would rather start with a team with diverse skills than spend a lot of time developing the same skills, and most organisations understand that as a request for roles. I also appreciate that most people have gravitated towards a role that suits their preferences and skills, and asking people to move into other areas requires both time and motivation that we usually don't have a the beginning of project.

My hope is that companies that go to the trouble of assembling multi-discipline teams will also recognise the benefits of keeping those teams together for long periods of time. Time is the essential ingredient to building role-independent teams - it helps build trust between the team members, it lets people experiment and learn, and it gives the team opportunities to get feedback on different approaches to task assignment.

An interesting exchange

I wrote this in response to a customer email, but it seemed like something that I could put here:

On 14/10/2009, at 9:15 AM, ... wrote:

Morning Steve,

Saw this article and thought it was interesting. http://www.javaworld.com/community/node/3530

Regards
...

From: Steve

It is interesting. I think it's hard to get the tone right when you're dismissive of agile zealots (who it's hard to agree with, almost by definition), without being dismissive of agile in general. Having been involved with agile for a long time I have a nice clear centre that tells me that agile should be adaptive, but I've also seen the problems that come from being too adaptive too early.

I totally agree that the process for one or two really talented, motivated people is different from the process you use for larger groups/applications. Alistair Cockburn has been very explicit about this in his writing about the Crystal family of methodologies, and Kent Beck has touched on the same subject from a different perspective when he wrote his blogs about "Flight of the Startup". The hard part for most of us is dispassionately looking our our team and ourselves and changing process over time. It's easy to err on the side of too much, too soon or too little, too late, but very hard to judge it just right.

On the "where's the Access of today", that's a question that we've thrown around within Cogent as well. My personal opinion, shared by some others in the company but not everyone, is that we've gone backwards over the last 10 years in productivity and our ability to deliver things quickly. Our capabilitity has increased - we can deliver bigger, more sophisticated applications - but in the process everything seems to have become harder.

I agree with the poster who mentioned the combination of Ruby on Rails and Heroku - that's the combination that I'm using for my personal projects now. I think it's the combination that's the winner - there are other frameworks that to me look more promising than RoR but with each of them I have to manage my production environment myself (for some of them even setting up a production environment is a challenge). Heroku takes care of that and make deployment as simple as possible.

On the OS X desktop MacRuby looks very promising, leveraging Inteface Builder with the power of Ruby. I don't play in the Windows space, so I don't have any idea what the possibilities are there.

...

Steve

My Kindle DX and I

I've fielded more questions about my Kindle, and how I use it in Australia, than just about anything else I've mentioned on Twitter so I thought I'd put the information in a blog post.

After October 7 this information is really only useful if you want a Kindle DX - if you're happy with the smaller Kindle then you should buy an internationalised version and avoid all the issues I'll describe.

Why a Kindle?

Books are heavy, and I often want to carry around more than one for reference, especially if I'm doing some writing. At lot of the things I want to read these days are also in PDF and I haven't found a good way to read those - I end up reading a lot either on public transport or just before bed and my laptop isn't convenient in those environments. I tried using my iPhone to read PDFs but that doesn't work for me (other people seem very happy).

The Kindle is great for reading material that's been formatted for the device - I haven't found it to be that good for PDFs (more on that later). It's much better for me than either my laptop or my iPhone. The screen has great contrast, a huge viewing angle, and when I first opened the box I couldn't believe the starting image was being displayed on something electronic.

First Problem

The first problem is that Amazon won't sell you a Kindle DX if your shipping address is outside this USA. My first solution was to have one shipped to a friend in the USA and then shipped on to me, but it turns out that there are people on eBay who can help. My KIndle DX arrived in the original Amazon packaging, with the original seals intact, with a new shipping wrapper pasted over the original.

Charging

The Kindle arrives with a USA style power adapter, but the approach is the same as the iPhone - it's a USB connecter that plugs into the adapter. Since I already have an iPhone charger I can plug into that, or I can charge from my computer.

The Kindle is fairly frugal with power. Since you won't be using WhisperNet you can turn off the wireless connection to reduce battery use. The screen is bi-stable, so it only uses power when you move from one page to another. I charged my Kindle last Friday night - it's currently Thursday morning and I'm still using it happily.

Content

Amazon (who I'll get to later) isn't the only source of content for your Kindle. You can use .mobi files from other sources, or PDFs. For example, I buy combo packs from the Pragmatic Programmers, so I have .mobi versions of all of their books, and their magazine comes out in the same format.

If you want to buy content from Amazon you won't be able to do it with an Australian credit card/address. I've set up a separate Amazon account for my Kindle purchases and given it my old Brooklyn address (you can use that too if you ask me nicely). I buy an Amazon gift voucher on my Australian account and then use the gift card to buy the content on my Amazon Kindle account. It's an extra step, but it's not really that much of a problem. I download the content to my laptop and transfer it to my Kindle via USB (the Kindle looks like any other disk drive).

Carrying an extra device

Yes, it's one more device, but I've put my Kindle in the back pocket of my backpack and I really don't notice the extra weight at all. It's always there if I want to read, and I use it with one hand even if I'm standing on public transport.

Summary

There's no economic reason for me to have a Kindle, but I'm really enjoying the experience. The proof of the Kindle pudding will be how it scales to having the majority of my library on a device I carry around with me. I suspect that this will change the way I treat information.

Ubiquitous Language

Business language is a pain in the ass. People are way too smart and capable of dealing with ambiguity, and the more familiarity they have with a particular domain the more ambiguity they can handle. They use multiple words for the same thing (perhaps with subtle differences between the words, perhaps not) and they simultaneously use the same word for different things. If you're not "in the know" it can be very confusing. Worse, it may be confusing the people who *are* in the know - the loose language may be obscuring inconsistencies that only become clear when you try to apply automation (computers aren't as tolerant of ambiguity as people are).

There have been multiple attempts at dealing with this problem. Once upon a time it was common to say that business analysts were translators, responsible for taking things that the business understood and turning them into things that the developers understood. Of course this involves waste, in the form of hand-offs and delays, and inevitably introduces defects.

Extreme Programming introduced the idea of a System Metaphor, but most people find it hard to come up with an appropriate metaphor for their application. When someone mentioned this to Martin Fowler at a conference he said "Oh, we just use the naive metaphor" - that is, the developers used the language of the business.

Other people use different words for the same idea - System of Names for example. Domain Driven Design also has this idea at its core. However, the most common term for this idea is Ubiquitous Language.

Ubiquitous language means that everyone in the team is using the same language for the same things - mainly business concepts, but if there are important technical concepts these should be part of the language as well. The language also needs to be precise - coming up with ubiquitous language often requires disciplined analysis from a number of stakeholders (ubiquitous language does not come from one person working in isolation).

Normally we ask a team to converge on one set of language, but I'm currently working with a project that involves both a vendor and their customer.The vendor already has a well-developed set of language around their product, and the customers have a well-developed set of language around their business processes. Probably neither set of language meets my definition of a ubiquitous language, but we should try move them in this direction. Reducing them to one set of common language would probably be impossible, so we probably have to live with both sets for the duration of the program.