Transforming into a Team

One of the principles behind Agile Team, is the commitment of the Team to finish the planned features for a given iteration. There are times when some members in your team will finish their tasks early while others will stuck on unplanned or underestimated tasks. In a perfect world, each one of your teammates would be able to perform any kind of work whether it’s design, writing database queries\commands, program, create graphic interface, test. At least to some degree. On the Agile community, these kind of people are called “generalist specialist”. This will allow the Team to help each other and keep their commitment. In most of these scenarios, the teammates will help each other as a natural process of feeling as one unit. But things are more complex.

The problem is that you still want to hire a great SEO specialist, a great web designer or a great DBA, so this leaves you with the question “how could they help the Team meet its commitment?”. We can’t ask a SEO specialist to write multi-threaded C# code, which leaves us with a Team and a bunch of consultants that try to aid the Team hold to its commitment. I’ve seen this behavior of “consultants” inside teams leading to the notion of “Look, I’ve actually finished my tasks successfully! it was the Team that failed…”.

Could we really try to use our SEO guy for multi-threading tasks? most probably not. The trick here is to find a common ground so we can bound our SEO guy into several fields, making him feel as part of the Team. For example, the SEO guy can make some web design by helping to create a SEO-correct HTML (thus helping to take some pressure off from the web designer) or maybe helping the architect design the user interface. One of the things we’re doing now at our Team, is introducing our beloved DBA(Shlomo – I’m waiting for your blog dude) into writing the data-access layer in C#. We’re doing it step by step, while I’m trying to explain about working methodologies and doing some pair programming. It will take us time (baby steps), but we’ll get there.

This change in state of mind is not easy, but it is crucial if you want to jell your teammates into one Agile Team. Notice that I’m writing “Team” rather than “team”. I see Team as a single entity, a solid force driven to hold to its commitment no matter what (while still keeping high quality delivery, of course); This is very different from a team, driven to do as much as it can, each one on its own, without being responsible for the greater good.

Being a part of something bigger is a motivation boost you shouldn’t underestimate. For me, there is no bigger satisfaction than taking ownership over an entire application (instead of “I’ve fixed problems 1 and 2 in product A and problem 5 in product B”), working hard and making it work at the end of the day. Doing that, you could honestly say “I’m responsible for the success of our product, and I’m damn proud of it!”.