Scrum for Lay People – Part 2 – Key Aspects of Scrum


Key Aspects of Scrum

  • The Scrum Team
    • There are no titles or positions of work authority on Scrum Teams — so no member has any higher authority to answer to on the Scrum team.
      • They may answer to someone in the organization(outside of the Scrum Team), such as for performance appraisals.
    • The Scrum Team operates by consensus and negotiation between the members of the team.
    • The Scrum Team, within loose boundaries set by the organization, is fully empowered to organize every aspect of their team, including, but not limited to:
      • The software technologies they choose to use
      • Team staffing/makeup
      • Team workflow and planning
      • Team members choose their own work assignments
      • Team celebrations and team building activities
      • Working environment, facilities, tools, work hours, etc
    • Though there are no titles, there are 3 roles on a Scrum Team:
      • Product Owner: Represents the customer and decides what features get prioritized by thinking about the relative business value ROI of said features.
      • The Development Team:A team of 5-9 software developers, where there is usually a good overlap of skills, thus reducing bottlenecks.
        • Has full authority over how they work.
        • Has full authority over how much work they plan to take on in a cycle.
        • About the only thing they are not empowered to do is change the Scrum process.
          • Where the Scrum framework is flexible, the Scrum teams are allowed to fulfill the framework however they want to.
      • Scrum Master:One person who:
        • Acts as a servant leader to the Scrum Team.
        • Owns the Scrum process.
          • Ensures that all hard and fast Scrum rules are followed
          • Ensures that, where rules are not defined by Scrum, the team is fully empowered to self organize and operate however they want to.
        • Coaches the Scrum Team and wider organization on Scrum.
        • Ensures that obstacles are removed, including both intra team, and outside the team obstacles.
        • Sometimes facilitates meetings and other activities in order to remove obstacles.
        • Has no authority over how the rest of the Scrum Team organizes their work.
          • The Scrum Master is not a team lead or manager, but the Scrum Master role is considered a management position(as is the Product Owner).
  • The Software Release Cycle (2-8 weeks)
    • Scrum Teams deliver a new, fully functional version of the software to customers every 2-8 weeks, with a preference towards the shorter cycle length.
    • Frequent releases:
      • allow the organization to achieve competitive advantage and be highly responsive to market forces.
      • minimize complexity to reduce defects and waste created by changing business requirements.
      • allow the organization to get really good at releasing, thus minimizing business disruption due to software releases.
    • Scrum Teams work with customers to do high level planning(called Release Planning) that usually encompasses about three months of work.
    • Higher level planning can be done by the organization, in conjunction with representatives of the Scrum Team.
  • The Sprint Cycle (2-4 weeks)
    • Fixed length cycles called “Sprints” enhance feedback(“inspect and adapt”) loops that are built into Scrum.
    • The software at the end of each Sprint must be a fully functioning version of the software, as the Product Owner may choose to ship/release the results of any sprint to customers.
      • Part of the reason for each Sprint’s output being fully functional is that it strongly encourages the development team to always do quality work and almost never have a “I’ll fix that later” or “I’ll clean that up later” mentality.
      • Whether to release or not is a business value ROI decision made by the Product Owner, and ensuring that each Sprint is potentially shippable allows the business to remain Agile and competitive in the marketplace. Said another way, a shippable product allows for maximum Agility to deliver high value, late breaking features to customers.
    • Each Sprint is begun with a planning meeting, where the Scrum Team self organizes to plan their work.
      • There is no person who is authorized to assign tasks to team members.
    • Each Sprint ends with a feedback loop called a Sprint Review for the entire Scrum Team and customers to see the features just produced, and collaborate on the features about to be produced.
    • Each Sprint ends with a feedback loop called a Sprint Retrospective for the entire Scrum Team to reflect on what they are doing well, as well as how they can improve.
      • The team has full authority to experiment with new ways of doing things
    • The Scrum Team meets at least daily for a quick standup meeting(feedback loop) called “The Daily Scrum”
  • Other Key aspects
    • Scrum emphasizes just in time planning, with just enough detail.
    • Scrum focuses very much on complete and quality work and discourages incomplete or shoddy quality work.
    • Scrum does not focus at all on “planned vs. actual” work effort, but instead focuses only on “remaining” work(in the cycle or release) effort.
      • Scrum provides very simple methods for creating hand drawn graphs that helps teams and organizations compare the amount of work remaining to the amount of time remaining in the cycle.
    • The Scrum team’s job is not to product documents. Its job is to produce fully functioning and working software. Where documentation is absolutely necessary, it can be created.
    • Because Scrum is an Agile process, it focuses much more on a reacting to changing business needs than it does to following a preset plan.
    • Because Scrum is a highly collaborative Agileprocess, it strongly encourages(but doesn’t require) that teams be co-located in the same room so as to maximize verbal communication.
      • Agile teams generally prefer any form of verbal communication over any form of written communication or documentation.
    • Because Scrum is a “highly disciplined” process, tinkering with the Scrum framework itself is strongly discouraged by all but the most advanced of Scrum Teams.
      • Said another way, messing with the “formula” usually messes with the results in very significant, and usually very negative, ways.
Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: