Mini SWAT Team

Similar to the build master role - I posted about that a few weeks ago - you may find occasionally that there are other topics that you want to overemphasize for a certain period. The build master is specifically taking care of continuously improving the engineering and build environment.

But you may have items that are either to beyond the available build master capacity or don't even fall under the build master's duties. Or you want to speed things up. Let me give you two examples.

Let's say you want to introduce a new testing tool that you haven't used in the past. The tool arrives. While rolling it out you find that there are challenges and issues that need to be addressed. Not that you are surprised but the amount of work is way beyond of what your build master (or build master team) can do within their time. So what do you do?

Or you want to migrate your build environment towards a substantially improved environment, more powerful, more flexible, maybe involving virtual machines, new technologies, and so fourth. A steep learning curve is guaranteed. What do you do?

In both cases you can create a "Mini SWAT Team". This can even be as small as one person. The mini SWAT team would be dedicate to one particular subject for a period of time and then wrapped up. In the first example the introduction of the testing tool could be sped up by working with the QA team and by working with the developers. In the second example the mini SWAT team could work with IT on the environment improvements.

Who would you put on your Mini SWAT Team? Certainly you'd look for someone who can work independently but also in a team. People who can work with different functions are certainly advantaged. But then, you also have a quite different option as well: Give it to a more junior member of your team. Provide a lot of support and you'll find that the person steps up and grows with the job, enjoys the responsibility and the opportunity to pull something through that is of value to the whole team.

Food for thought? I hope so. It's all about trying something new and then adapting as you go!

Taking turns in being the build master

The build master is a quite important role in an software development team. Responsibilities include ensuring the build works all the time and chasing down people who are fixing a broken build. Other items may include improving the build process which should also include the execution of comprehensive test suites in all test beds.

While on one hand it is a big help if a person in this role has prior experience with these tasks. On the other hand - and that doesn't have to be a competing goal - it is also valuable if team members take turns.

Let me explain. In all teams that I have coached I have found that different people have different strengths. For example one person might be excellent in writing Perl scripts while a different person is extremely proficient in relational database systems. By taking turns each individual can emphasize their area of expertise in the build master role. That way, if the skill is important to the whole team, the skill is also important for the build master role. Eventually all areas of expertise will get addressed eventually.

One more benefit of taking turns is that all team members walk in "the build master's shoes". There is a much better understanding of and buy-in by the team for build master related tasks and challenges. The response to being chased down because of a broken build will be tainted quite differently than if the same person is in the build master role.

At the moment I'm experimenting with swapping the build master role at the end of each release cycle (currently one month). And already the above mentioned effects have become visible.

---

Also check out "Manfred's DotNet Blog"