I’m the CEO of ADS, a web development shop in Orlando
Simple project management for agile teams
Find me on Twitter
The Old Way
Requirements -> Design -> Implement -> Verify -> Maintain
Waterfall
The Old Way
Requirements -> Design -> Implement -> Verify -> Maintain
Waterfall
The Old Way
Requirements -> Design -> Implement -> Verify -> Maintain
Waterfall
The Old Way
Requirements -> Design -> Implement -> Verify -> Maintain
Waterfall
The Old Way
Requirements -> Design -> Implement -> Verify -> Maintain
Waterfall
The Old Way
Requirements -> Design -> Implement -> Verify -> Maintain
Waterfall
Pros
Find bugs early in the process
Correct requirements now, less problems later (in theory)
Emphasis on documentation - developers hate doing this
Simple and disciplined
Good for stable projects
Cons
Each step is not mutually exclusive
Developers are usually (not) clairvoyant
Documentation overhead
Rigid and inflexible
Stable project?!
Reality
Development phases overlap
Software is emergent - the farther along we go the more we know
“Done” is a moving target
Flexibility is required - business requirements and the environment changes
Collaboration is essential
Lays out the philosophy for agile development
Individuals and interactions over process and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Agile Myths
Lack of discipline - “self-managing” = do whatever you want, when you want
Lack of visibility
“That won’t work here”
What is Agile?
Group of philosophies and practices that provides the ablility to handle changing requirements
Iterative development
A lot of collaboration between business and developer
Have self-organizing and self-managing teams
Stressing leadership over management
Utilizing these and a set of practices, a team gains the ability to continuously adapt.
Agile Methods
Extreme Programming (XP)
Test Driven Development (TDD)
Feature Driven Development (FDD)
Behavior Driven Development (BDD)
Scrum
Scrum!
A framework for developing complex products and systems
Grounded in empirical process control theory
Transparency
Inspection
Adaptation
Three inspect and adapt points
Sprint Review and Planning meetings
Daily Scrum
The Retrospective
The Scrum Team
Product Owner
ScrumMaster
The Team
Called pigs: they have their bacon on the line
Involved, but aren’t committed
Users, stakeholders (customers, vendors), managers, and business units
The driving force behind the process
Helps the team and organization adopt and use Scrum
A leader, not a manager
Roles they play: coach, teacher, and supporter
Manages and controls the product backlog
Responsible for the value of the work done
Keeps the product backlog in priority order, visible to everyone
A single person, not a committee
Must have authority, and the respect of others to succeed
Single point of contact for the team
The ones turning product backlog items into increments of potentially shippable functionality
Cross-functional: everyone that needs to be on the team to make the stories happen
Self-organized: everyone contributes
No job descriptions, no titles, no exceptions
Sink or swim as a team
Optimal team size: 7, +- 2
Team composition may change at the end of a sprint; be careful in doing so
Product Backlog
Managed by the Product Owner
Evolves along with the product and the environment
Master list of all functionality desired in the product
Includes all features, functions, technologies, enhancements, and bug fixes
Requirements are typically written in user story format
User Stories
How we write our requirements
From the user perspective
User Stories
Product Backlog
Sorted in order of priority
Requirements never stop changing
Minimize work: add fine-grained detail to the highest priority items (for the next few sprints)
Release Planning
Purpose: establish a plan and goals that everyone can understand and communicate
Establishes
The goals of the release
The highest priority Product Backlog items
The major risks
Overall features and functionality that the release will contain
Probable delivery date and cost if nothing changes
Composed of Sprints that deliver increments of the product, starting with the most valuable and most risky
Once enough increments are completed, release!
Most planning is done at the beginning of a release
Sprint
Sprint: 1-4 week block of time; all sprints are the same length
Protected by the ScrumMaster - no changing once it's started
Sprint Planning Meeting
When the iteration is planned
Max 8 hours for a one-month sprint, or 5% of the total Sprint length
Two parts
Sprint Planning Meeting: Part 1 - What
4 hours
The Product Owner and Team mutually determine what functionality will go into the Sprint
Considers the Product Backlog, the latest increment, team capacity, and past performance of the team
Only the team can say what they can accomplish in the upcoming Sprint
Sprint Goal: the purpose statement of the Sprint, the "why"
Sprint Planning Meeting: Part 2 - How
4 hours
Team determines how it will deliver a "done" increment
Identification of tasks - where the details are
A single task should take no more than one day
Sprint backlog - the list of tasks
Team self-organizes to assign and do the work
Negotiation between the Team and the Product Owner happens here
Sprint Backlog
All of the tasks required to turn Product Backlog items into "done" increments
Break each user story down so that changes in progress can be understood in the Daily Scrum
Modified during the Sprint as-needed
Tasks are added and removed if unnecessary
Tasks are estimated in hours, by the Team
Only the Team can change the Sprint Backlog during a Sprint
Highly-visible and real-time
Sprint Backlog
All of the tasks required to turn Product Backlog items into "done" increments
Break each user story down so that changes in progress can be understood in the Daily Scrum
Modified during the Sprint as-needed
Tasks are added and removed if unnecessary
Tasks are estimated in hours, by the Team
Only the Team can change the Sprint Backlog during a Sprint
Highly-visible and real-time
Sprint Backlog
All of the tasks required to turn Product Backlog items into "done" increments
Break each user story down so that changes in progress can be understood in the Daily Scrum
Modified during the Sprint as-needed
Tasks are added and removed if unnecessary
Tasks are estimated in hours, by the Team
Only the Team can change the Sprint Backlog during a Sprint
Highly-visible and real-time
Sprint Backlog
All of the tasks required to turn Product Backlog items into "done" increments
Break each user story down so that changes in progress can be understood in the Daily Scrum
Modified during the Sprint as-needed
Tasks are added and removed if unnecessary
Tasks are estimated in hours, by the Team
Only the Team can change the Sprint Backlog during a Sprint
Highly-visible and real-time
Sprint Backlog
All of the tasks required to turn Product Backlog items into "done" increments
Break each user story down so that changes in progress can be understood in the Daily Scrum
Modified during the Sprint as-needed
Tasks are added and removed if unnecessary
Tasks are estimated in hours, by the Team
Only the Team can change the Sprint Backlog during a Sprint
Highly-visible and real-time
Sprint Backlog
All of the tasks required to turn Product Backlog items into "done" increments
Break each user story down so that changes in progress can be understood in the Daily Scrum
Modified during the Sprint as-needed
Tasks are added and removed if unnecessary
Tasks are estimated in hours, by the Team
Only the Team can change the Sprint Backlog during a Sprint
Highly-visible and real-time
Sprint Burndown
Graph showing the amount of Sprint Backlog work remaining
Variable of interest: work remaining and date
Daily Scrum
15-minute standup
The Team is responsible for having the meeting
The ScrumMaster ensures it happens, and that it stays short
3 questions
Goals
Improve communication
Eliminate other meetings
Identify and remove impediments
Highlight and promote quick decision making
Improve everyone's knowledge
Daily Scrum
15-minute standup
The Team is responsible for having the meeting
The ScrumMaster ensures it happens, and that it stays short
3 questions
Goals
Improve communication
Eliminate other meetings
Identify and remove impediments
Highlight and promote quick decision making
Improve everyone's knowledge
Increment
Potentially shippable software: the Product Owner may decide to put it into production
Bug free, tested, clean code
Must work with everything already in place
This is where regression testing and continuous integration servers come in
Sprint Review
4-hour meeting for a one-month Sprint, or 5% of the total length of the sprint
The Scrum Team and stakeholders collaborate on what was done
Based on the feedback and changes to the Product Backlog during the Sprint, they collaborate about what to do next
Informal meeting intended to foster collaboration
Product Owner - tells what has/hasn't been done
Team - discusses what went well, what problems they ran into, and what they did to resolve them
Team - demos what's been done, and answers questions
Product Owner - discusses the Product Backlog as it stands
Group - collaborates on what to do next
Release Burndown
Graph showing the Product Backlog estimated effort remaining across time
Product Backlog estimates are reviewed and revised
Keep in mind: the Team is responsible for all estimates
Sprint Retrospective
Held between the Sprint Review and the next Sprint Planning meeting
3 hours max
ScrumMaster encourages the Team to revise their development process to become more effective
Purpose: inspect how the last Sprint went in regards to people, relationships, processes and tools
Identify and prioritize the major items that went well, and those that didn't - discuss how they can be done better
Discuss: team composition, meeting arrangements, tools, definition of "done"
Result: actionable improvement measures