Why do we need roles in an agile team?
Self-organisation is the goal of an agile team, but this does not happen unless the environment is provided. It is the responsibility of the leaders in a team to create and maintain this environment. However, we need to avoid creating bureaucracy and dogma so should try and steer clear of tightly defined roles and responsibilities. The boundaries need to be loose enough so we can get the most out of individuals and customise the roles to the requirements of the specific team.

Why add more roles at all then?
In my organisation either you’re a Developer or a Team Lead. This is not a fair reflection of the value our colleagues bring to the organisation. A great developer is worth exponentially more than an average developer and excellence needs to be appreciated. Also, what makes a developer good are not necessarily the same skills we’re looking for in a team lead.

The responsibilities an agile team needs to be successful
Below I’ve listed responsibilities desired in an agile team. Whilst I have grouped them by the roles of Team Leader and Lead Programmer they are by no means mutually exclusive and do not even have to be the responsibilities of either. We want to be creating teams that have senior people capable of taking on as many of these responsibilities as possible and then allowing them to decide who is best suited to do what. This will have the dual effect of empowering our teams (therefore reducing their dependency on management) and allowing people the flexibility to develop themselves in the areas they enjoy the most rather than feeling they are competing for a single position or even worse, not seeing one that’s suited to them at all.

Team Leader
Communication champion.
Gets the most out of the team.
Empowers the team.
Provides direction (can be technical and process).
Resolves conflict.
Removes blockages.
Makes sure everyone is happy.
Ensures standards and processes agreed within the team are maintained.
Ensure all members of the team have a proper understanding of the customer’s requirements.

Lead Programmer
Code champion.
Responsible for the quality of the code base.
Responsible for the underlying architecture for the software.
Responsible for technical decisions.
Ensure all members of the team have a proper understanding of the technical vision.
Train and informs developers on coding best practices.

“It’s easy to make a mistake and have no idea that you’ve broken the software. A second set of eyes definitely helps. Lets face it, working in legacy code is surgery, and doctors never operate alone.”

“Working Effectively With Legacy Code” Feathers pp 317

I’ve being doing TDD for a year or so and the part I have struggled with the most is testing private methods. Should you test them at all? If so, how do you test them?

Michael Feathers’ book “Working Effectively with Legacy Code” has this to say about it:

“This question comes up over and over again from people new to unit testing: “How do I test private methods?”. Many people spend a lot of time trying to figure out how to get around this problem, but […] the real answer is that if you have the urge to test a private method, the method shouldn’t be private; if making the method public bothers you, chances are, it is because it is part of a separate responsibility: it should be on another class.”

I was looking for people’s experience on managing change when trying to improve software development processes and I came across James Shore’s Change Diary he wrote about trying to persuade a company to adopt agile methodologies. It’s full of useful advice, particularly about how you deal with your colleagues and frustrations.

At my company we’ve been going through a lot of change. I’ve only been there a year and it’s already moved beyond recognition. When I started there were a couple of projects, with the support of some of the management, trying to break away from the traditional approach to software development. There was a lot of excitement about Scrum, Agile and XP, enthusiasm abounded and slowly a movement emerged . As it caught on it became more and more apparent that the big problems lay outside of our control. It was all well and good having “sprints”, doing “pair programming” and so on, but as long as we were being tied to unrealistic fixed deadlines and budgets, projects were being to set up to fail from their inception and no amount of refactoring or retrospectives was going to do anything about it.

The movement became militant. We felt that our concerns were not being addressed and started to blame other people for our problems. We came up with a manifesto of how we wanted to build software. The plan was to send it out to all the developers, get them to sign it and present it to the management. Thankfully more considerate members of our community persuaded us all this wasn’t a good idea and the conversation turned about face. How can we engage the people we need to get involved in the discussions we were always having? The most important thing was that all the people involved in the process of building software are able to talk frankly and honestly. We realised it was our fault that we weren’t engaging with the people that mattered. We’ve organised a Goldfish Bowl discussion with the people we have been blaming for all our problems and the mood of the community has changed significantly. The militancy has gone.

It’s easy to see where this could have gone if we’d published our manifesto. OK, I’ll be honest, it was my idea, but everyone really liked it and we were all frustrated with how things were going. It was a worthwhile exercise and we all got something from it, but it took no account of the considerations of half the people we worked with so was therefore irrelevant.

Enthusiasm is great, but be careful with it. I think we were very lucky we saw reason in time.

Look for the signs, don’t get militant.