Wednesday, March 23, 2011

What's in a Role Anyway?

We recently had a discussion about what the state of the development community at the moment. I've also had a blog post with a comment, where I stated is there a need for a BA!? This centred mainly around the make up of the team and who or what key skills you need in a team. As I’ve become accustomed to being just a developer over the past couple of years which has included either of the following: writing code, or supporting production code. Although this has been my primary role over the last couple of years I’ve come to realise – probably since discussing and studying Agile & XP especially that this is simply cannot be the case anymore.

The main reason for this is due to the fact that XP & SCRUM just has a concept of a team – this includes everyone who is needed to deliver a product or rather something of value to the customer. The idea that when the time comes to deliver everyone needs to be able to help to deliver the product – this is mainly because there is not one person responsible for the delivery – the team is responsible. So this means that if there are tests to complete before the iteration completion date and no development work – then everyone needs to “muck in” to complete the tests.

This leads to teams of individuals with multiple skillsets – as an individual you might for one day have your developer “hat” on – the next day your “hat” is firmly in the “test” ring. Traditional role definitions are probably not well used here and are probably redundant. You are essentially just a team member who has more experience in development than testing, BUT you must be able to help with testing if the needs arise. If there is a bottle neck you must be able to relieve the pressure on the bottle neck – otherwise the “team” will not deliver.

This ability to learn different skills leads me to another important asset of any team member – you must be willing to learn. I think Agile especially encourages this, since everything is an experiment? I was listening to a Podcast with Lisa Crispin and a couple of her final thoughts centred on the need to learn and willingness to learn. It must have struck a chord - because I was skiing at the time! I believe these are key skills for anybody working within in an Agile team.

For me this leads to a couple of core things to look for in team members:
  • Willingness to learn
  • Ability to adapt to the needs of the team

4 comments:

Mike Bosch - Software Engineer said...

Nice post. Thanks for sharing.

Jason Young said...

The way I think of it is that traditionally we had roles that a person filled. In an agile team, people have skills that they use in the best way to achieve the goals of the team.

The implication of this is that a successful agile team will probably have team members whose previous role in a traditional environment was tester, BA etc. These activities still occur in an agile environment, it's just that they're not confined to one person, but are the responsibility of the team.

This is also related to the concept of "generalising specialists". Whilst you want team members to be able to tackle any task the team requires, you still need someone who is sufficiently skilled in a skill to be able to guide those team members who are not specialists in a skill. This skill could be testing, business analysis, or a particular technology.

Jason Young said...

On a partially related note: I once read a tweet (Lisa Crispin maybe?) saying that they call everyone on the team a developer - as they are all involved in the development of the software.

Ady_Stokes said...

Role v Goal is a discussion that has bounced around for a couple of years now. I've read quite a few on this. There are many references to it in quite a few blogs.

My take is simply, "what can I do to further the development of the solution"?

I'm not bothered if it's my job, in my role remit or out of my 'normal' scope. If I suggest an improvement, suggest 'different' code, come up with a test scenario that is not covered, anything really then 'if' it improves the delivered solution I'm doing my job. Call it QA, call it testing, call it development to my mind it does not matter as long as the 'customer' calls it a job well done and value delivered.
Cheers, Ady