View source for Agile Process for Developing Web Apps and Working With Nonprofit Clients

Facilitated by the [http://www.radicaldesigns.org Radical Designs] Team

Radical Designs has settled on Agile as the most effective way to deliver web solutions to nonprofit clients. The “scrum” process allows the team and their clients to stay aligned on a daily basis. Pair programming yields higher quality code while distributing project knowledge evenly, and allows junior developers to ramp up quickly with senior developers. This session will focus on how the process yields better outcomes.


--------------------------
Facilitated by Austin from Radical Designs.

"Switched" to agile 7 months ago, but that was just tests, didn't
really start doing it (pairing, etc.) until 3 months ago.

How have people used agile in the past?

- in college, but not since

- haven't done it, maybe semi-agile, but have new managers that want
to move in that direction

- designer... interested, but not sure how to incorporate it as a designer

- want to do it, but mostly work remotely, not sure how to bridge that gap

- want to do it, but never seem to quite get there

- need "agile therapy"... worked in an environment where there were death marches and 2 hour standing meetings and called that agile

- already do agile, just not calling it that... ship every day, pair program, etc.

- have had a couple of agile project successes


Challenges of remote working came up a lot.  How does this work?  It
can be contraindicated.  Ways to make it work:

- meet face to face at the beginning of the project

- engage in the "warmest possible communication", i.e. in person > video chat > conference call > irc > email; screen sharing w/ video chat > screen sharing w/ audio or text chat

- Austin used to work from home 3 days / week, but now has to come in every day.  It's a challenge to have it work remotely.

Stories... all you need is a pen and cards.

Start w/ a daily stand-up meeting, stand-up to keep them short.
Weekly meeting where you sit, but daily is just reporting problems and
what's gonna happen today.  Around the circle answering 2 questions:
What did you do yesterday?  What are you gonna do today?

This can involve people playing different roles, someone representing
the client, etc.  You want as much client interaction as possible,
ideally every day.  RD does twice weekly phone meetings, once weekly
in person if possible.

"Scrum master" has job of finding whose stuck, make sure they get the
help they need or a different direction to not get bogged down.

"Scrum" is another name for standing meeting.

Challenges:

- people drill down too far, go on too long (scrum master should
facilitate here)

- large teams can present a challenge, really need to keep things tight

- "pigs and chickens"... lame joke, but points to the difference between "committed" and "involved".  people who are interested in the project but who aren't actually involved in performing the task at hand can listen, but shouldn't talk.


Terminology check:  XP, Scrum, Lean... specific types of agile
methodology.  "Agile" is a superset of these.

------------
Development
------------

Pair programming and test driven development is a big part of it.
Test coverage is important, especially to be able to respond to
requirements changes quickly and w/ a much better sense of security.

w/o testing you're not agile.

Pair programming can be fun, and it's key to move knowledge around.

Pair programming... two people pair programming can be a bit slower
than two people writing separately.  But you get code review while you
go, a lot of teaching in the process, much more enforced readability.
Plus folks don't get distracted as much... email, IM, IRC, etc.

Dominance problems in pair programming?  How to you work w/ that?  RD
got a chess clock, to force "driving" switch.  Enforcing that forces
the more experienced people to teach the others what they should be
doing.

"Ping Pong Pairing": one person writes a failing test, other person
has to make the test pass.  then person b writes failing test, other
person makes it pass.  back and forth... can get a state of shared
flow that can be much more fun than solo flow.

Limits on session lengths?  Haven't, but probably should.  1.5 hours
is usually a lot, but have gone as long as 4 hours.

Another pair programming challenge is different environments,
different editors, etc.  Organizationally enforced standards can help
here, but it's not always possible.

Are there pairs that just don't work?  Possibly... try as much as you
can, don't give up right away, but if someone just isn't working on a
team, if you're a big enough organization to be able move people
around, then try that.

How do you deal with being the only person on a project?

- try to start the day w/ your own scrum.. what did i do yesterday, what do i do today

- try to involve the client more

- involve other folks on the team (QA, etc)

- use short iterations

- can be tough to stay on track

- use test driven development

- use the "rubber duck"

-------------------
Project management
-------------------

Stories.  You write on a card an English (or spoken lang of choice)
language description of some action that the system needs to perform.

Talk through the stories, what are the technical challenges, to figure
out how challenging a story is.  Could formally break it into tasks
and estimate the tasks, or could be less formal and just build your
estimates from the stories after considering the difficulty.

Estimates based on the stories.  Estimating in hours is VERY hard.

- One successful way to think is fibonacci numbers.... 15 minutes, 1
hour, 2 hours, 3 hours, 5 hours, 8 hours, 13 hours, 21 hours.  If
you're gonna round up from one of these numbers, go to the next fib
number rather than just adding one or two.


- Another approach is to not use hours at all... RD has their own
"difficulty currency".

1 - very easy, you think it'll be 15 minutes to an hour

2 - couple of hours

4 - pretty hard, takes some effort, but you can see how to do it

8 - very hard, you don't even know how to do it

W/ trial and error it's come out to about 5.5 hours per point.  YMMV.


- Another approach:  "Bang" (!) for the "Buck" ($).  A task has 1-4 !s,
for how much benefit there is.  1-4 $s for how much effort.  Tasks /
stories get bang for the buck ratings, becomes clear what's not worth
the effort.


Time tracking tools are useful.

- Harvest (works with Co-op) (harvestapp.com)

- SlimTimer

- Toggle

Social timing helps people stay on task.  Even if nobody else looks at
it, it helps to stay on task.

Ship as soon as you possibly can.  If you have something you can show
the user the first day, great, even if it feels silly (e.g. user logs
in to nothing).  Get customer feedback early and often.  Lean on the
clients to do so.  Client usage is the project mgmt equivalent of the
tests in test driven development.

Iterations. Hard dates of when things are shippable by.  One week
iterations works for RD.  They can turn into a death-march... don't
let that happen.  (Ran out of time before learning more about how to
do this....)