Colocation

One of the main themes of Scrum is the belief that project teams should be colocated. This belief is based on the idea that teams communicate better when they are colocated. We can all attest to this from experience in our own lives. Ever been on a call where one team member states something and everyone else seems to have no idea what they are talking about? While there may be several reasons for the confusion, one contributing factor is the lack of face-to-face communication.

When you are forced to communicate via other methods you lose the benefits of in-person communication. These benefits are:

  • The presence of non-verbal context clues (gestures, facial expressions, etc.) on the part of both the speaker and the listener
  • Presence of conversation/dialogue (other methods of communication tend to be more one-way)

You may think that simply having all your team members in the same building is sufficient in terms of colocation. While this is an improvement over teams being separated by thousands of miles due to the ability to schedule face-to-face meetings, it is still not ideal from a scrum vantage point.

Scrum preaches the benefits of having a Team Room. This room allows your team to be situated in a common area and benefit from the close proximity to teammates (brainstorming, collaboration, etc.). It also serves as the team headquarters and provides a place to post all the project artifacts. When team members are surrounded by their colleagues they have the opportunity to be more consultative to each other and to self-organize/manage themselves.  Also, having a team room makes conducting the daily scrum much easier due to obvious factors (everyone is already together). In later posts, we will talk about the key features of a Team Room.

So in conclusion, when at all possible you should try to insist that your project team is colocated. It will make things easier for you and the team.

Scrum Documentation

Many people feel that scrum means that they don’t have to document the project anymore. That is simply not the case. The reality is that the type of documentation required for scrum is significantly different than the type required for a waterfall-driven project.

Below is an overview of the types of documentation that a scrum project requires.

Product Backlog

    • Describes “what” will be built
    • Managed by product owner
    • Translated requirements into user stories
      • User stories = one or two sentences in language of customer
    • Contains rough estimates (in days)
    • Contains priorities, reprioritized after each sprint

    Sprint Backlog

      • Produced from Spring Planning Meeting
      • Tasks can be of the following types:
        • Design tasks
        • Coding tasks
        • Testing tasks
        • Documentation tasks
      • Tasks are not assigned, but signed up for
        • Each person is working on one task at a time
        • Estimate of the task adjusted daily
      • Tasks cannot be added, but can be removed if out of time
        • Velocity will be established over iterations
          • # of tasks that the team can complete in one sprint

      Sprint Burn-down Chart

        • Shows the number of hours of work left to satisfy all the requirements of the sprint

        Scrum Process

        Below is a high-level overview of the process that occur during a scrum project.

        Sprint Planning Meeting

        • Timeboxed at 4 hours
        • eam negotiates with product owner over what to put in sprint
        • Determine the sprint goal (specific, measurable, demonstrable)
          • E.g. make the application run on SQL server in addition to Oracle.
        • Translate user stories into “how” a requirements is to be built
        • Estimation
        • Estimate in ideal days
        • Play planning poker
          • Each team member gets a deck of playing cards
          • Put down the card for the number of days a user story would require in development time
          • If a user story takes too long, break it down into sub-stories
          • All team members show cards at same time
          • Discuss discrepancies to arrive at agreed upon duratio

        Daily Scrum Meetings

        • No more than 15 minutes in length
        • Traditionally a stand-up meeting
        • Not for problem solving
          • Whole world is invited
          • Only team members, Scrum Master, and product owner can talk
        • Each team member answer 3 questions(signify commitment in front of team)
          • What did you do yesterday?
          • What are you going to do today?
          • What is in your way?

        The Sprint Review

        • Team presents what it accomplished during the sprint
          • Typically takes the form of a demo of new features or underlying architecture
          • Informal meeting
            • 2 hour prep time limit
            • No slides allowed
          • Whole team participates
          • Invite all stakeholders

        Sprint retrospective

        • Performed after every sprint
        • Evaluate what is and is not working
          • Discuss what the team would like to:
            • Start doing
            • Stop doing
            • Continue doing
        • Typically 15-30 minutes
        • Whole team participates
          • Scrum Master
          • Product Owner
          • Team
          • Possibly stakeholders

        Scrum Basics

        Scrum Basics

        • Small cross-functional teams (7 people +/- 2)
        • Series of Sprints (iterations), 2-4 weeks in duration
        • Each Sprint produces a working increment of software
        • To start a Sprint, the team selects & commits to stories from the Product Backlog in priority order
        • To close a Sprint, we demo/evaluate progress
        • Between Sprints, the Product Owner can modify & reprioritize the Product Backlog

        Scrum Roles

        Each agile project is conducted by individuals with the following roles:

        -Product Owner or Product Ownership Team
        -Scrum Master
        -The Team

        The Product Owner is responsible for:
        -Managing and prioritizing Product Backlog
        -Deciding on release date and content
        -Ensuring profitability of the product
        -Accepting software at the end of each iteration

        The Scrum Master is responsible for:
        -Shepherding the team
        -Removing impediments
        -Keeping the process moving
        -Ensuring team is fully functional and productive
        -Shielding the team from external interferences
        -Representing management to the project
        -Socializing scrum to the greater organization

        The Team is cross-functional in nature. It is generally composed of programmers, testers, user experience designers, etc.
        The team is self-organizing, but is accountable to the product owner for delivering as promised.
        The team is responsible for:
        -Estimating size of backlog items
        -Committing to increments of deliverable software – and delivering it
        -Tracking their own progress (with Scrum Master)

        Agile Manifesto Tenets

        What are the core beliefes of agile project management?

        When the authors of the Agile Manifesto were searching for the underlying mantras behind agile project management they came up with the following:

        • Individuals and interactions over processes and tools
        • Working software over comprehensive documentation
        • Customer collaboration over contract negotiation
        • Responding to change over following a plan

        Principles of Agile

        Scrum is one of numerous agile project management methodologies. While each method varies, they all share the following basic principles:

        -Our highest priority is to satisfy the customer through early and continues delivery of valuable software.

        -Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

        -Deliver working software frequently, from a couple of week to a couple of months, with a preference for the shorter timescale.

        -Business people and developers must work together daily throughout the project.

        -Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

        -The most efficient and effective method of conveying information to and within a development team is face-to-face conversation

        -Working software is the primary measure of progress.

        -Agile processes promote sustainable development. The sponsors, developers, and user should be able to maintain a constant pace indefinitely.

        -Continuous attention to technical excellence and good design enhances agility.

        -Simplicity – the art of maximizing the amount of work not done – is essential.

        -The best architectures, requirements, and designs emerge from self-organizing teams.

        -At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.