Saturday, March 24, 2012

Helpful Tips - Scrum Feature Teams

Scrum feature teams make up vertical slices of areas of expertise to form cross-functional teams.  Feature teams can help a company scale by allowing team to take ownership of active projects in-flight that must be released in parallel.
Please note, unless your architecture is stable and modules are completely stand alone, be mindful of how many major features are being releasing in a given sprint. I recommend the team limit the number of active projects and never start a new project until the current one is 'shelf ready'


Helpful Tips for Choosing Feature Team Members
* There must be a Lead Product Owner or Master Product Owner that oversees all the inputs and outputs
Per each feature team:
1. One Product Owner.  Each feature team should consist of only one product owner. I will start another discussion on this topic when the same resources are responsible for projects belonging to different product owners.
2. One ScrumMaster.  An experience ScrumMaster is recommended to teach both the product owner and the team to work through sprint goals.
3. The Team. Try to keep the team size limited to three to four developers and no less than one IT QA staff per feature team.

Helpful Tips for Training your Feature Teams

For members new to Scrum
1. Make it very clear to all team members that no one is the boss, it is a horizontal org chart with everyone answering to the client.  Everyone is a subject matter expert of their team function. Each person is held accountable for their role and responsibility during the sprint.
2. If teachers are limited, train development first. Developers appreciate Scrum if you point out that requirements and priorities do not change after the sprint is locked and committed to by the feature team. Check out Jeff's article on shock therapy - http://scrum.jeffsutherland.com/2012/01/scrum-shock-therapy-how-to-change-teams.html
3. Train Product Owners on how to write a user story and break it down into manageable parts. Provide high level training on the Scrum Framework, don't reinvent the wheel, use material provided by your Scrum Certified Professional or what is available on the Scrum Alliance.
4. VERY IMPORTANT - When the team completes estimations and goals can be selected, make sure there is a face to face meeting in which the sprint goals are clearly defined and committed to.  The ScrumMaster only locks the sprint goals when the expression on every team members face shows comprehension.
5. Define a Sprint Activity Calendar and Checklist per each role. This is most helpful when there are old waterfall mindsets on the team.
6. Let the feature team members attempt to follow the checklist according to their role, make the ScrumMaster responsible for ensuring all members complete a full set of checklists by the end of the sprint.
7. The Scrum Coach or Scrum of Scrum Masters must conduct one on ones with each team member on a daily or weekly basis.
8. RETROSPECTIVE IS KEY.  Inspect and adapt.  Train on what is most important, not on everything under the sun, or shall I say 'under the Scrum'.

4 comments:

  1. Dear Piikkila - It looks like your approach to Scrum takes into account the necessary concerns for companies of varying size; I especially agree with your recommendation that no more than 2 product components (feature teams) release code in a given sprint. Upper management must be on board with this, else the developers can fall prey to getting behind. Keep up the vision and hard work!

    ReplyDelete
  2. Thank you for the comments! Indeed you have recognized one of the most common issues with Scrum methodology transitions. Executives without experience in different technologies fall prey to their old project projections and have a tough time trusting their teams developing in new technologies where the foundational work can take up to 3-6 sprints (depending on your sprint iteration) before anything is tangible to an end user. The company can combat this by clearly defining the company goals at a Quarterly and Year View. Allow the product/dev teams to assess and provide realistic expectations to the executive team before locking down the release plan. Wanna learn about the MetaScrum????

    ReplyDelete
  3. The Scrum Team is sometimes referred to as Development Team since they are responsible for developing the product, service or other results. It consists of a group of individuals who the user stories in the Sprint Backlog to create deliverables for the project”. – SBOK 2013 Edition.

    ReplyDelete