Hands up if you…
- have responsibility for a product or project?
- manage a team?
- work in a team?
- have heard of Agile?
- have heard of Scrum?
- Richard Herbert MSc CSM - [email protected]
- Originally started in architecture and engineering
- Got into computing via structural analysis
- Moved into IT management
- Been a freelance web developer since 2001
- MSc Internet Systems Development
- Certified Scrum Master since 2014
- Available for weddings, christenings, Bar Mitzvahs and other Agile opportunities
- Requirements
- Design
- Implementation
- Integration
- Testing
- Installation
- Maintenance
- Installation
- Testing
- Integration
- Implementation
- Design
"We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value…"
|
Individuals and interactions Working software Customer collaboration Responding to change |
over over over over |
processes and tools comprehensive documentation contract negotiation following a plan |
"That is, while there is value in the items on the right, we value the items on the left more."
- Our highest priority is to satisfy the customer through early and continuous 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 weeks to a couple of months, with a preference to 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 users 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.
From: Shakespeare, Will
To: Macintosh, Cameron
Subject: Hamlet
I've got this idea for a scene...
"To be, or not to be, that is the question.
Whether 'tis Nobler in the mind to suffer
The Slings and Arrows of outrageous Fortune,
Or to take Arms against a Sea of troubles,
And by opposing end them?"
From: Macintosh, Cameron
To: Shakespeare, Will
Subject: Re: Hamlet
Nope, I'm not geting it.
From: Shakespeare, Will
To: Macintosh, Cameron
Subject: Re: Hamlet
Okay, let me pop over with my actor mate, Larry and we can go over it.
From: Shakespeare, Will
To: Macintosh, Cameron
Subject: Hamlet
I've got this idea for a scene...
"To be, or not to be, that is the question.
Whether 'tis Nobler in the mind to suffer
The Slings and Arrows of outrageous Fortune,
Or to take Arms against a Sea of troubles,
And by opposing end them?"
From: Macintosh, Cameron
To: Shakespeare, Will
Subject: Re: Hamlet
Nope, I'm not getting it.
From: Shakespeare, Will
To: Macintosh, Cameron
Subject: Re: Hamlet
Okay, let me pop over with my actor mate Larry and we can go over it.
Thank you very much and enjoy the rest of your day…
Embrace change
Frustration with failure
Looking for another way
Focus on doing the right thing
Give the customer what they want - value
- A philosophy
- An attitude
- A frame of mind
- Dynamic Systems Development Method (DSDM)
- Feature Driven Development (FDD)
- Extreme Programming (XP)
- Lean Startup
- Kanban
- Scrum
Concept proposed in 1986 by Hirotaka Takeuchi and Ikujiro Nonaka (HBR)
"a flexible, holistic product development strategy where a development team works as a unit to reach a common goal"
A framework that supports the Agile philosophy
Concept proposed in 1986 by Hirotaka Takeuchi and Ikujiro Nonaka (HBR)
"a flexible, holistic product development strategy where a development team works as a unit to reach a common goal"
A framework that supports the Agile philosophy
- “A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value”
- Call projects “Products” to signify we will deliver a tangible benefit - value
- Empirical approach to getting things done
http://scrumguides.org/
Transparency
Inspection
Adaptation
Roles
Events
Artefacts
Product Owner
Development Team
Scrum Master
Product Owner
Development Team
Scrum Master
- Discovery Phase
- Sprint Planning
- Sprints
- Daily Standup
- Product Backlog Grooming
- Sprint Review
- Sprint Retrospective
- User Story Map
- User Stories
- Product Backlog Items
- Definition of "Done"
- Burndown Chart
- Product Increment
Product Owner
Development Team
Scrum Master
- Represents the Customer
- Holds the Product Vision
- Domain Expert
- Has organisational respect to drive through the vision
- Decides the priorities
- Works with the Dev Team
- Provides detailed insight
- Owns the User Stories
- Owns the Product Backlog
- Do the work
- 5 - 9 members (7 ± 2)
- Works with the Product Owner
- Estimates the User Stories
- Decide how things are done
- Owns the Sprint Backlog
- Commit to deliver regularly
- Cross functional self-organising professionals
- Works for the Scrum Team
- Servant - Leader
- Facilitates the Scrum Process
- Supports Product Owner
- Resolves impediments
- Maintains the Scrum Values
- Protects the Team from interference
Product Owner
Development
Team
Scrum Master
Customers
- Discovery Phase
- Sprint Planning
- Sprints
- Daily Standup
- Product Backlog Grooming
- Sprint Review
- Sprint Retrospective
- Establish Product Vision – Product Owner
- Map User Stories – Everyone
- Write User Stories – Product Owner
- Define the Definition of “Done” – Development Team
- Prioritise Product Backlog items – Product Owner
- Estimate Stories – Development Team
- Not time-boxed
- Has output but not shippable (NOT Sprint Zero!)
- Scrum Team members can come and go
- Short and to the point
- Limited to an index card
- Promise of a further conversation
- Includes acceptance criteria
- Estimated with Story Points
A promise of a further conversation
- Personalise - Give them a name
- Backstory - Why are they coming to you?
- Attributes - Motivation
- What needs to be done
- What activity needs to be performed
- A narrative that briefly describes what the persona wants to achieve that will deliver value
- Something that can be tested
- Why are we providing this feature?
- What is the business value?
- What will the return be?
- Is the effort too great?
- Could the Product live without it?
| I | Independent | The user story should be self-contained, in a way that there is no inherent dependency on another user story |
| N | Negotiable | User stories, up until they are part of an iteration, can always be changed and rewritten |
| V | Valuable | A user story must deliver value to the end user |
| E | Estimable | You must always be able to estimate the size of a user story |
| S | Small | User stories should not be so big as to become impossible to plan/task/prioritise with a level of certainty |
| T | Testable | The user story or its related description must provide the necessary information to make test development possible |
- Can do
- Give technical insight
- Write technical stories
- Define the test criteria
- Definitely
- Owns the Stories
- Provides the detail
- Defines the Acceptance Criteria
- Justifies business value
- Rarely
- Advises
- Guides
- Facilitates
- A polite word for a guess
- Improves with experience
- Cone of uncertainty
"The exact number of candies in this jar can not be determined by looking at it, because most of the candies are not visible. The amount can be estimated by presuming that the portion of the jar that cannot be seen contains an amount equivalent to the amount contained in the same volume for the portion that can be seen" http://en.wikipedia.org/wiki/Estimation
"Every year there is a new estimation technique. The real Agile approach would be to throw estimates out"
Ron Jeffries - Agile Manifesto co-author
- A popular movement in the Agile world
- Considers estimating a waste of time
- "At the one point in the project when I know the least about it you want me to commit to a timescale and cost!"
- A ship's Captain can only see as far as the horizon
Linguist Geoffrey Pullum stated the quotation was "completely straightforward" and "impeccable, syntactically, semantically, logically, and rhetorically. There is nothing baffling about its language at all."
http://itre.cis.upenn.edu/~myl/languagelog/archives/000182.html
- Not time but effort based sizing
- Tee-shirt sizing (small, medium, large, x-large)
- Trouser sizing (short, regular, long, x-long)
- Dogs (Chihuahua, Greyhound, St Bernard, Great Dane)
- Story Points
- Relative sizing (1, 2, 3, 5, 8, 13, 21, 34)
- Planning Poker
- All show their hand at the same time
- Discuss and justify variations
- Agree the effort – if not, break the Story
- Team Velocity
- Initially a guess
- Indication of capacity
- Indication of completion
- Burndown Chart
Story Points:
The separation of the estimation of effort from the estimation of duration
- Unit tests written
- Deployed to Test environment
- Documentation written
- Committed to blessed repo
- Code written
- Tests passed
- Ticket updated
- Previewed to Product Owner
- Peer reviewed
- Shown to my Gran
“In preparing for battle I have always found that plans are useless, but planning is indispensable”
…or…
“Plans are worthless, but planning is everything”
- Review prioritised Product Backlog
- Get missing detail from Product Owner
- Understand Acceptance Criteria
- Define Sprint Backlog
- Commit to deliver in Sprint
- Review the Definition of "Done"
- Iterations of work
- Time boxed
- Between 1 - 4 weeks
- Always delivers a Potentially Shippable Product increment
- Practices of eXtreme Programming (XP)
- Embrace Change (expect requirements to evolve)
- Pair Programming (working together on a task)
- Test Driven Development (check ideas frequently)
- Sustainable Pace (don’t work weekends)
- Co-Location (work with the customer and team)
- Continuous Integration (deliver value frequently)
- Refactor (work on the problem as it is now)
- Small Releases (get stuff out soon)
- I've got this idea...
- I've got this idea...
- I've got this idea...
- Actually, can I change that?
- I've got this idea...
- Actually, can I change that?
- Okay, now I know!
- Same time!
- Same place!
- Every day!
- Everybody!
- Whole Scrum Team
- Product Owner
- Development Team
- ScrumMaster
- 15 minute catch up on how everyone's doing
- “What I did last time”
- “What I’ll do this time”
- “What’s stopping me”
Maybe we should call that refinement?
- Product Owner
- Add more Stories
- Reorder Backlog
- Add more detail
- Development Team
- Add more Stories
- Ask questions
- Re–guesstimate
- ScrumMaster
- Advises on User Story content
- Development Team “show and tell”
- Audience – Product Owner and Stakeholders
- Demonstrate shippable business value
- Get agreement to deploy to Production
- “Wot went right?”
- “Wot went wrong?”
- “Wot can we do better?”
“Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand”
Retrospective Prime Directive - Norman L. Kerth
- Agile – A set of values to work by
- Scrum – A framework to work within
- Roles – An agreed understanding of responsibilities
- Events – A series of knowledge sharing opportunities
- Sprints – Deliver value on a regular cycle
- Artefacts – A collection of items that show progress
Play Video
Questions?
Feedback?
Comments?
- Richard Herbert
- [email protected]
- @agilemix
- +44 (0)7717 846090
- agilemix.com/presentations