I think this is one case where the training would be very valuable. Although a lot of it is simply team lead best practice stuff. I led my first project in 1988 when I knew absolutely nothing about leading a team. I had 4 years experience as a C hacker and had kept my eyes and ears open and learned stuff.
The project succeeded beyond my best hopes, in large part because of my predecessor. He had experience and good ideas but didn't have the technical skill under Unix to make the tools work. The first thing I did was fix the tools and learn from them. I also spent a week with him at his office. That helped a lot. Before that I'd spent hours in bars after work with an older colleague who had run construction projects before moving into IT. I used the Golden Rule and tried never to do anything to someone which I wouldn't like done to myself. If something I tried pissed off one of my people I'd change and try something else the next time. That's about it.
And I took a walk around the floor every morning. Once I had my setup going I'd get in at 9 and have a look at the results of the overnight regression tests to see the state of the built system. Did I mention the overnight builds and
test runs? Then I'd get a cup of
coffee and walk around and ask how things were going. Any hangups? Ok, I'll get back to you. I had to finish my walk after all. Sometimes it turned out the problem impacted several people. If there was a problem with the build or one or more regression tests failed I'd report that fact in a low-key way to the developer who broke it and tell him the req was re-opened. That was it. I was prepared to come down like a load if it became a habit but it never did. It happened twice with only one guy and that was a strange situation. I was prepared to help out if I could. Actually everyone was on that team. Does this sound a little familiar?
In the space of 6 months we went from taking a month to make a new build to being able to build, test, and redeploy in 2 hours. No big deal today in a world with
JUnit, Cruise Control, and
Maven. But I'd never seen it done before. We cut the list of outstanding bugs by 90%, improved performance by a large factor and doubled the number of concurrent users we could support at one time on the same hardware. Someone had gotten a bit enthusiastic with malloc(). By allocating initial memory more judiciously we were able to cut the memory profile of a user session by about 40%.
This was all team stuff. I didn't touch a line of C code in 6 months time. I didn't have the time to. Too busy clearing obstacles from my people's paths, negociating bugs, writing tests, packaging work into decent packages complete with a handy-dandy regression test the programmer could run to see the problem(s) and test whether his work fixed the problem. I also expected them to run the short suite of regression tests before dropping the code. Basically everything but the soak tests, which took hours and which I mostly ran over the weekend.
What struck me about SCRUM was the morning SCRUM session. Short and sweet. It was immediately obvious that it would work a charm if used correctly.
The reason I think the SCRUM courses are important is that SCRUM is a tool which can help you a lot or can hurt you disasterously if misused. To make SCRUM work everyone has to drop their defenses and trust. If that trust is violated even by mistake SCRUM can turn into a clusterf... (er, disaster).. I can usually work around a poor team lead but not if I have to drop trou in a SCRUM inquisition every morning. :roll:
Well that was overstated. A single mistake won't kill you, particularly if it is honestly recognized and corrected. It's when it turns into the morning session of the Spanish Inquisition that the wheels fall off.
So if there is a chance you might screw it up spend the sawbuck and talk to an expert. Even if you're not screwing up but others on your team are spend the sawbuck. It costs far less than recruiting a new team does!