Notes from Agile Training from Pivotal Tracker

Please add your notes here.

1. Inception
   • All stakeholders present
   • Come together on: goals, risks, users, stories/features
   • Estimate work for each story
   • Prioritize stories
2. Iteration planning
   • Reevaluate priority of stories
3. Sprint (do the work)
4. Reflection

As a (role) I want (something) so that (benefit).

• As a visitor I want to view my shopping cart so that I can review what items are in my shopping cart.

I took a lot of notes. I'm too lazy to integrate them with what's here. If someone else would do that, that would be great. I figure it's better to have this dump of info at the bottom of the page than a dearth of info. If a lot of people feel otherwise, you can delete my stuff.

agile development with pivotal labs

prioritized backlog - client writes user-oriented story of what web app will do - client prioritizes these stories/features - client understands that lower priorities will come like 2 months later - pivotal gives time estimates for different priority levels - features are always end-to-end involving back end and user - all programmers share this priority list. when one finishes a task, h/she grabs the next one on the list. - identify a “product owner” role. this person manages the priorities. ex for consulting the client, for Microsoft the PM. then others execute the priorities.

release planning - inception: all stakeholders (devs, designers, UI, everyone) discuss users and needs and how users will accomplish their needs. this creates prioritized backlog. plan about 2-3 months in advance; any more and things will have changed. set expectations with client of what can be accomplished in this time period.

iteration planning - break 2-3 months down into 1-week “sprints” aka “iterations” - each week discuss specs (“acceptance criteria”) for the story you're working on. have discussion for each week at beginning of week, then you can work independently that whole week. defer detail planning as late as possible to avoid wasted time planning details and then having things change. - 15 minute daily stand up meeting (all standing to make things go quickly). share what you did yesterday with group, what you will do today, and any roadblocks you need cleared from devs or others. - works best on ⇐ 10 people teams. amazon coined “2 pizza” team size rule. 4 devs, a PM, a visual designer, and UX (user experience) person.

retrospectives - every 2-3 weeks whole team (dev, designer, UI, UX, client, PM) has open meeting to talk about what's working and what's not - don't introduce hierarchy in this, everyone has equal voice

