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.