This is a primer on the ideas/ls of Agile. They are not what most people think they are, and it would behoove many people to take time to learn what they really say.

The Agile Manifesto:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

Declaration of Interdependence:

We …

Increase return on investment by — making continuous flow of value our focus.
Deliver reliable results by — engaging customers in frequent interactions and shared ownership.
Expect uncertainty and manage for it through — iterations, anticipation and adaptation.
Unleash creativity and innovation by — recognizing that individuals are the ultimate source of value, and creating an environment where they can make a difference.
Boost performance through — group accountability for results and shared responsibility for team effectiveness.
Improve effectiveness and reliability through — situationally specific strategies, processes and practices.

Other types of Agile other than Scrum:

XP (Extreme Programming) – Focused on partner-programming and deep code reviews
TDD (Test Driven Development) – Focused on, well, TDD

Scrum – A type of Agile

Transparency – Visibility to people responsible for outcome
Inspection – Regularly assess how doing related to goals
Adaptation – change process to fix problems

Defined By:

Do just enough prep before starting work to be able to the work
Short sprints, 2-4 Weeks
Customer (The Business) must talk with the developers regularly

Team needs:

Product Owner – The business rep, maximizes value from sprints
Scrum Master – Process owner, ensures SCRUM is followed
Dev Team – Everyone on dev team is equal, there are no bosses, though people can work on specific things.

Ceremonies:

Sprint Planning Meeting
Grooming (technically not a formal Scrum event)
Daily Scrum (Standup)
Sprint Review – PO and Scrum team and customer meet to demo
Retro – Team assess selves

Documents:

Product backlog – all work to be done to deliver full product
Sprint backlog – work to be done in single sprint – highest value items first
Product Increment – Part of overall product that can be released to customers on its own

Fail Fast => Learn Quickly

It’s ok if people make mistakes if they were trying. The point is for us to do so early before we build lots on top of the broken. We need to trust each other. We don’t blame people for mistakes, we are a team, they are team problems, not individual problems

Visibility/Transparency

Definition of “Done”

Sprint Goals – Should be very visible and reviewed often – make sure you meet them

Burn down – Shows work as it gets completed

Burn up chart – Should how us when the product will finish, based on what is in backlog and velocity

Team makes its own rules, solves its own problems.

Team makes its own definition of “done” – It’s the TEAMS decision if QA should be removed from the “done” requirement

Inspection/Adaptation

The team should be inspecting what they are doing to see if it is working, and change their processes if they are not.

All Scrum events are opportunities to analyze your process and refine it.

Value Driven Delivery

This is the POINT of Agile – Focus on Value

Product = Value

Value to Customers

What gives most value to customer?

Vertical slicing

Itemize each valuable deliverable

Defining Value

Requires Defining Value – Acceptance Criteria

Agreeing up front – helps minimize waste

FOCUS ON VALUE DELIVERED!

Short Sprints

Short sprints allow you to fail faster.

2 week sprints you fail much faster than 4

Short sprints also show value to stakeholders more often

Team Size

Team has 5 – 9 people

Dev team specifically is 3-9 people

Then you need a PO and Scrum master

Up to 12, but that gets to be a challenge, anything beyond that needs to be broken into multiple teams.

Multiple Teams

Scrum of Scrums

With multiple teams, Scrum masters from each team meet 2-3 times a week to coordinate efforts between teams.

Scrum Events:

Events should be timeboxed based on the length of sprints. If you have longer sprints your events will need to be longer – except Daily Scrum, which is always 15 minutes.

Sprint Planning:

Every sprint should create a working product increment.

What is needed for Sprint Planning Meeting:

The Backlog needs to be ordered
Items completed in last sprint
Velocity of team
Dev Teams capacity (is anybody on vacation?)

What can we do that will result in a product increment?
How will we do it?

PO provides a list of possible items for sprint and Dev Team decides which ones to accept, with the mind toward creating a working product increment.

Sprint Goal is defined:

Sprint goal is: Summary of the work and the value that will be delivered in the product increment.

Daily Scrum (standup):

The daily Scrum (also known as standup) is a daily, timeboxed 15 minute meeting, where everyone on the team goes of:

What they did yesterday
What they are doing today
Any roadblocks

Scrum Guide Says:

Scrum Master does NOT attend Daily Scrum, they only ensure it happens.
The Product Owner ALSO does not attend the Daily Scrum.

Scrum Alliance Says:

Entire Scrum Team Addends
Any member can provide updates

Team members can meet after Daily Scrum to talk about things that came up.

Backlog Refinement:

This is an ongoing process where the PO gathers information needed for items in the backlog.

ALSO: Backlog Refinement can be a meeting after the midpoint of sprint. Inspect backlog items and dev team asks for clarification on things targets for next sprint. Sounds like Octopus Grooming. Scrum Guide does not have this meeting, but Scrum Alliance does.

How to tell if item is ready for a sprint:

Sized small enough to fit in a sprint
Dependencies are identified and managed
Acceptance Criteria has been defined

Sprint Review:

This is the inspect and adapt event for the Scrum team and all the key stakeholders. Product increment is the subject of the event. This is the second to last event in the sprint. Usually held in the afternoon to give the morning to finalize anything. Questions from stakeholders are encouraged! Timeboxed meeting. Probably 2 hours.

Things gone over:

PO gives sprint goal and issues worked
Demo
PO goes over issues in next sprint
Open discussion with stakeholders – capture feedback
Turns feedback into backlog issues

Demo:

Timeboxed!

The point is to demonstrate value to Stakeholders.

Stakeholders need to be at demo!

It is their opportunity to give feedback

Timing demos is important.

The higher the risk the more often you should demo.

Customer feedback need for quality

You can even demo every week instead of at the end of sprints OR Every other sprint!

They do not have to follow the sprints

More often = more informal / less often= more formal

Might make sense to demo before releases, not with sprints

Sprint Demo

Demos the stories completed in the sprint

PO or Devs can demo, then stakeholders give feedback or missing requirements (those are hopefully stories further down the backlog, but might need new stories.)

Product Demo

Show stakeholders the collective product as it is being built

This is a demo that gives a cohesive view of what the product looks like

This should be done for every release

Sprint Retrospective:

Focused on Scrum team. This meeting is about how the team can make improvements for themselves and their process.

Things to review:

What went well – consider why they went well and how to keep momentum going
What didn’t go well – why didn’t they go well and how can we improve that

Then look at both lists and decide what to focus on in next sprint – you should only pick 2-3 ites to work on in the next sprint, or it will become too much. These need to stay visible to team through sprint.

Release Need to be Valuable:

MVP – Minimum Viable Product

MMF – Minimum Marketable Feature

MVP = MMF

MVP Advantage –

Feedback sooner
Early ROI

Backlog Prioritization

Backlog MUST stay prioritized with what the customer values most as the highest priority

It is the PO’s responsibility to organize the backlog – But they get their demands from the stakeholders.

The backlog exists as long as the product exists.

Items in the backlog are Product Backlog Items, or PBIs

Backlog contains:

Features
Functionality
Requirements
Defects
Enhancements

Prioritization Options:

Kano:

Exciters
Satisfiers
Dissatisfies
Indifferent Features

MoSCoW:

Must Have
Should Have
Could Have
Would like to Have

Lots of other ways you can do it too.

Sprint Backlog:

Subset of backlog with the items that are to be completed in the sprint.

The Dev Team NOT the PO decides what is to go into the Sprint Backlog. This is because the goal is to create a working product increment, and the Dev Team is best suited to identify what PBIs can create a working product increment.

Decision Making

Everyone is involved in decision making, and you are looking for convergence, team and stakeholders.

Agile Charter

Focuses on project goals, not what will be built.

Who will be engaged in project?
What will the project be about?
Where will the work happen?
When will the work happen?
Why was the project needed?
How will you work?

Need Vision

Need Definition of “Done”

Agile Modeling

Ways to model things, and get feedback from stakeholders – Should be used every time you start work on new valuable deliverables

Diagram use cases
Model data structures
Sketch screen designs
Wireframe
Personas – User use description

Status updates

Status reports suck – don’t use them

There are the charts (burndown, etc.)

Need to have conversation with stakeholders

What to Communicate

Charter
Vision
Sprints
Release Plan
Burn Charts
Project Risks
Quality/Defect stats

Forecasting short term results is a lot easier than long term (duh)

Product Demo

Show stakeholders the collective product as it is being built

This is a demo that gives a cohesive view of what the product looks like

This should be done for every release.

Adaptive Planning

Constant planning – planning to plan

You are planning every day.

Everything is planning.

Progressive Elaboration

Incorporating new information into plans to reprioritize backlog.

Every time you release an MVP you need to reevaluate all of your previous plans – did the process change any of your plans? This should be a big meeting with stakeholders where everyone gets to have input on how priorities have changed. Then the backlog will need to be reprioritized.

Possible Additions

Iteration 0 (Sprint 0)

Iteration 0 an option addition that is basically a sprint before the first sprint that allows you do to things such as:

Identify resources
Setup workspaces
Setting up environments
Establishing a vision
Early planning
Hiring
Training

Doesn’t have to be length of full sprint

Iteration H (Hardening Sprint)

Hardening, finalizing, testing, documenting – before product moved to production

Architectural Spike

Short (like 1 week) while team investigates PoC

Risk-Based Spike

Used to test new-untested technology

Relative Sizing

