Agile Scrum : Best Practices

  Agile Scrum: Framework

My Name is AK and today we will discuss Agile Scrum

This will be a lengthy blog so do grab a cup of coffee and hop on!

The Layman definition of ” Agile ” is the ability to move ” quickly and easily”

The 4 core values of Agile software development as stated by the Agile Manifesto are:

1. Individuals and interactions OVER  Processes and tools
2. Working software OVER  Comprehensive documentation
3. Customer collaboration OVER  Contract negotiation and
4. Responding to change OVER   Following a plan

12 principles behind the Agile Manifesto are as below :

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done
6. The most efficient and effective method of conveying information to and within a development team is a face-to-face conversation
7. Working software is the primary measure of progress
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely
9. Continuous attention to technical excellence and good design enhances agility
10. Simplicity–the art of maximizing the amount of work not done–is essential
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly

Agile manifesto encompasses  several pre-existing methodologies including:

• Scrum
• Extreme Programming
• ScrumBan
• Adaptive Software Development
• Crystal
• Agile Up
• Feature-Driven Development
• Pragmatic Programming
• Lean Development

However “Scrum ” is the most popular form of Agile which is widely used in the Software development industry

Definition of Scrum:

A framework within which people can address complex adaptive problems while productively and creatively delivering products of the highest possible value

 SCRUM is Easy to Understand but ” Difficult to Master ” 

Key Idea’s:

• Iterative and Incremental Framework
• Requirement Volatility
• Self-Organizing, Cross Functional, Co-location and face to face Communication
• Empirical process: Inspection, Adaptation, and Transparency
• SCRUM ROLES (3 Roles): Product owner, Development team (3 to 9 members) and Scrum Master
• THE SPRINT: Time – Boxed Event (1 to 4 weeks)
• SCRUM EVENTS: Sprint Planning, Daily Scrum, Sprint Review and Sprint Retrospective
• SCRUM ARTIFACTS: Product Backlog, Sprint Backlog and Product Increment

 Agile Scrum: Roles, Ceremonies, and Artifacts

SCRUM ROLES (3 Roles)

Product Owner, Development Team, and the Scrum Master

1) Product owner

The product owner represents the product’s stakeholders and is the Voice of the Customer

• Defines Goals, ROI, business value and announces releases
• Writes user stories on the INVEST model
• Organizes milestone reviews
• Educates stakeholders on the development process
• Negotiates priorities, scope, funding, and schedule
• Ensures that the product backlog is visible, transparent, and clear

2) Development team (3 to 9 members)

• Build’s product increments (analysis, design, development, testing, technical writing, etc.)
• Maintains sustainable pace, self-organizing, track sprint progress, whole team accountability
• Empowered, Dedicated, Independent, cross-functional and continuous collaboration

3) Scrum Master 

The core responsibilities of a scrum master include

• • Supports the PO and Dev Team
  • Coaches the team, within the Scrum principles, in order to deliver high-quality features
  • Promotes self-organization and Facilitates team events to ensure regular progress
  • Process Champion and Impediment Remover
  • Educates key stakeholders on Agile Scrum
  • Coaches the development team on the benefits of cross-functionality
  • A team facilitator and Servant-leader
  • The roles, ceremonies, and artifacts are summed up in the table below

    

    SCRUM EVENTS

    1) The Sprint: Time- Boxed Event (1 to 4 weeks)

    Sprints will have consistent durations throughout the development effort

  • A new Sprint start’s immediately after the conclusion of the previous Sprint
  • Sprint consist of Sprint Planning, Daily Scrums, the Sprint Review, and the Sprint Retrospective
  • Each Sprint may be considered a project in Agile Scrum with no more than a one-month duration
  • Like projects, Sprints are used to accomplish something
  • Each Sprint has a goal of what is to be built, a design, the work, and the resultant product
  • Frequent changes are not recommended which can result in sprint failure
  • The scope can be clarified and re-negotiated between the PO and Sponsor as more is learned

• • 2) Sprint Planning: Time – Box Event (4 Hours Max for a two-week long Sprint)

•  Sprint Planning would answer the following:
• What can be delivered in the Increment resulting from the upcoming Sprint?
• What work needs to be done to achieve the increment?
• Fibonacci series (1, 2, 3, 5, 8, 13, 21 etc.) or doubling method is followed to estimate story points
• Sprint Goal is an objective set for the Sprint which can be met by implementing the Sprint Backlog
• Sprint Goal provides guidance to the Development Team on why they are building the Increment

