SCRUM, two months (or years?) into it.

I've been part of two SCRUM rollouts so far.  One was a grassroots effort, the other organizational.  I have some thoughts I'd like to share, in no particular order.

• It's no silver bullet.  Repeat that last sentence 10, 50, 1000 times until you believe it.  If your work habits, talent, training, and support roles suck, your (insert work product here) will still suck using SCRUM.  On the bright side, you'll understand that in 2 weeks to 2 months, instead of years after the product is in the field
• SCRUM teams: 10 people max, and that's pushing it.  Five is better.  I was on a 6 person SCRUM team, and it was great.
• Team of Specialists versus Team of Generalists?  I've no idea.  I've arguments for either approach, and no one answer fits everywhere.  Yay, "It depends."  I could be a consultant.
• The team must see the value in SCRUM.   It's a lightweight process, but it requires them to think and communicate on a level they haven't before.  If it's a drag AND they have to communicate to one another, they'll abandon both.
• Don't B.S. the acceptance criteria.  If you don't complete a user story, you don't get credit, period.  This sort of boundary helps focus the SCRUM team when it's committing to a story.
• Enable the team to organize itself once it's gelled.  Yes, that means kicking the dead weight overboard, too.
• Empower the SCRUM master to do his/her job.  Measure if s/he does it.
• Project Manager != SCRUM Master.  The skillset and attitude is different.
• For heaven's sake, DO NOT MAKE THE TEAM LEAD THE SCRUM MASTER.  I was a team lead and a scrum master for about 2 weeks.  Disaster ensued, and I got help for my team.  Basically, anything that lets the team lapse into a parent/child relationship will destroy a SCRUM team--they must feel like they have the power to make something happen.

Some things that I don't think SCRUM wholly solves (nor seeks to, if you seek a cop-out):

• "Agile fatigue":  Teams get locked into a vicious cycle of committing to 100% of what they can possibly do, then Billy get sick.  Or Bob's mom dies.  Then, the team is behind, and the sprints are/should be too short to recover the loss of resource, so the rest of the team rallies and does Bob/Billy's work.  That leads to resentment, and someone usually ends up as the "goat" for a given sprint.  Sprints get into a rhythm, so a given team isn't given opportunity to relax, and this ends-up fraying the team and fracturing the trust on the team.  Once a SCRUM team is gelled and performing, there's little worse that a breach of trust.

• It doesn't make up for management's job.  You must cultivate, measure, and weed-out your talent pool.  There's precious little slack in an Agile team.  A team of 50 programmers is relatively easy to "Hands-off" manage--I can make that outrageous claim, as I've never been a manager.  If you have 1 unproductive layabout in 50 programmer department, no action is really required.  His peers may know and resent his indolence, but as a manager, what's the pressure to act?  If you have a 5-person SCRUM and 1 person sucks, you're down 20%, and that can't go on.   A SCRUM team is measured holistically on its output, and dead weight must not fester or the whole team suffers.