Used because people are better at comparative sizing than actual sizing

Fibonacci – follows normal growth patterns and normally used

Estimation Techniques

Wideband Delphi: Team anonymously submit estimates to avoid bias (not actually used much)

Planning Poker: Most widely used (would have to research)

Team Roles:

Role: Project Sponsor

Usually senior leadership and not directly involved day-to-day

Main Project Advocate
Final Decision Maker

Role: Product Owner

Soul accountable party for the product the team is building.

Should be a person from The Business.

Need to be able to answer Dev Team questions.

Need to be able to negotiate backlog items.

Must be able to talk with other people in business.

Makes the decisions about product vision and the features that are needed.

Represents stakeholders.

Dev team only takes orders from PO.

Responsible for maximizing value.

PO -AND ONLY THE PO- manages the backlog.

A proxy can be used if the PO can’t dedicate the full time – but the PO is ultimately responsible.

A Business Analyst can work with the PO to help them prioritize for the business.

Though the PO is responsible for the backlog they can delegate responsibility to parts of the Dev Team, especially in the case of technical issues they don’t understand.

PO Responsibilities

Clearly define Backlog issues
Order/Manage Backlog
Ensure Backlog is available to the team, and across the Business.
Clarifying requirements
Providing status and forecast

PO Can abnormally terminate a sprint early – usually done when current work is found to have no value, and should be stopped.

PO does NOT manage the team – only the backlog

Role: Scrum Master

NOT the manager of the team

They manage the Scrum process, NOT the team

They instruct everyone – Dev team, Product Owner, Business – on Scrum process

They are the SERVANT of everyone

Protects team from outside distraction
Protects team from overcommitting
Protects team from complacency – makes sure team keeps refining and improving their process
Owns the Scrum framework – They are the ones who actually decide how/if process can be changed

Scrum Master’s Jobs

Clarify Goals and Objectives
Coach Best Practices
Guide Process and Planning
Facilitate Scrum Events
Share Knowledge

SM has their own Scrum event – Product Backlog Refinement

Role: Development Team

Builds product

Role: Stakeholder

Who are the stakeholders?

PO, Scrum master, team, and sponsor – brainstorm on this is.

Who are direct users of the product?

Executives, manager, who in the company?

The stakeholders need to be told about Agile.

They need to be present in demos.

Definition of Done

The Definition of Done is something that should constantly be reviewed. This is different from the Acceptance Criteria of a PBI, ACs are different for different PBIs, DoD is across the board for all PBIs. Teams should have a defined definition of done for all PBIs, and constantly be reviewing it. Possible DoDs include:

Unit tests written
Reviewed by another developer
Passes linting

Team Norms

Ground rules created by team to guide the project and how team members interact.

Norms should be reviewed and updated every couple months – maybe after every MVP goes live? Should spend an hour in a norming session.

Possible rules:

Silence means consent – if you disagree, speak up
No meetings before noon on mondays, or after noon on Fridays
All opinions and ideas will be considered equally and thoughtfully
Team members will ask for help as soon as they know they need it
Team members will keep commitments to each other
Team members will hold each other accountable for maintaining norms
People will talk respectfully and thank each other for contributions
No devices in meetings without team consent
All decision made by consensus
Agree to try to resolve conflicts inside of team before going outside of team

Skills

Though everyone should have specific skills, team member should have general skills too, to be able to help with other tasks

Swarming

When team members use secondary skills to help reach the sprint goal.

Collaboration and Commitment

The space you are in can include:

Product Vision
Task Board
Design Models
Burn down
Burn up
Team Norms

No reason we should be looking at things like burndown during the standups

When co-located, things like standups twice a day might make sense

Velocity

Usually takes 3-4 sprints to get an established velocity.

Calculating: total points done / number of sprint = velocity

Can be used to calculate how much longer project will take

Risk

Can have brainstorming meeting about risk:

Goal to just ID possible threats

Assess how likely to happen, and how bad it will be if it does

Should be considering risks in planning meetings

Risk Register

Owner of Risk
Mitigation Plan
Escalation Path – where does owner go if they need help

Kaizen

Agile is based on Kaizen (hey my mom did that in the 90s!)

This means improving the quality of the work by making small adjustments over time

The Retrospective is a clear use of this idea. It is asked:

What went well?
What can be improved?
What can be done differently to improve?

Growing Skills

Pair Programming
Skill Shares
Encourage continuous learning

Lean

A way to identify and eliminate a system’s waste without affecting productivity.

Adapted from manufacturing.

Partially done work
Extra processes
Extra features
Task Switching
Waiting
Motion
Defects

Value Stream – The path a new idea has to go through to get to the customer

This should be mapped out, and you can then see where you can make it better

You can map any processes Value Stream – like deployment process, and see where the problems are.