Agile Primer

Examples of using Agile in the workplace

 

The good, the bad, and the ugly side of the
Agile Methodology

Me

  • Professional LAMP developer for 16 years
  • Based in the Los Angeles area for past 12 years,
    all but ~3 years working for startups
  • Originally from Canada
    (NWT, Kingston ON, Ottawa ON)

9 years in Startups

(not including my own webdev startup in Ottawa)


 

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

My first "Agile" Startup

  • Focused on online education
  • devs worked >60-70 hours per week
  • CEO delegated every task, focus changed on a whim
  • CEO set all deadlines
  • CEO started learning software development when we started missing deadlines

First "Agile" Corporate role

  • Focused on online shopping
  • My workload was delegated; I estimated deadlines
  • Had an all-hands engineering meeting every Thursday to talk about status
  • Worst work week: >80 hours, but was a very rare occurrence

Freelancers 'R Us

  • Big-name entertainment company
  • My workload was delegated; deadlines were pre-determined by managers
  • Weekly team meeting on Friday afternoons
  • Lots of pressure to succeed/produce
  • Worst 2-week work period: 215 hours

Getting warmer ...

and back to startups

  • Startup focused on online advertising
  • My workload was delegated, deadlines were mostly estimated by me
  • Daily stand-up Scrum status meeting
    • included all 30 engineers in one giant circle
    • meeting often took >40 minutes
  • Attempted "kan-ban" at the same time
    • we went through a bazillion Post-It notes
    • duplication of effort on bugs/tasks was annoying
  • I often worked >80hrs/wk for months at a time

Let's try the gaming industry

  • Startup was a social, casual gaming portal
  • My workload was about 50% delegated
  • Most deadlines were estimated or non-existent
  • There were occasional business-value deadlines
  • Twice-weekly status meetings

Double-You Tee Eff?

  • They all called themselves "agile"
  • Is workload delegated or not?
  • Who sets your deadlines?
  • Does it mean working harder or working smarter?
  • Does it involve daily status meetings or weekly?

What exactly IS "agile"?

AGILE

Princess Bride quote, 'you keep using that word, I do not think it means what you think it means'

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

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 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 Dilbert cartoon from March 11, 2011 * 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?"

Tools I recommend

  • Pivotal Tracker
    • Free for Academic Institutions, Non-Profits, and Personal use
    • $7/mo for 3 users, $18/mo for 7 users
  • Rally
    • Free for 10 users
    • Significantly more complex than Pivotal
  • Jira + Greenhopper
    • $10/month for 10 people

Q&A

Dilbert cartoon, September 17, 2011

http://iandouglas.com/presentations/agile/@iandouglas736ian.douglas@iandouglas.com