Lesson Learned Expanding Scrum

To start, Scrum is a flavor of Agile. A good beginning description of Scrum is available here:
http://www.controlchaos.com/
Or here:
http://scrumforteamsystem.com/ProcessGuidance/Scrum/Scrum.html I particularly direct your attention to some of the videos on this site.

OK...Prior to the meeting on May 10, someone gathered together the following list of "lessons learned" from a variety of sources, including Scrum-Dev, books and other places.

Lessons Learned for growing Scrum (starting a new team)

One might think of these as the success factors for implementing Scrum. You will notice that the presumption is that the way to implement Scrum is most importantly focused on...actually implementing it with a team (Ex: not focused on doing a lot of preliminary work prior to doing "real" work).

People

Recruit the best people you can (Ex: for teams, product owners, etc.)
Recruit people who are capable (for that project)
Recruit people who /want/ to do Agile (don't force anyone to do it)
Recruit people who fit together (Ex: want to work with each other)
Keep a team close to 7 (plus a coach); usually the Product Owner is part of the 7
Recruit a good Product Owner
Minimize other people "issues"

Other

Tell management to be available if needed, but otherwise leave the new Team alone (The Product Owner will watch that the investment is reasonable.)
Educate the business about their new role
Support collaboration; support collaboration; support collaboration
Typically, do not put too much pressure on new teams (inhibits willingness to learn & change)
Minimize any behaviors / rewards / feedback loops that cause people to hide (Ex: so much buzz around Agile that some people pretend to like it)
Recruit and grow the best coach(es) you can find (internal/external)
Remove impediments (Ex: other departments that slow things down, better engineering practices, etc, etc); make visible to many that impediments are being removed
Reward successful teams (team members); reward people willing to change to Agile (or to better Agile)
Balance keeping a team together with germinating a new team with Agile-experienced people
Support the coaches (it's a weird & hard job)
Set realistic expectations about the rate of (cultural) change people can move through [25% of juice in year 1, 25% more in year 2, etc.]
Don't expand too fast!

At The Meeting

In the meeting on May 10th, the members expressed the following lessons learned:
{Attendees: Feel free to improve the wording of these.}

Get high-level buy-in/support; not just lip service
Motivated people {Comment: In his connection see the HBR classic Herzberg article here: Motivation.}
Somewhat harmonious team members
Better: both top down and bottom up -- and meet in the middle
Good engagement with sponsor & other business partners; daily or multiple times per week
Team members know priorities - Which project am I really on? Focus
Snacks & games
100% committed P.O. (short for Product Owner) --> with authority to make decisions
Some Software Dev engineering discipline {Comment: One might argue that Scrum enables you to identify and prioritize which engineering improvements are most useful. Thus, the "if I were you I wouldn't start from here" syndrome is avoided.}
No chaos; need goals
Focus on groups / areas that are not Agile
Shared vision -- Team and P.O.
Innovative thinkers {Comment: Creaivity and learning are /so/ important in SW dev.}
Need planning -- at least one Iteration ahead
Some controls in place

By no means did we identify all the ideas that the Team had. Please add more!

Note that many of these have no explanation as to /why/ they were recommended. If people have comments/questions about that, please post them as Comments to this page or in the Yahoo Group (see Front page). Hopefully someone will answer (correct answers will cost extra).

apln-richmond