www.pivotaltracker.com - tool for managing backlog - devs can have a hard time estimating how much time something will take. comparing it to other tasks (ex. that's twice as hard as what i did yesterday). 0,1,2,4,8 where 0 is five minutes, 1 is twice as hard as 0, 2 is twice as hard as 1, etc… estimate for everything you do, use historical averages to get estimates of how long new tasks will take. make each week about 8 worth of work. - using actual time estimates tends to make harsher deadlines (ex. exactly an hour) - groups estimate times together. if they have very different estimates, they can discuss. - transparent tracking of

1. person B requested this task
2. person A is starting this task
3. person A can finish the task, then submit it
4. person C reviews task and accepts/rejects

- story format: As a _ (user) I should (be able to) (functionality) so that _ (value)

- shorten feedback loop so you don't waste time doing something that isn't right.

- you aren't going to need it. do the simplest thing for what you want right now (the current task on backlog), don't worry about dependent tasks that are much lower priority because you might never end up doing those (might be abandoned).

pair programming - two devs at a single machine on a single problem collaboratively - continuous code review (catch typos, checking all cases) - prevents distraction (text messages, facebook for a second) - prevents boredom by switching off who types - they estimate that the pair is more productive than two people working individually - promotes communication so there's no redundant work done - switch pairs every day - collective code ownership. not “i wrote this, this part is mine, you wrote that bug” - every coder feels comfortable with every piece of code - no “oh he's on vacation need to wait till he returns to fix his bug” - prevents feeling burnt out and socially isolated - all sitting at big tables in a big open room

test driven development - red, green, refactor process. first write a test that tests what you wish your code did even though you code doesn't yet (test everything it should do in all cases). it should fail. then change/write bare minimum implementation code to get test to pass. don't introduce complexity that you aren't testing. then when test passes, refactor code to write it the way you wish you'd written it all along. - run all the tests before you check in to make sure your code never regresses.

continuous integration - always integrating code as you go - run all tests before you check in your code - switching off pairs - continuous integration servers - they have a red/green test status display on tv screens in big office room where everyone works, so when your code goes red you want to fix it as quickly as possible. - every time you have a bug, start by writing a test that confirms that that bug is there. helps understand when bug occurs (could be like 3 things coming together)

automated deployments - acceptance staging: a place you can push code to, PMs can test it - APIs that can be broken and reset - intermediate environment for deployment to make sure it works before actually deploying it - arrange for one button deployment - deploy early and often

version control - pivotal uses git - push to it early and often - integrate with each other

cucumber & test driven development - (cucumber is a test framework for ruby) - behavior driven development, not test driven development - write tests in plain English! using cucumber - write the test of the whole user story - red, green, refactor. - test after every line. respond to each new error

robolectric - test framework for android

inception planning meeting - goals (launch site, business thingies, everyone on team should know) - risks, constraints that could prevent meeting goals - roles (ex. visitor to site, member of site, admin of site) - stories for what each role would want to do - stories should be

 Independent (stories are each independent things to do)
 Negotiable
 Valuable
 Estimatable (how long will it take to implement)
 Small (concise, takes no longer than a week to do, break into smaller piece)
 Testable

- prioritize stories

- after inception, can add a story at any time - also prioritize bugs. each bug is 0 points' worth of work (0,1,2,4,8) - changing SQL to other database structure is also 0 points' worth of work b/c doesn't add value to user

then also the weekly meetings - compare to inception planning - reorder priorities, discard or add

Prioritized Backlog

1. not a waterfall model, agile development
2. gives you a view of entire progress
3. weekly basis: spend 30 minutes walkthrough with designers, discuss what everything means (rich text field? what is a blog article? requirements or “acceptance criteria”)
4. opportunity to dive into details for individual stories
   1. Ordered List Item- best at beginning of sprint
   2. defer specifics as late as possible to give time to change directions
5. this project gives you idea that big picture meetings are big picture meetings and individual stuff is individual
6. daily stand up, 15 minutes, come together, three main goals: what accomplished yesterday, what doing today, what roadblocks need to be overcome
   1. important for team size that you're notwasting time
   2. “two pizza rule” for team size

retrospective:

1. every two weeks or so
2. very open, transparent conversation
3. what things working ver well, what we can do as a team to keep doing or stop doing
4. don't overlook anyone's opinion
5. early olin was like this

release planning: I N C E P T I O N

1. 1-2 day workshop where all stakeholders (project owners, designers, ux people)
2. talk through project, users, features you have in mind
3. what each user neds to develop features
4. 2-3 months of work is the futhest they think ahead (things change beyond that, waste of effort)

when the backlog ran out, client didn't have any options

need a project manager to own prioritization

1. much more time consuming than holding one person responsible

PIVOTAL TRACKER website

1. each is a user story, format: “As a … I should… So that …”
2. engineers can't put time on things; relative effort to other tasks is easier
   1. don't think too deeply
   2. > 8pt, break it down
3. ensure point system is useful: rock-paper-points, then discuss differences
4. order is important, codebase changes may

Defer things to a later date:

1. codebase may change before you get to it/render it useless

Pair programming

1. 2 working together better than 2 individuals
2. no writing same code twice, also at least two people know what code is
3. team owns all code, both good/bad
4. interaction is very social, helps fix individual problems

Test-driven development: red-green refactor

1. write a test that first tests what you wish your code did (should fail)
2. do the minimal amount of work to make test turn green (don't introduce complexity you don't test!)
3. do it ugly and quick first, then refactor
4. “make it work, then make it fast, then make it elegant.”

Continuous integration

1. run entire suite of tests with every checkin
2. codebase size does make large projects fickle
3. but small projects, it gives you confidence to move fast

rails environments: development, test, and production

1. deploying early/often is a good thing
2. write automation scripts to easily upload/restart/maintain code, deploy easily
3. remove human element of forgetting steps

version control:

1. they use git

yellow/green cards: mark chang?

cucumber: runs test suite for html testing robolectric: test android code

TEST I N C E P T I O N: goals, risk constraints roles: visitor, member, action, chef

1. as a visitor, i wanna
   1. view recipies
   2. search incredients
   3. view by chef
2. as a member, i wanna
   1. login
   2. create recipe

acronym: INVEST Independent [user goals] Negotiable [what can we simplify] Valuable [show that user needs are important] Estimatable [break them down so you can have a sense of when they will get done] Small Testable

create stickies on whiteboar,d prioeritize with index cards requirements may be remembered at any time, throw items into icebox

Intro to Agile Development -Pivotal Labs Overview Prioritized Backlog -Put all the work you do in a queue so that the top thing is the most important thing and the bottom thing is the least. -Pivotal Tracker is how they manage the prioritized backlog -Clients make the tradeoff of what they want prioritized and finished now vs. what will be finished in two months from now. -Staff works on things at the top of the list. When they finish something, they grab the next thing that needs to be finished. -Allows product owners to own the product and engineers to own the engineering. Release Planning

1. (missed this part)

Daily Standup

1. Works best for teams under 10 people.

Retrospectives

1. Don’t introduce a lot of hierarchy. Everyone’s opinions need to be valued and listened to.

Pivotal Tracker Demo Pair Programming

1. Makes it easier to stay focused and not get distracted.

Test Driven Development

1. Red Green Refactor.
2. Can get a few cycles of improving code before committing.

Continuous Integration -Constantly run tests on everything that gets added to the project to ensure that a new feature doesn’t mess up everything made earlier. Automated Deployments

1. Write automation scripts to upload new code to servers constantly.

Version Control

1. (missed this part)

Android: Pivotal.github.com/robolectric