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"
Showing posts with label Build Master. Show all posts
Showing posts with label Build Master. Show all posts
Thursday, July 02, 2009
Tuesday, March 10, 2009
Changing People's Mindset
One of the biggest challenges with building and fostering an agile team is to change people's mindset. It didn't take me long to realize that brain washing is not an option, although it is very tempting!
There are different approaches. One approach is to wait until a good opportunity comes up. For instance if there is a particular bug that was extremely painful and maybe somebody suggests to add one more step to the build process.
That's your signal! Ask what that additional step is and ask for more details. Then ask whether the additional step can be automated. And if the answer is 'yes', then ask to add the automation of that step to the build masters backlog. You don't have a build master? Well, then you have just identified yet another item that the team should put in place. You don't have a build master backlog yet? Well, there you go! Yet another opportunity.
So bottom line: This one single event can trigger the introduction of no less than three agile techniques: Automated Testing, Build Master, and Backlog.
The more I work with teams the less I see the need to push things out. Instead there are actually quite a lot of opportunities that present themselves. In other words: You don't have to wait long until such an opportunity is there. And then you can suggest the techniques that worked wonderfully in the past.
And by asking the right questions, again and again, including "How can we test this?" and "How can we automated this?" you drive your message home. Asking the same questions again and again will make sure that people start to change their minds. I have seen it more than once. Just keep insisting on answers to those two and similar questions. Be gentle but insist on those answers. It will pay off!
There are different approaches. One approach is to wait until a good opportunity comes up. For instance if there is a particular bug that was extremely painful and maybe somebody suggests to add one more step to the build process.
That's your signal! Ask what that additional step is and ask for more details. Then ask whether the additional step can be automated. And if the answer is 'yes', then ask to add the automation of that step to the build masters backlog. You don't have a build master? Well, then you have just identified yet another item that the team should put in place. You don't have a build master backlog yet? Well, there you go! Yet another opportunity.
So bottom line: This one single event can trigger the introduction of no less than three agile techniques: Automated Testing, Build Master, and Backlog.
The more I work with teams the less I see the need to push things out. Instead there are actually quite a lot of opportunities that present themselves. In other words: You don't have to wait long until such an opportunity is there. And then you can suggest the techniques that worked wonderfully in the past.
And by asking the right questions, again and again, including "How can we test this?" and "How can we automated this?" you drive your message home. Asking the same questions again and again will make sure that people start to change their minds. I have seen it more than once. Just keep insisting on answers to those two and similar questions. Be gentle but insist on those answers. It will pay off!
Subscribe to:
Posts (Atom)