3) Daily Scrum: Time – Boxed Event (15 Min)

In Agile Scrum, the Daily Scrum would start

1. Will happen at the same time and at the same place every day
2. Anyone is welcome, though only development team members should contribute
3. Scrum master captures any impediment (e.g, stumbling block, risk, issue, delayed dependency) for the team
4. No detailed discussions should happen during the daily scrum
5. Each team member typically answers three questions:

• What did I complete yesterday that contributed to the sprint goal?
• What do I plan to complete today to contribute to the sprint goal?
• Do I see any impediment that could prevent me or the team from meeting our sprint goal?

  

4) Sprint Review: Time – Boxed Event (2 hours for a two-week sprint)

   In a typical Agile Scrum process, the sprint review is a meeting where:

• The team demonstrates the completed work in the sprint
• Presents the completed work to the stakeholders/Product Owner for validation/sign off
• Agile Scrum works on (0-100)% complete rule so incomplete work are not demonstrated

5) Sprint Retrospective: Time – Boxed Event (1.5 hours for a two-week long sprint)

At the sprint retrospective the team will:

• Reflect on the past sprint
• What went well during the sprint?
• What DID NOT go well during the sprint?
• Reflect on the team velocity and quality
• Identify and agrees on continuous process improvement action

  

Scrum Extensions (Part 1): Not Generally Considered part of “Core Scrum”

 1) Backlog refinement: Time-Boxed Event (10% of a team’s sprint capacity)

In Agile Scrum, the Backlog Refinement /Grooming would be done only when:

• PO reviews the product backlog and finds out that they need to re-prioritize an item of urgency
• If the team need to re-estimate as the original estimates in the Sprint planning meeting were flawed/incorrect

2) Sprint 0: Time-Box Event (3 days Max for any number of Sprints)

In Agile Scrum, the Iteration Zero/Inception Sprint/Hardening of the sprint is NOT a good practice and is done only when

• The team is working on a product where there is less visibility on the scope
• A detailed investigation needs to be performed considering the complexity/sizing
• A study on the high-level application architecture on how the features will likely be implemented
• Sprint 0 is not a good practice as it takes away the urgency context
• It does not deliver a working software or valuable functionality at the end of the sprint 0

3) Canceling a sprint: (Anytime during a Sprint)

In Agile Scrum Cancelling, a Sprint is extremely rare and is done only under the circumstances below

• The Customer may advise the PO to cancel a sprint if external circumstances negate the value of ROI/Sprint
• In an event of abnormal termination, the reason and deliverable produced are still reviewed
• Only the Product Owner has the authority to cancel a sprint

 SCRUM ARTIFACTS

1) Product Backlog:

• The product backlog would comprise an ordered list of product requirements
• Product backlog items vary, common formats include user stories, use cases or any other format the team finds useful
• PO prioritizes product backlog items (PBIs) based on considerations such as risk, business value, dependencies, size and date needed
• The product backlog is what will be delivered, ordered, or the sequence in which it should be delivered
• However, the development team contributes by sizing it in story points or in estimated hours
• It is visible to everyone but may not be changed without the consent of the PO
• The PO is ultimately responsible for ordering product backlog items for the development team to choose
• The PO gathers inputs and takes feedback from many people, but ultimately makes the call on what gets built
• The Product backlog may include new features, replacing old features, removing features and fixing issues
• The Product Backlog features should be prioritized based on the MOSCOW model

2) Sprint Backlog:

In a typical Agile Scrum Process, the Sprint backlog is :

• A progressively prioritized list of deliverables by the Product Owner
• The order of selection is from the top until the team have enough work to fill the sprint
• The development team should consider their previous sprint velocity which figuring out the efforts for the items
• The product backlog items may be broken down into tasks by the development team
• Sprint backlog items are worked based on their priority set by the Product Owner
• Agile Scrum follows the “Pull-based “approach to work assignment
• The pull-based approach promotes self-organization and team buy-in
• No additional work is generally added to the sprint backlog once the team commits to its delivery
• In a special case, the PO after consultation with the customer can add/remove the scope from the sprint
• Once a sprint is completed the product backlog is analyzed and reprioritized
• After the successful conclusion of the sprint, the next set of functionalities are selected for the next sprint

3) Product increment:

