Agile Process for Developing Web Apps and Working With Nonprofit Clients
Facilitated by the 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....)