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.
Commonly Cited Reasons:
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. Iteration / Sprint
## 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
* 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
"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:
Scrum asks you to commit to a goal and then provides you with the authority to meet those commitments.
Scrum insists that you focus all your efforts on the work you're committed to and ignore anything else.
Openness is promoted by the fact that everything about a Scrum project is visible to everyone.
Scrum tenets respect that the diversity of team members' background and experience adds value to your project.
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
* 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?"