Agile project management for non-profits: Are you crazy?

AGILE from QUILTED

Agile: a way of managing projects

• Three components:
  • Your project is broken up into bounded periods of time called sprints
  • Agile puts your value in the project; user stories are used, the most important part is the value they provide
  • Allows for a process of prioritization of the different user stories or value statements
• Methodologies that Quilted has been playing with, trying out, refining

and improving

GO AROUND

• What works well as a developer: getting something launched at the end

of every week; what's difficult: communicating with clients about what they're going to get at the end. Always a struggle, a lot of talking.

• Informal Agile practices work well; love tight feedback cycles, feel

safter as a dev not spending a lot of time building something that the client doesn't like or use. Question: what was meant by launching something every week? A concern: working in a project management role for a long-term client that's working with another shop that uses a very formal SCRUM methodology; seems too set in stone to be Agile, which seems to mean you can make decisions in the moment. Amount of project management time involved in daily burndown charts seems worrisome; acting as the rep of the client brings up those concerns.

• Had a lot of experience hiring devs for small projects and not being

able to convince other stakeholders on client end that anything but a formal RFP and set of deliverables systems works. Figuring out how to manage the process well internally in order to roll out things faster.

• Use a formal Agile process at work, well implemented. But there's bad

project direction, lack of real investment among potential users. Looking forward to moving to a different job managing developers; thinking about how to implement Agile in a more healthy setting.

• Project managament NOT of software dev, some tech some not; some

projects are stalled, want to learn about different methods.

• Incorporate a lot of project management elements of Agile, but can't

convince people to go ahead without some feature set the client feels comfortable about.

• Using "half-assed Agile" methodology; cherry-picking things that make

sense, but knee-jerk reaction to jargon and dogma and difficult to implement some components with clients

• Some parts of Agile that work really well: regular reflection in terms

of continually improving the process; direct involvement of the customer in decision-making, including being colocated with them, which is a more formal Agile/SCRUM thing.

• Last year's Agile session, came out totally convinced Agile wouldn't

work for nonprofits with small budget projects; still grappling with that question. Something that worked well: incorporate clients as part of a client team, especially in daily check-in meetings, have client report on what they've done since last time. Makes process really collaborative, all on the same team. Want to learn more about how to run design and development in parallel; want to hear more about that; do some folks use Agile for design?

• There are very strict interpretations of some of these methodologies,

but there are also interpretations.

• Quilted does not use a hyper-strict defined version.
• In Quilted lingo, SCRUM = daily check-in meetings with entire team

(including client) reporting on what they did the day before, what they plan today, any blocks.

• Sprints = amount of time you work before you check in again. Sprint

planning meeting at beginning of sprint where you do prioritization and retrospective on how previous sprint went. Hour for planning, hour for retrospective.

• Not doing retrospectives harms process; gives you chance to change and

improve process.

• Question: is there a lot of project management overhead? Does it lead

to more productivity?

• Different project managers work differently.
• Project management time has been reduced by SCRUM; team takes more

responsibility for what's going on and you're in communication with client about that. When doing daily burndowns in a more formal SCRUM way (spreadsheet not pivotal tracker) it didn't take that long -- maybe 5 minutes. Biggest part was developers re-estimating tasks for the week. That was a little intense but really clarified what to say to the client, what could get done by milestones and what couldn't, how to plan for what couldn't get done.

• Pivotal tracker: a web-based, proprietary project management hosted

service tool (also nonprofit free accounts) that can be used for a number of threads of Agile processes; the main unit is a user story, you can upload files and comments.

• A burndown: you have remaining points in the backlog (full list of

user stories you want to get done in the project, the outstanding tasks that have been agreed upon) along the vertical axis, time along the horizontal access. Have a line that shows straight path from tasks to launch, but you have many points plotted along the timeline of the project; you draw an average of the scatter and have your actual burndown based on how things are trending to re-estimate the timeline IF you're going to do all of the work in the backlog. Features can be taken out of the backlog if you see you're totally fucked.

• Wrestle with this a lot; what happens is that a firm set of features

