I believe that the scrum master should be rather the pastor than the commander. The engineering talent simply is not relevant here. First this person should be able to convince the people (the managers and the team) to observe the scrum principles like the pastor do. Naturally this person should understand the scrum principles.
The scrum works. The IBM PC computer was created in 1980 actually by the scrum method with small self organizing team (12 persons) who operated on their own in a converted warehouse in remote Boca Raton, Florida with only quarterly corporate reviews.
Microsoft included agile method as one of the templates in their Team Foundation Server. Scott Ambler is now the Practice Leader Agile Development at IBM Corporation in the IBM Methods group. And finally Google implemented Scrum in Adwords. You may find the references in my site (the personal blog part) if you wish.
And yes the main problem is to convince the managers and the team that scrum is the
trade off between the innovation freedom and the product delivery according to the schedule.
Actually the problem is in the education and ambitions.
Not all managers are as wise as Ronald Reagan who used to said "Surround yourself with the best people you can find, delegate authority, and don't interfere as long as the policy you've decided upon is being carried out".
If there is no the strict schedule (like in most Google projects, or Open Source) all you need is the good people. However, if you have the schedule and deadline, you need the scrum.
The most of so called "Hungarian notations"(including the ones previously recommended by Microsoft) is the wrong interpretation of the original ones. No wonder that Torvald , Stroustrup, Sutter and Alexandrescu don't recommend them. However, the original notation are quit reasonable and can be found here
http://msdn.microsoft.com/en-us/library/aa260976(VS.60).aspx
Finally, there is the good book
C++ Coding Standards: 101 Rules, Guidelines, and Best Practices
By Herb Sutter, Andrei Alexandrescu
The best advice from this book
" Don't sweat the small stuff. (Or: Know what not to standardize.)". For example " Don't specify how much to indent, but do indent to show structure" etc.
Slashdot Mirror
The scrum works. The IBM PC computer was created in 1980 actually by the scrum method with small self organizing team (12 persons) who operated on their own in a converted warehouse in remote Boca Raton, Florida with only quarterly corporate reviews.
Microsoft included agile method as one of the templates in their Team Foundation Server. Scott Ambler is now the Practice Leader Agile Development at IBM Corporation in the IBM Methods group. And finally Google implemented Scrum in Adwords. You may find the references in my site (the personal blog part) if you wish.
And yes the main problem is to convince the managers and the team that scrum is the trade off between the innovation freedom and the product delivery according to the schedule. Actually the problem is in the education and ambitions.
Not all managers are as wise as Ronald Reagan who used to said "Surround yourself with the best people you can find, delegate authority, and don't interfere as long as the policy you've decided upon is being carried out".
If there is no the strict schedule (like in most Google projects, or Open Source) all you need is the good people. However, if you have the schedule and deadline, you need the scrum.
Linus Torvald Linux Kernel coding style http://lxr.linux.no/linux/Documentation/CodingStyle
Bjarne Stroustrup C++ Style and Technique FAQ (Trivia and style section) http://www.research.att.com/~bs/bs_faq2.html
The most of so called "Hungarian notations"(including the ones previously recommended by Microsoft) is the wrong interpretation of the original ones. No wonder that Torvald , Stroustrup, Sutter and Alexandrescu don't recommend them. However, the original notation are quit reasonable and can be found here http://msdn.microsoft.com/en-us/library/aa260976(VS.60).aspx
Finally, there is the good book C++ Coding Standards: 101 Rules, Guidelines, and Best Practices By Herb Sutter, Andrei Alexandrescu
The best advice from this book " Don't sweat the small stuff. (Or: Know what not to standardize.)". For example " Don't specify how much to indent, but do indent to show structure" etc.