Observations from a Recent Scrum Project - Part 1

Recently, I concluded an engagement where I was coaching a new Scrum Team and Product Owner who wanted to build a SharePoint 2010 web-facing content management system with extranet access.  This proved a challenging endeavour on multiple fronts, from lack of proper training and preparation (no time) and experience with the technologies and problem domain to an inconsistent level of engagement for planning each Sprint and defining “done”. 

Over the course of the project, I compiled a diary of observations and notes about what worked and did not work for the Scrum Team and Product Owner as they moved through their project.  Below are the first seven lessons learned I noted: While certainly not new or unknown in agile circles, I present them to edify others who may be taking on a Scrum project for the first time and need some support in making the right choices to avoid problems they might encounter in their implementation.

1. Get training before you start the project.  For everyone.
• While some teams can learn-as-they-go, to be really effective you need to do some dry runs before beginning.  Learn the roles and their responsibilities.  Write some user stories, build and prioritize a Product Backlog.  Decompose it into a Sprint Backlog.  Have a Sprint Review.

• Effective training will give you 40% theory and 60% practical application - you need to do this so that you can begin your Scrum project with less learning curve friction.  You should be able to plan a two week Sprint from start to finish in four hours or less.

2. Scrum is not magic.  It's easy to begin, difficult to master.
• When I instruct teams on Scrum, I make a point of repeating the phrase: "This isn't magic;  it's a framework with rules of engagement that help you get things done."  Too often I find that organizations understand the brochure but not the manual when it comes to Scrum, and this disconnect leads to some shock and awe when the full scope of responsibilities is understood.
   
• Scrum isn't a means to get more done faster - in fact, for new teams they will feel a little slowed down - this is normal because they're building the discipline it takes to be a world-class delivery team.

3. The rules of Scrum are there for a reason:  Don't work around them.
• The first questions I'm often asked by a Product Owner and team is how they can abandon or work around the handful of rules that Scrum requires.  They are there for a reason:  To keep you and your team productive while promoting ROI. 
   
• They have been "play tested" by thousands of teams over two decades - they work because they are simple and effective, but it is hard work to stick to them.  This is why you need a strong Scrum Master / Coach - to keep you motivated as you build your competency.

4. Choose your Scrum Team according to your project.
• It's common sense:  To work effectively, your team needs to have, as an aggregate, the skills required to take on your project.  If they do not, they will move more slowly as they acquire these skills, which can be OK if you've got the budget to accommodate it.

• Having access to a Subject Matter Expert can help a team remove obstacles more quickly, but they are not necessarily an accelerator:  At the end of the day, the team still needs to do the research, whether with the SME or Google, and implement a solution.

5. It takes at least three iterations to get a team together.
• Learning Scrum is easy;  applying it consistently is the challenge.   I often relate the analogy of training to run your first 10k or half-marathon when you have no experience running at all:  You need to understand that newbies will take time to adapt to the pace and practices, and will sometimes falter in their training.
   
• Your new team will likely follow a curve where they are "failing" for the first three iterations as they learn and internalize how to work together as a unit.  Be patient;  expect them to hit their stride in the 4th - 6th iterations. 

6. If you're going to be the Product Owner, be sure you can meet the demands of the role.
• This is a tough and challenging role that has no real analog or precedent:  You are the active guardian of ROI:  You set the goals for each release and iteration and you steer the project based on the inspect/adapt planning and feedback points that bracket every Sprint timebox.  This means keeping your Product Backlog groomed and prioritized with good user stories and working closely with the Scrum Master and Team.

• If you feel that you've got too much on your plate to do this role well, you have two choices:  Delegate your plate to someone else so that you can devote enough attention to the project or delegate the role to someone who can.

7. Celebrate the achievement of every Sprint.
• I make it a point to celebrate the end of every Sprint with each team I coach by taking them out to a pub for a round on me - including the Product Owner.  By the end of a Sprint, a team is often exhausted and exhilarated:  They've hit highs and lows on the road to Sprint Review and they may or may not have made their goal.

• By taking the time to recognize their achievement through a small reward like getting together for a beverage, you validate each team member as a human being and not just a resource.  It gives them a relaxed forum to swap war stories, talk shop or what's up for the weekend while building team morale and loyalty.