are set for a certain cost and it's all on the developer to keep track. Wind up with fights, blame being thrown around, but also understand that as an organization it's hard not to be beholden to that sort of mythical process whereby someone tells you what they're going to do and how much it's going to cost to let you compare proposals.

• Compromise: during depth of the economy, people couldn't commit

without a solid budget. Came up with expectation management - don't provide a fixed bid, provide a range, make sure client understands that how long it takes depends on decisions made along the way. RFPs are pretty much stock with necessary addition; describe discovery process, an initial planning process after which the estimate is re-evaluated. The first estimate is a draft; gives people an understanding of cost but remind client that folks are paid hourly, that if you take out features you can reduce cost.

• Card stack: make client write out all the feature, rank them, you tell

them how hard everything is, they can resort.

• Discovery process is paid, but client gets a deliverable (more

detailed estimates, document to take away); they can cancel the project at that point -- either the client or the shop.

• We use a spreadsheet that's quite similar to the card stack.
• Whole process of prioritizing features/user stories is built into

Pivotal Tracker; it only lets the client put a certain number of points (i.e. a certain amount of work) into what you're working on this week. The act of the software indicating to clients the tradeoff when prioritizing tasks (adding tasks on drops others off) makes a big difference for clients.

• Important to communicate risk to clients at different points of the

project; the amount of risk changes throughout the project.

• Discovery process has been very helpful; always have it as a separate

contract beyond the main contract. See what it's like to work with the client; get a sense of whether the client can actually hold up their side of things. Lots of times have to argue with the client to do the discovery process; if the client can't accept that process they might not work with them. Much stronger position at end of discovery to understand how it's going to be to work with someone. Sometimes when you tell the client they should hire someone else to avoid the process they realize why it might be important.

• Makes dev feel safer: less worry about time, stress, bills the client

doesn't want to pay.

• Best project ever: a couple of weeks of discovery, then the client

agreed to spend the next couple of months talking every week and just planning. Development period was quite short but it all worked out.

• Card stacking: with tools like Pivotal Tracker, some clients don't

want to use another tool; something that's more physical and visceral can be really helpful.

• In communicating risk, you have to build up a level of trust that when

you say something is hard, the client can trust that. A lot of these processes is meant to build trust, but they can also devolve into blame games. When you figure out how to build up that trust it helps.

• A lot of Agile methods they stopped doing with small organizations

where there's no dedicated staff, can't meet frequently about things they feel like they're paying YOU to do. Pick and choose what they use and what they don't. Stopped doing completely separate contracts for discovery and development; it's all in the original contract, it's in the estimate, but the contract can be cancelled at any time after discovery is complete.

• Three different parts of project management: budget, time, and scope.

The reason why the process resonates is because the scope is not fixed. You can fix one or two project management components, but not all three. There's a cost, scope, and time triangle; you can have one or two, but you can't have them all.

• Has a lot to do with trust and communication; this is how to seel this

to clients. Need to develop the communication methods and trust to get that across, avoid disappointment and anger between shop and clients.

• Quilted: clients pay per sprint; you pay per week of the project. Have

moved away from billable hours and rates; you just work full time for the whole week, no specific amount of time, just full-time work. Cost calculated based on number of people working on it and the size of the project.

• How do folks structure billing and deliverables?
• Quilted: bills clients at the end of every week, bill by the week.
• Radical Designs: hourly contracts, paying per hour, but no specifics

about use of time unless they're requested. Client can see time per feature relative to initial estimates. Take a 30% deposit on the high rough estimate; reserve the right to bill monthly, but usually bill more like quarterly. Client is paying on time, not on a deliverable project since often you wind up waiting on something from the client.

• Design Action: Sometimes map out the deliverable from the designer,

the developer, and the client with specific dates; if the client doesn't get their deliverables in the timeline changes.

• There's a reassurance that the client is going to get *something* --

that might sound like a low bar but sometimes people wind up with projects where they don't get anything at the end but still blow through a budget. That's the biggest sell.

• User stories: written specifically without technical details;

describes what the client wants. As the sprint is going on, you can describe less complicated or more complicated solutions to user stories depending on where the whole project is at. With constant talking and high level of trust, you have that freedom.

