Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That doesn't mean processes, documentation, plans, etc aren't necessary.
But given the choice, they're not as important.
Why Agile?
Commonly Cited Reasons:
Reduced Time-to-Market
Increased Quality
Reduced Waste
Better Predictability
Better Morale
Forrester Research, 2007
## Risk Deduction
* Iterative and incremental development provides feedback loops.
* Feedback loops provide opportunity to learn, reducing future risk.
* Focus and visibility provide better information for decision making.
## Even Agile has a 12-step Program
* There are 12 core principles of Agile to cover.
* I'll try to provide examples as we go along.
### Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
* In other words: "deploy code early and often".
* Features and Bug Fixes must be balanced.
### Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
* Shifting priorities is 'teh suck', but sometimes it's very necessary.
* Embrace it, don't hate it, but if it becomes a problem too often, speak up "early and often".
### Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
* Develop a short "sprint" cycle, try to deploy code at the end of the sprint.
* I recommend a two-week sprint.
* Try to deploy code within the sprint if possible, especially bug fixes.
### Business people and developers must work together daily throughout the project.
* The business people are what we call "product owners".
* Product Owners MUST:
* be available for questions from the team
* assist in setting priorities
* filter upper management and developers from one another
* Transparency will lead to better direction.
### Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
* Also, let them choose their workload.
* Trust is crucial.
### The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
* Daily Scrum meetings are essential.
* for remote workers, video chat is always better than plain audio
* I recommend Google+ Hangouts where possible
* Never be afraid to call a huddle.
### Working software is the primary measure of progress.
* Are Bug Fixes more important than Features?
* This can backfire on longer projects.
* Ideally project is broken down into smaller deliverables.
### Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
* Jim Franklin, CEO of SendGrid: "rested racehorse"
* Average day of highly effective intellectual work: 5-6 hours
* 2 week sprint = 40-48 hours of development per person
### Continuous attention to technical excellence and good design enhances agility.
* It's easier to maintain high-quality code. (use coding standards)
* Push towards test-driven development, especially for regression tests.
* Find other shortcuts.
* eg. don't invent your own CSS, use Bootstrap
### Simplicity—the art of maximizing the amount of work not done—is essential.
* Automate the boring.
* If you can't automate it, it might be too complex.
### The best architectures, requirements, and designs emerge from self-organizing teams.
* Often hard, especially in very small startups.
* There's also a tough balance of people who want to be involved in knowledge meetings, and those who do not.
### At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
* Have a "retrospective" meeting at the end of every sprint.
* What got done? Not done?
* What went well? Not so well?
* Discuss external blocks (other teams, external vendors)
* What are we going to improve on next time?
* What were we going to improve? Did we do it?
## In other words...
* focus on customer value
* deliver early and often
* reduce batch size
* make quality a priority
* inspect and adapt
* foster a collaborative culture
## Agile Planning Levels
1. Daily
1. Iteration / Sprint
1. Release
1. Roadmap
1. Vision
## Practical Implementation
Two week sprint break-down:
* sprint planning day
* 4 work days
* backlog grooming day halfway through sprint
* 3 work days
* retrospective and demo day
## Sprint Planning Day
* Team members discuss availability
* Product Owner is present to discuss priorities
* Stories, Bugs, Chores are chosen
* For each item of work, discuss:
* commit to finish?
* requirements, so anyone can do the work
* acceptance criteria
* QA process, unit and functional tests
* deployment strategy
* planning poker
### Planning Poker
* Uses Fibonacci sequence to describe complexity of a story/task
* 0,1,2,3,5,8,13
* very complex projects (epics) get pt values of 20, 40, 100
* *Everyone* must vote at the same time, must reach unanimous decision
* General rule of thumb: 1 point = half a day's work
* your mileage may vary
* ["Software Estimation"](http://goo.gl/CRHq2)
### Why do we care about points?
* Points help you track a velocity (effort over time) so when similar projects come up, you can better estimate the level of effort.
* They also help plan your sprints more accurately based on how much you know you can handle.
* Teams within a larger organization may each have their own velocity. This is normal.
### The Fist of Five
Scale of 1-5 on how confident you are the team can accomplish everything you're COMMITTING to.
It could even be done per story/bug/chore if it contains a lot of tasks.
1. I am very opposed, we should not move forward.
1. I have some reservations I'd like to discuss.
1. I can live with it, and will support it.
1. I think it's a great idea, wish I'd thought of it.
1. ERMAGERHD BESTEST IDEA EVAR!!!11!!!one!
## Backlog Grooming Day
If this is done well, it shouldn't take more than half a day, unless your team is EXTREMELY overloaded with work.
Backlog grooming is never really "done", it's always evolving
## Main Goals of Backlog Grooming
* Review requirements for stories to flag them as "ready"
* Constantly breaking down stories into smaller pieces/tasks for estimation
* Re-rank low-priority items
* Add/Refine acceptance criteria
## Backlog Process
* Product Owner must be in attendance to discuss any shifted priorities at a project level
* P.O. is responsible for maintaining the backlog, and ensuring value delivery
* P.O. provides the voice of the customer/market
* Any stories/chores or bugs related to the next project should be pioritized
* For each story, discuss:
* requirements, obtain any missing information
* you *can* estimate effort here if you have time
* business value, customer value
## Retrospective
"Hindsight is 20/20" - source unknown
### What got done? What didn't get done?
* Talk about work the team committed to complete and why anything didn't get finished.
* Be civil, but be transparent.
### What went well? What didn't go well?
* Talk about several positive things among the team
* "pair programming caught several bugs before deploy"
* Discuss things that didn't go well
* "that meeting on Friday took too long, lost productivity"
### Did we have any major roadblocks?
* Talk about things that blocked the team from getting work done
* Meetings, outside vendors, knowledge transfers
### What can we improve on for next sprint?
* Discuss 2 or 3 very specific goals for the team, like writing better documentation
### What did we say we were going to improve on? Did we do it?
* Review the last retropective notes
* Carry over items if needed
## Definition of Ready
* Is there a user story defined?
* Have the general requirements been formed and documented?
* Have acceptance criteria been formed and documented?
* Has an initial high-level estimation been provided?
* Has application architecture been reviewed for impact?
* Has User Experience (UX) been reviewed for impact?
## Definition of Done
* Functionally complete
* 90% Code Coverage with Unit tests
* Functional tests written for regression testing
* System monitoring is ready
* Metrics collection is ready
* Deployed to a staging environment for review
## What about Scrum
Scrum is sometimes referred to as a "flavor" of Agile.
Scrum has 5 core values:
### Commitment
Scrum asks you to commit to a goal and then provides you with the authority to meet those commitments.
### Focus
Scrum insists that you focus all your efforts on the work you're committed to and ignore anything else.
### Openness
Openness is promoted by the fact that everything about a Scrum project is visible to everyone.
### Respect
Scrum tenets respect that the diversity of team members' background and experience adds value to your project.
### Courage
Scrum asks you to have the courage to commit, to act, to be open and to expect respect.
## Daily Scrum Standups
* These are invaluable for a team.
* Should be optional, with caveats.
* The highest priority: keep it short.
* Second priority: choose your workload.
* Someone is delegated as leader of the meeting: Scrum-Master
* Scrum-Master is generally a dedicated "interrupt" filter for the team
### Optional?
* Scrum meetings should be optional.
* Down side is people feel out of the loop.
* One incentive is to choose your own workload.
* Important: if you *choose* not to be there, you should not complain to the team when you do not understand something or get stuck with less-fun stories/chores.
* If certain people are consistently absent, there's a bigger issue to address as a team.
### Keep it Short
* Scrum actually mandates that you literally stand up for meetings whenever possible
* Each person on the team gets to talk
* Scrum-Master takes notes, especially about blocks
* Now is not the time to problem-solve, take it "offline"
### Answer Me These Questions Three
* What did you accomplish yesterday?
* What will you be working on today?
* typically coincides with picking a new story/task to work on
* Are you blocked on anything?
## Scrum of Scrums
* All Scrum-Masters meet to discuss progress and blocks
* "Is your team on track?"
* "Is your team blocked on any other team?"
* "Is your team about to block another team?"
* Each person on the team gets to talk
* Scrum-Master takes notes, especially about blocks
* Now is not the time to problem-solve, take it "offline"
