Observations from a recent Scrum Project - Part II

In the previous installment of this series (Part I), I introduced the first seven observations and notes that I had compiled over the course of a recent project where I was engaged to help a new team and product owner shepherd a small SharePoint 2010 portal into existence using Scrum.

Here are the next seven observations that in contrast to those in Part I, go a little deeper into the meat of organizational and implementation challenges that new Scrum teams encounter.

1.  Build a Release Plan. Revisit and revise it often.

• It’s difficult to know if you are reaching the “promised land” without knowing what it looks like.  A release plan sets out goals for each iteration along with expected features.
  
• Go through the activity of building the plan to first determine if the project is feasible within stated parameters like cost and budget.  Return to the release plan as a preface to each Sprint Planning session and Sprint Review.

2.  You can only go as fast as your team.

• Your project can only progress as fast as your team can deliver features according to their abilities and your definiton of “done”.  Don’t goad them into taking more on to satisfy your ambitions:  It will only lead to an increased probability that they won’t fully deliver a functional, potentially-shippable product increment.
  
• Do not fall into the trap of believing that overtime solves all problems: In reality, quality often suffers as a result.

3.  Set an explicit definition of “done” and stick to it.

• When you set a goal for a Sprint or Release, be explicit with a shared understanding of what it means when a feature is considered “done”.  Often, this defaults to the old trinity of coded/tested/documented, however even this needs clarity: 
• Coded: Usually means writing the code, ensuring it compiles without breaking and is checked-in;
• Tested: Is wide-open to interpretation: Developer unit tests? Acceptance tests?  Automated?
• Documented: This can mean comments in the code, along with capturing pertinent design details in a central repository like a wiki.  On this project, it was deemed satisfactory if a feature could be traced from requirement to implementation and back again.  Fortunately, TFS with the Microsoft Visual Studio 1.0 Scrum template along with associating checked in code to a work item made this a snap.
  
• Without a definition of done that is set and agreed-to by the Product Owner, the team is left to their own devices to determine this, which can and does lead to unpredictable results.

• On the flipside of each user story card, you should capture some simple criteria to prove that feature has been implemented according to spec.  If you run out of room, you may need to break the feature up as you’re likely discovering new usability scenarios.
  
• This tripped up my team on several occasions, and often left QA wondering what they were testing.  This takes practice to be diligent about capturing and remedying.

5.  Involve QA as part of the team from the start.  Give them automated test tools.

• When QA is integrated into the Scrum Team, they are able to understand and discern features and create effective test plans by actively engaging the developers.  This has to happen on a daily basis.  It’s too late to leave it even for a few days.
  
• QA will fail if they are expected to run tests manually; they will fall behind and never catch-up.  Get them an automated UAT suite so that they can compile their test cases and run them automatically at the push of a button.  I recommend Telerik’s Web UI Test Studio.

6.  Don’t design in absence of the team.  Iterate.

• Wireframes and PhotoShop mock-ups are great for “seeing” a design and gettings a feel for it.  However, when they are developed in exclusion of physical implementation by the team, you really have a simulated sense of reality.
  
• This simulated reality often comes at a high cost the longer you wait to implement it;  it can and does create gaps where the mock-ups “hide” how certain features are designed to work, which leads to significant re-work later on, and always takes a lot of work to implement.
  
• Integrate design into planning for each iteration so that the team can translate them into working software.  The goal of every dollar spent in a project should be directed toward creating a functional, potentially-shippable product increment every two weeks.  Period.  Full-stop.
  
• Give your design time to breathe; leverage the opportunities that Sprint Review provides to check your assumptions against reality.  Adjust and improve every iteration.

7.  Trust the team.

• Don’t obsess over whether the team knows what tasks to take on and that you or a Project Manager knows better.  They can and will organize themselves around the work to be done in the most efficient manner because it is always less painful to do so.
  
• Have a question about the product under development?  Ask the team.
  
• Have a question about a new feature you’d like to see in the next Sprint?  Ask the team.
  
• The team will always have a deeper understanding of your product and the challenges faced to make it real:  Always be transparent.  Always take any issue or question to the team.