Scrum Organizational Framework

I’ve spent the last couple of weeks diving in deeply to Scrum.  As a fan of organizational and productivity methods, this one is AWESOME! :)  It falls right in line with the practices I use to organize myself and have built into my Daily Workbook, yet it expands into how to organize teams to be highly effective.

The Scrum framework challenges traditional project management based on the understanding that a project can meet the standard target measures of on time, on budget, and in scope, yet still not be successful.  When issues arise, one or more of these measures is often sacrificed and the product is what suffers.  This is a large contributing factor the failure rate of most IT projects.

Scrum allows for rapid progress to deliver maximum value.  It is great for software management and works well for the organization of any complex system.  

Here are some highlights about Scrum:

Purpose:  Scrum is a framework that enables agility to advance rapidly while dealing with complex problems.  It is designed to deliver products of the highest possible value while encouraging creativity and efficiency at the same time.  As a framework, this system is not complete by itself but is complemented well by agile and product management methods.

As this framework is used to solve complex problems, it employs Empiricism to create a level of flexible control.  Empirical Process Control Theory is not as defined as a typical process.  Knowledge comes from experience and making decisions based on what is known.  This requires trust and courage as a foundation amongst the Scrum Team. It also has 3 pillars: transparency, inspection, and adaptation.  Throughout the Scrum framework, these principles are applied.

Scrum’s values are the life blood of the framework.  They are: Commitment, Courage, Focus, Openness, and Respect.

Roles and Teams:  One of the keys of Scrum is that there are specific roles that people fall into.  By clarifying these roles, it eliminates ambiguity and speeds the team’s activities.

• Scrum Team – A Scrum Team comes together to deliver value.  There are only 3 roles officially on the team.  There may be multiple Scrum Teams for one product.  The more that a team can stay working together, the better their velocity can be.  Changes to teams cause a drop in productivity.
• Product Owner – Ultimately responsible for the value created by Scrum Team.  There is one product owner per product.  They are charged with maximizing value, being the voice of stakeholders, defining market strategy, and designing the product roadmap.  They own the Product Backlog and decide the priority of items within it.
• Developers – Responsible for technical quality.  The Development Team consists of anyone who builds the product such as Business Analysts, QA, etc.  The ideal size of a development team is 3-9 people.  Each Development Team is self-organizing, cross-functional, and all play the role of Developer.
• Scrum Master – Responsible for Scrum adoption by the organization.  They are a servant leader who serves the Product Owner, Development Team, and overall organization.  They serve by removing impediments to the Scrum Team, facilitating Development Team decisions, and ensuring artifact transparency.  
• Stakeholders – Stakeholders include anyone that interacts with and/or is impacted by the Scrum Team but is not officially on the team.  Their interactions with the Scrum Team are designed in a way that encourages participation at key intervals but also removes contact during times of focus.  This allows for optimal alignment of all parties and maximizes value created.

Events:  Scrum Events create regularity and enable transparency.  Each event is clearly defined with specific frequency, maximum length, and attendees.

• Sprint – Timeboxed period to create a usable and potentially releasable product Increment.  Consistent time periods of 1 month or less (shorter is preferred as the feedback loop is shorter and it increases the competitive advantage).
• Sprint Planning – Collaborative meeting of up to 8 hours where the Scrum Team plans the work to be performed in the next Sprint.  During this meeting, they review the Product Backlog, discuss capacity, forecast PBI’s, craft a Sprint Goal (brief, clear objective for the Sprint), and create a plan.
• Daily Scrum – Daily meeting for 15 minutes max.  Only the Development Team can participate although others can listen in.  The purpose is to align on the plan for the day to meet the Sprint Goal.   
• Sprint Review – Collaborative working session where the Scrum Team and Stakeholders can inspect the outcome of a Sprint and align on what to do next.  The Increment is demonstrated, the Product Backlog is reviewed, market changes are discussed, and timeline/budget are reviewed.  The Product Owner orchestrates the event and adapts the Product Backlog based on feedback.  
• Sprint Retrospective – Private meeting where only the Scrum Team can attend.  This meeting creates a virtuous cycle by reviewing the Scrum Team’s people, relationships, process, and tools to identify improvements that can be made.  It has rules similar to Vegas – what happens in the meeting, stays in the meeting. :)

Artifacts:  The tools used to facilitate this framework are called Artifacts.  Each has a specific owner, purpose, and well-designed activities.  Transparency in the artifacts is critical as decisions to optimize value and control risk are made based on the perceived state of the artifacts.  The artifacts in Scrum include:

• Product Backlog – Ordered list of all known things to create and/or improve the product including features, functions, requirements, enhancements, and fixes.  Each Product Backlog Item (PBI) has a description, order, estimate of effort, and value.  Always evolves and is never complete.  The Product Owner prioritizes items on the list.  Items high on the list are refined as they become closer to being included in a Sprint.  
• Sprint Backlog – Set of PBI’s that are selected for the Sprint that is updated by the Development Team as work is completed.  The Development Team forecasts what functionality is required to achieve the Sprint Goal.  It’s highly visible and real-time.
• Increment – Usable item delivered at the end of the Sprint (must be usable at the end of each Sprint).  A sum of all the PBI’s completed during a Sprint and the value of all Increments from previous Sprints.

Reference:

• Scrum.org
• Improving's class:  Professional Scrum Product Owner (PSPO) 
• http://www.ambysoft.com/essays/brokenTriangle.html