• Benefit of daily communication and weekly check-ins is that it's

easier to not sweat the trade-offs when clients don't get things done; all of those adjustments are project management time. The daily meetings take time, but the complexity of managing an inflexible timeline system also takes a lot of time. A lot more fluid, a lot less scary.

• We charge for project management time. We know they're going to want

to talk, change things; there's no money loss.

• Sometimes clients don't keep track of where they are in their budget;

whose responsibility is it? Hard to find the time and tools.

• Chili Project: new fork of Redmine
• User stories are wack despite otherwise good Agile methodology. How do

you excavate good user stories from clients?

• The way we write user stories is the way to prioritize value over

features; the discovery process is designed to get user stories. You can use Agile as a todo manager, but that doesn't resonate as the best way to use Agile -- doesn't get to the heart of the matter which is making sure the project has value.

• Maplight: example project that has 18 different mockups with no

product yet. The value of the whole website is a way to get reporters to write about the organization; the whole mission of the website is JUST that, so lots of typical things (About page, donate button, etc). The user story (get reporters to write news about us) was where the value was, so things that weren't central to that were reprioritized. Finally came out with mockups that were super-strategic; every piece of the mockup is completely designed to getting reporters to write about them. Tested on reporters! Downside: took 10 months, might have taken far less time.

• PowerBase implementation: experience of internal excavation of user

stories from the organization; Progressive Technology Project handheld org through mapping workflow processes of the entire organization. Obviously has incredible value for figuring out the database and how the documentation will be written, but also gave the whole staff of the organization a sense of how the whole organization works. That's a much heavier process than most software development processes are going to need, but mapping the workflow is a great tool for excavating that. Guiding questions that are super simple gives you a picture of what needs to happen.

• People often want to talk about features, not what they want to

happen; getting people to say the outcome they want is a huge challenge. What do you want the user experience to be? That's what user stories are.

• Any client who doesn't have that you can only have two of cost, scope

or time really doesn't get it; it happens in their work, too!

• Adding value during the discovery process is one of the greatest

gifts; lots of times people don't know what their org is doing, what they want to do. The work often helps define the mission statement and what the work is. As devs we're used to thinking about corner cases, entire workflow; lots of times folks aren't use to thinking about all of the possibilities.

• How do you contend with different definitions of what the work is or

what's needed? (Answer: talk them through it)

• How do you avoid dealing with RFPs? How do you talk clients out of

RFPs they're really committed to?

• Quilted: we're really networked and connected to clients who trust.
• Quilted: we don't respond to RFPs in the way clients are asking them

to respond; respond saying they can't give an estimate based on the RFP, give them examples of how it's worked, give the pitch of the big success points. If it doesn't work for them, they shouldn't work with them.

• RD: Started using Agile in a situation where they COULD pick and

choose, but then got into a situation where they couldn't because they needed the work; had to walk away from the situation of being able to reject.

• Felt the money crunch too and has taken jobs they shouldn't have. Cost

more money than it would have to just turn them down.

• Radical Designs: There's feast or famine; started doing a monthly

quota for new business, when you're in danger of not meeting the quota might cut deals, but allows you to prioritize good clients. Monthly basis rather than crunch time.

• If the client has conflicting requests, you have to point out how

developing for both sides of the conflict will cost time and money.

• Project manager's job is NOT to keep the client happy; it's to get the

project built that's good for the client, meets their needs, within their budget. If you tell the client what they think they want to hear even if it won't work you're fucking yourself. Expectation management!

• Have written a good RFP and gotten a good bid with a big range

($20K-$60K) but that felt reasonable given the RFP.

• Palante: we've found it easy to get clients to agree to iterative

processes; we'll start with the most important features, maintain the relationship, and add more down the road when the budget can accommodate it; it's often even better for clients to work with the initial site build first and discover what they like, what they don't, what they might not even need before building more.

• Iterative is awesome if as the client you understand that from the

beginning.

• Quilted: stopped doing separate discovery contract because at the end

there was more pressure to define what the entire project is going to be; still the same problems at the end of the second phase when they didn't get the exact cost, scope, and time that was then defined.