Friday, January 14, 2011

Team Work Common Sense

Let’s talk about working in Teams.  There are many options for how to work in teams and a variety of implementations.  However, let’s just talk about some business reasons for doing things in teams and why they are an essential part of software development.

Actually, I can think of a variety of other parts of business that could benefit from this approach, but let’s just stick with software development for now.

When working in teams, I try to spread the work amongst the developers.  This shares system knowledge and experience.  As each week passes, each team member becomes knowledgeable about a different part of the system.

At first this approach to the outside observer seems slow and cumbersome. As time goes by, and the team gets used to each other and the application, development gets faster as any team member can effectively work on any part of the system. 

This is the tricky part. An executive who has not seen Agile work before will think that things are slowing down. Yikes.  Of course this is not the case.

Try to focus on the difference in the bug rate, increased value to the customer and to the company with things such as lower churn (loss of customers) rates, a regular and predictable release cycle, customer satisfaction, and the happiness of the support desk staff as the number of support calls goes down. Consider also, what marketing can do with the information about the upcoming release, or even the excitement of the customers experiencing a new, zero bug release every iteration.

Granted, these items seem less tangible to a financial person, but the turnover of unhappy support employees, unhappy developers and churn of unhappy customers can easily be quantified, to name just a few.  In your environment, there are likely many more.

Depending on the size of your application and team, you will soon be confident that any team member can work on any part of the system and make the development team extremely productive and respected.  As a minimum, there will be product knowledge by all developers.  This is key when you are planning on adding new functionality.  It may surprise you what a new novice developer has just learned in a course that you or your team members may not know about!

Don’t get me wrong, each ‘mini project’ or feature in the program still needs a developer who really knows that piece.  I can’t really see getting around this without having a very shallow application. 

I’ll talk about the whole developer managing a mini project thing and its’ advantages another time. For now, though, I’ll just stay on topic.

Once Agile is in full swing (no matter what your discipline or disciplines you use), you will find that you will soon be in a position to be wondering what work you can do next.  This is where Agile truly shines.  The work you are doing has a definable schedule and because of the regular estimates and re-estimates you have a realistic idea of how you are doing.  After a few iterations you will even have an idea of how much productive work gets done by the team in a week, and you know how much work you can already schedule ahead for.

Others will not see it coming and will likely be surprised you are asking.

Don’t be shy! This is the time to let others know how well Agile is working for your company.

Each time a small feature or part of the system is being worked on, I purposely give the piece of code to the same ‘base” developer to do but assign a different “second” developer to work on that piece.  This forces information exchange and empowers the team to know all parts of the system.  It is also a great way to pass on development experience to new developers and sometimes from new developers to existing ones.  The exchange of information is a dramatic thing to witness once a team is used to it.

There is nothing more enjoyable than to publish a new release and to have nothing dramatic happen from the development perspective. 

Where I currently am, I remember after about the 4th iteration (we are on weekly cycles), having a developer meeting 2 days after and the whole team joking about the fact that not only did the support department receive no extra calls, but the call volume actually went down because of some of the previous defects we fixed.

What a feeling of accomplishment and teamwork!

As well as the obvious benefits of removing risk from the company, it provides the added benefits of true teamwork spirit, mutual respect and fellowship.  The developers soon know each others’ strengths and weaknesses and will automatically help each other out.

Techniques are passed on and knowledge that otherwise would have stayed only with one developer is shared.  The transformation from individuals to a team is remarkable and very enjoyable to see and for me at least, the true inspiration for managing as part of an Agile Team.

Agile helps the developers to be happy and fosters an environment where everybody feels like part of the finished product. 

For those of you out there that are regularly trying to figure out how to keep developers motivated and feeling like part of the company, consider the positive effects of true teamwork and each person feeling like they are part of the finished product (which of course they easily could be).