Scrumcrazy_header5.jpg
scrumcrazybtn.jpg

For Training, Coaching, and Consulting engagements, please contact me for details on how I can help your organization.


To see a more basic description of Scrum, see Scrum For Lay People


Disclaimer: Since this is a description for lay people, many of the Scrum details have been glossed over and oversimplified at times. As such, some of the words used here are actually incorrect, but correct enough for a lay understanding. If you want a full understanding of Scrum, then the only way to get that is to read the Scrum Guide and/or get certified in 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
    • There are no titles on a Scrum Team, but there are 3 roles on a Scrum Team
      • Like positions on a football team, these 3 roles were created to reflect the best practices in team-based software development.
      • Product Owner:Represents the customer and decides what features get prioritized by thinking about the relative business value ROI of said features.
        • The Product Owner is also the one that approves features once they are complete, signifying that the development team has delivered what the Product Owner (and by representation, the Customer) wanted.
      • 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 Delivery "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 by being highly responsive to market forces.
      • minimize complexity to reduce defects and waste created by changing business requirements.
      • allow the organization to optimize and perfect their release process, 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.
TheSprint.png
  • The "Sprint" Cycle (2-4 weeks)
    • Once a release is planned, the team breaks down the work for the release into multiple "Sprints."
    • These "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.
      • Whether or not to release the output of a Sprint is a business decision made by the Product Owner.
        • For instance, the Product Owner may want to:
          • wait until a certain amount of functionality is in the system so as to reduce customer confusion, OR
          • time the software release to coincide with a marketing campaign, OR
          • take advantage of market timing, OR
          • respond to a competitor's actions, OR
          • any other business reason that the Product Owner can come up with that enhances business value.
        • 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.
      • 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 strongly discourages team members from having a "I'll fix that later" or "I'll clean that up later" mentality.
    • Each Sprint begins with a planning meeting, where the Scrum Team self organizes the plan of attack for the Sprint.
      • Self organization means that the team collaborates and there is no one person who is in charge of (or has authority over) any other team member.
        • One might think that self organizing teams might be prone to laziness, lack of direction, or gridlock, but Scrum Teams are still held accountable, as a team, by those (outside of the Scrum Team) who pay their salaries and/or fund their budgets.
    • 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 to be produced in the next Sprint.
    • 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
    • Each day, a feedback loop (meeting) called the "The Daily Scrum" occurs.
      • The Daily Scrum
        • lasts no longer than 15 minutes, AND
        • is intended to encourage the team to collaborate on how to solve problems and optimize work efficiency AND
        • is almost always a standup meeting.
  • Other Key aspects
    • The Scrum team's primary measure of progress is working software that delights customers.
      • As such, documentation is only created when it is deemed absolutely necessary.
    • 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.
    • Because Scrum is an Agile process, it focuses much more on 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.

coaching(4).jpgForScrumMasters.jpgForProductOwners.jpgForScrumDevelopers.jpgPresentations.jpg