View source for Making Agile Development Methods Work in Nonprofit Contexts

Facilitated by Michelle Murrain, OpenIssue

Michelle will discuss approaches to modifying [Agile development techniques] for nonprofit software development shops with very small teams and many projects.

== Session Notes ==

* Traditional agile is for big teams working on one project for a long time
* Still break work into two-week chunks. But it has to happen across all projects
* Individual projects don't fit nicely into two week chunks
* We can't have daily scums, but twice a week
* The general model still works in terms of iterations, "we'll show you stuff and you'll tell us what to do next"
* You can tell them what it's going to cost, but not what they're going to get
* Giving lots of reports is another option. Just keep the client in the loop as much as possible
* Periodic estimating what's remaining in the project. Burndown charts. If the work is happening daily, you need information and feedback daily
* One combo is to estimate based on milestones and waterfall estimates, but then run the project in a more agile way.
* Distinction of day-to-day vs estimating fee model
* Estimation process: User stories and estimating user stories
** Sometimes estimating user stories is risky because it can't be granular enough. Expectations are sometimes not properly communicated.
** Focus on outcome, not a deliverable
** User stories have to be accomplishable in a single iteration
* Doing a planning phase (which is paid), at the end they get a project plan / RFP that they can take to other shops if they want. After that, give them an estimate for the rest
* The reality is that we're not google, and working on small projects. The point of this session is to figure out how to do things that are flexible, client centered, and with constant review.
* At what point does a project get two small to use agile
* Just because you have a plan doesn't mean that you're not doing agile.
** I think I'm going to get to chicago by noon
** The management's job is to say: it's noon, how far are you from Chicago
* One problem with programming methodologies in general is that they work only for the organization that invented them
* Having a lot of client involvement and buy-in. 
* Estimation is inherently hard. Nothing is going to be perfect
* Scope creep is accepted. You are in total control of the scope and we're going to help steer you to be efficient
* The ultimate goal is to spot when things are starting to go off course, and do something before you start taking on water
* Challenges for working on multiple projects
** If you're trying to juggle lots of work for one client they can help decide what to prioritize, but if you're juggling multiple clients you can't ask the clients to help you prioritize
** One solution is to organize sprints anyway. It will be due in 3 weeks but we're only going to be working on it. It's an event not a milestone
** Even doing 2 or 3 day sprints are fine
* Agile is a team methodology. You need to be able to push work around the team
* Building assurances into contracts that clients are going to stick to schedules
* Emergencies are really hard for schedule
** The agile solution is that you're pairing as much as possible
** "You are on fire duty"
* Working actively with clients also facilitates knowledge transfer
* One unexpected problem is that clients just wonder off and don't engage
** Working on-site helps a lot
** Fixing bugs live is really powerful for people
** Even using go2meeting
** The more you can demystify what your job is the more clients are willing to meet you where you're at
** "The plastic alter"
* Risk management
** The problem of defining the problem is hard
* Civic actions estimation tool

Report back
* Bad news: There's no solution
* Strategies that have been useful
* Parts of agile ideas are useful at specific times
* Smaller iterations with sign-off
* Managing things as sprints / events (projects as events)
* Demystifying the process
* If clients can see changes in real time they get really excited