• They are the Product Backlog items completed during and before sprints
• At the end of a sprint, the increment must be complete according to the team’s definition of done (DOD)
• It should be fully functioning regardless of whether the PO decides to release or hold it

 Scrum Extensions (Part 2): Not Generally Considered part of “Core Scrum”

The following artifacts are used even though they are not part of core scrum:

1) Sprint burn-down chart:                              

• An information radiator which displays remaining work in the sprint backlog
• The horizontal axis shows days and the vertical axis shows the work remaining
• However, the chart is updated every day as and when the team members update the remaining work

2 Definition of done (DOD):

• In Agile Scrum, DOD is the “exit-criteria “to determine whether a product backlog item is complete
• It may vary from one scrum team to another, but must be consistent within one team
• Acceptance criteria should be verified
• Coding, Regression tasks should be reviewed and completed
• Technical design specifications updated
• Defects are in an acceptable state to the PO
• User story accepted by the PO

Example: DOD of a typical Software/Digital team  

• Code Linting, Review and documentation Complete
• Unit test, Regression tests completed
• If it’s a Microservice, then load, volume and stress test should be completed successfully
• Build pushed to test environment (user story)
• All functionality and tests verified by the QA (optional for implementing unit tests)
• User story accepted by PO

3 Velocity:

• • Total effort a team is capable of in a sprint
  • The team evaluates the work in the previous sprint’s and derives the velocity
  • However, the work to be accomplished  in the future sprint’s depends on the Historical velocity
  • A consistent and predictable velocity helps the team to deliver results
    

    Tools for Implementation

    The following tools are widely used in Agile Scrum :

    1) Jira:

  • It’s an issue tracking product which provides bug tracking, issue tracking, and project management functions

• • 2) Confluence:
  • It’s a content collaboration software used to create, document, organize and discuss work with the team

• • 3) Spreadsheets:
  • Spreadsheets are used to build and maintain artifacts such as the sprint backlog

• 4) Whiteboards, paper, and sticky notes:
• Co-Located teams use Whiteboards, paper, and sticky notes

Scrum Limitations

Agile Scrum is not very effective in the following scenarios:

1) Geographically dispersed or part-time teams:

• Developers should have close and ongoing interaction, working together from the same location
• Agile Manifesto advises face to face communication
• Though Improvements in technology have reduced communication barriers nevertheless co-located teams have a higher success rate

2) Teams Members with very specialized skills:

• Dev team should be able to work on each other’s tasks or at least swarm and help each other
• While team members with specific skills contribute they should be encouraged to collaborate with others

3)Products with many external dependencies:

• External dependencies for shorter sprints can lead to sprint failure
• In Fact, dependencies on other teams can lead to delays or roadblocks
• The external vendors need to understand that the team is Agile

4) Products that are mature or legacy or with regulated quality control:

• A single sprint should be enough to test an increment
• Products which need large amounts of Regression/safety testing like medical devices or vehicle control are less suited

Scrum values

• Commitment: Team members commit to achieving their team goals, each sprint
• Courage: The team has the courage to work through conflict and challenges together
• Focus: They focus exclusively on their team goals and the sprint backlog
• Openness: Agile Scrum teams are transparent on any challenges, they may face
• Respect: Agile Scrum team respect’s each other in good faith and intent

 Scrum Team: Out of Scope activities

• Hiring New Resources
• Appraisals
• Contract Negotiations
• Employee Training
• Budgeting

Conclusion:

• Agile Scrum is a “Framework “and not a Regulation so it can be modified to suit the requirements
• However the “core scrum “ roles, ceremonies and artifacts should be kept intact
• PMP Aspirants looking for certification help can visit my website projectmanagementwithak.com
• I have also documented my PMP lessons learned, link: http://projectmanagementwithak.com/how-to-conquer-pmp/
• Should you wish to read more about Agile please go through the website and books listed below :

1. Agile Estimating and Planning by Mike Cohn
2. Agile and Iterative Development: A Manager’s Guide by Craig Larman
3. Software in 30 days by Ken Schwaber
4. Agile Retrospectives by Esther Derby and Diana Larsen
5. Agile Software Development with Scrum by Ken Schwaber and  Mike Beedle
6. Scrum and The Enterprise by Ken Schwaber
7. Agile Software Development Ecosystems by Jim Highsmith
8. Scrum Alliance by www.scrumalliance.org

Keep learning and keep inspiring!

Regards,

AK, PgMP®, PMP®, CSP-SM™, CSM®, ICP-ACC, ITILv3