Invest in the People, Not in the Process

This is the eighth in a series of posts on dealing with the impediments raised in “Agile Antipatterns Are Easy to Spot, Hard to Change”. The eighth antipattern discussed in the post is…

8. Unwillingness to invest in training and coaching

Agile looks easy. All you really need are daily meetings, a status board, and active SQA participation, right? No need to spend a lot of time planning and designing. Just jump in and start writing code. The team will sort things out as they go. What could be simpler?

In fact, it’s so simple, that there’s no need for training, coaching or other expensive services. The team is bright. They’ll figure it out.

Sure they will! To anyone who thinks agile software development is easy, I have bad news for you. It’s not. In fact, getting agile development right can be more complex than getting waterfall development right.

How can that be?

Waterfall development techniques rely heavily upon documentation and their associated review cycles. Writing and reviewing are pretty basic principles that any competent individual can master. Easy? No, but the basic, non-technical skills are readily learned.

Agile development techniques rely heavily on interpersonal exchanges and the ability to fail fast. These behaviors can be difficult to master as they often get people out of their comfort zones. Team-based development and a willingness to try something new are not so readily learned.

That’s where training and coaching can help. Some degree of classroom-based instruction for the entire team can help orient everyone around the formal elements of the agile approach being used (e.g. Scrum, Kanban, XP, Lean, etc.). This helps get everyone on the same page and avoid arguments over how to do this or that.

Following up with an experienced adviser or coach during the first few iterations or sprints can help the team to hit the ground running and build a level of comfort with what they’ve learned. Classrooms and books are fine but there is nothing like doing the work and delivering results.

Even if one or two people on the team have experience with agile development, some level of independent, formal instruction for everyone on the team is valuable. If you need to minimize expenses, this is not the place to do it. Setting up the team for success is more valuable than saving a few bucks.

For the record, I’m neither a trainer nor a coach. I’m not trying to sell you anything. I just like to see software projects succeed.

Updated: November 27, 2011 — 8:37 pm