# "Shut up and ship it" ### How Agile Methodology may help your startup ## Ian Douglas

 

* interrupt with brief questions any time * extended Q&A at the end
# Agenda * my experiences with "agile" * let's learn what Agile really is * planning: your next workload, your TODO list * doing a Retrospective * quick overview of Scrum * how will ANY of this apply to your startup? * tools I recommend * further research and reading
# Me
  • Professional open-source Web Developer for 16 years
  • Started hacking on a Commodore 64 thirty years ago
  • Based in Los Angeles area ~12 years
    • almost all in startups
  • Originally from Canada
    • NWT, Kingston ON, Ottawa ON
  • Graduate of St Lawrence College, Kingston ON
    • Computer Engineering Technology
## Names left out to protect the guilty * I'll avoid the names of the companies I describe * Business practices change all the time
## I represent myeslf * While I have permission to discuss how we've implemented Agile at my current workplace (SendGrid Inc), I am here representing myself and not my employer. * This advice may not work for you

My "Agile" Startup Jobs

Let's examine my jobs where "agile" was in the job/company description

Industry size (ppl) avg hrs/wk delegation deadlines standups?
Credit Reports 4-6 70+ CTO
Education 7 60-70+ CEO CEO
Commerce 30-80 60+ CTO, me me weekly
TV Entertainment 6 (500+) 90+ Director Director weekly
Online Advertising 35-120+ 80+ Director Me, usually daily
Gaming 5-7 80+ Manager, Me semi-weekly
SendGrid 110+ 50 Me Me daily

What exactly IS "agile"?

Who thinks it means:

  • stand-up meetings?
  • long hours == productivity
  • delegated workloads vs your choice
  • delegated deadlines vs your estimates
  • something else?
## AGILE ![Princess Bride quote, 'you keep using that word, I do not think it means what you think it means'](montoya.jpg)
## Strictly Speaking...
  • Agile doesn't mandate daily stand-up meetings
    • that's SCRUM
  • Agile hopes your work breakdown makes for simpler planning
    • better planning => better hours
  • Agile teams should be "self forming" to work on what they choose
    • within reason, you should choice your own workload
  • Agile does speak on the importance of estimation
## Important: Implementing the Agile methodology:
  • just affect how you CREATE SOFTWARE
  • should not only change how you SCHEDULE MEETINGS.
## Methodologies are like Religions*

 

* Most people subscribe to one * Everyone who does thinks theirs is the right one * Everyone who follows one will try to convert you

 

###### this isn't meant to bash on religion in any way

Agility

[uh-jil-i-tee]
noun

  1. the power of moving quickly and easily;
    nimbleness: exercises demanding agility.
  2. the ability to think and draw conclusions
    quickly; intellectual acuity.

The Agile Manifesto

http://agilemanifesto.org © 2001


"We place higher value on:

  • 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:

  1. Reduced Time-to-Market
  2. Increased Quality
  3. Reduced Waste
  4. Better Predictability
  5. 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 ot scrapping work is 'teh suck'
    • sometimes it's very necessary.
  • Embrace it, don't hate it
    • 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.
  • While not part of "pure" Agile, 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. Vision 1. Roadmap 1. Release 1. Iteration / Sprint 1. Daily

5 circles of Agile planning

## Typical Development Workflow: * A product backlog is created/maintained * Customer feedback helps determine priorities * Developers break down backlog into sprints * Sprint stories broken down into tasks with time estimates * Sprint work is completed, tested, and deployed * (repeat)
## Comparing Costs of Agile ![comparing the cost of typical development over agile](devcosts.png)
## Typical Development

 

<-- TIME
Analysis
Design
Code
Test
## Agile Development

 

TIME -->
      Analysis
      Design
      Code
      Test

Practical Implementation

Two week sprint break-down:

  • sprint planning day
  • backlog grooming day halfway through sprint
  • retrospective and demo day
  • 7 full work days
     
    MON
    TUE
    WED
    THU
    FRI
     
     
    sprint planning
    work
    work
    work
    work
    backlog grooming
    work
    work
    work
    retro & demo
     
     
     
## Wait ... 40-48 hours of work every two weeks?? * Average developer gets about 6 hours of productive work every day * Sprint planning day should take a full day * If your backlog is huge or retro/demo take all day, you lose two full days * 7 days * 6 hours = 42 hours of productive work
## 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:
    • do we commit to finish this?
    • 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
  • Some say you should never equate points and time
  • Software Estimation
### 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; 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
# 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" ![Dilbert cartoon from March 11, 2011](dilbert-scrum.gif)
### 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?"
# How will any of this # apply to you? * not everything we've discussed will apply to your startup * let's discuss ways to apply bits of Agile * save the rest for later
## "Done is Better Than Perfect" * deploy early and often * implement a 'beta' program your users can opt into * let them see iterative changes * balance bugs and features carefully * don't be the next Digg 4.0
## Plan. Then plan to re-plan. * changing direction is much easier in a startup * get feedback often from trusted customers
## Implement Sprints * try different sprint lengths for a while * find your groove * likely, two weeks will work best * deploy code within the sprint
## Implement Daily Scrums * your team communication is already as good as it's going to get * formalizing actual scrums just to cover its three pieces will help
## Work towards implementing ## a coding standard * this will be time consuming * checking can be automated * be firm about it as the team grows
## Work towards Test-Driven Development * this will also be time consuming * lets you work toward Continuous Integration/Deployment
## Reserve time for a retrospective * strive for transparency
# What won't apply yet? * which parts of Agile won't apply until you grow?
## "Product Owners" are also business decision makers, and likely also your development team * generally this would be a conflict of interest
## Low-Population Companies
  • self-organizing teams to tackle projects
  • scrum of scrums
  • demos don't need to wait until end of sprint
    • they'll likely happen naturally as you deploy
## "Rested Racehorse" * In the words of Rick Ross, "Every day I'm hustlin'..."

Engineering vs Humanity

  • "Humans are not scalable"
## Automate the Boring * this may be too time consuming unless you have pockets of downtime * consider contracting this out if funds allow?
## are we still talking Agile? * the idea of removing things that don't add immediate value is actually one of the key tenets of the Lean methodology

Tools I recommend

  • Pivotal Tracker
    • Great tool for tracking work using Agile
    • Free for Academic Institutions, Non-Profits, and Personal use
    • $7/mo for 3 users, $18/mo for 7 users
  • Trello
    • Save a tree, use Trello for KanBan
  • Jira + Greenhopper
    • bug tracking
    • $10/month for 10 people
## Further Reading/Research

Q&A

Dilbert cartoon, September 17, 2011

iandouglas.com/presentations/shutup-shipit@iandouglas736 #agile • ian.douglas@iandouglas.com