Agile practices in nonprofit contexts

From DevSummit
Jump to: navigation, search
  * No one way to define agile
     * Minimizing documentation
     * Minimizing overhead
     * Trusting people over process
     * Scrum
        * Defacto standard for Agile in the corporate world
        * Comes from Rugby!
        * How are Scrum and Agile different?
           * Scrum defines a few things you have to have in an iteration
              * Two weeks to a month
              * User stories in a backlog
              * Defined roles
                 * Bus. owner
                 * Scrum master
                 * Team
              * Bus. owner defines priorities
              * Team decides on what they can do in a sprint
              * Daily standup
                 * What am I working on today?
                 * What did I do yesterday?
                 * What is blocking my progress?
              * Post-sprint meeting (process meeting)
                 * What worked, what didn't?
     * Extreme Programming
        * Very much about what developers did
           * Pair programming
              * Not as common anymore because nobody wants to pay 2 devs for one person's work
     * Kanban
        * Kanban removes iterations completely
        * Pull jobs from a board and ship
        * "Flow" instead of iterations
        * Sets limits on:
           * Items in progress
           * Items in backlog
           * Items done but not shipped
  * Existing nonprofit processes:
     * Midwest Academy Model
        * Charts
           * Allies
           * Adversaries
           * Constituents
           * Tactics
           * Resources
        * Criticism
           * Doesn't move the project forward
           * Good at planning, bad at execution
           * Not good at chunking plan into action items
  * User stories for nonprofits:
     * Used in software: X user can do y action for z business need
     * In nonprofits: X type of constituent can do y action for z social benefit
  * Case studies about Agile in nonprofits:
     * Assigning value outside of difficulty is useful
     * Make ranking of priorities visible
     * There's usually some kind of visualization (board, spreadsheet, whatever) to prioritize user stories
     * Most useful when you're building something, esp. if you're foundation-funded because it's similar to getting investment capital
     * But Agile doesn't work when something breaks
  * Case study: Building software to help refugee orgs in Africa
     * Tried to do user stories, but emergencies come up to disrupt them
     * "We need to get to where this group of constituents understand online anonymity enough to safely use a tool."
     * "We need to get to where this SMS based tool is stable enough that our operator partners will implement it."
     * You have a pool of resources and assign order of importance
        * "The order of importance is mightier than the makeup of your team"
        * People do whatever needs to be done most rather than exactly what they're best at
        * "Not my job" thinking reduced
  * Case study: using Scrum for public access TV station
     * Project is so huge theres 150 user stories
        * All interact with each other, hard to separate
        * Really focused on individual testing
        * Not doing good regression/"big picture" testing
        * Prioritization doesn't work as well at scale, possibly?
        * Hard to see things "holistically" using Agile
     * Response: need to learn to write better user stories to avoid this!
  * Case study: Corporate-world scrum
     * "Epics", stories, and technical tests
     * Also "themes" for big picture thinking
  * "Nonprofit strategic planning is totally waterfall"
  * 
     * Agile methodology lets us check in occasionally instead of maybe once a year
     * "Incredibly frustrating to have the basic toolkit be 'what are we going to do for three years?'"
     * Process facilitated by funders
     * How can we structure grants so funders are more like clients?
  * Scrum defines what happens when you break the process
     * Built to handle interruptions
     * You visualize that the cost is high
     * There is a very real cost of immediate changes, communicating that is important
  * Rigidity of foundations is causing nonprofit stagnation, how do we fix it?


     * Software development methodologies move fast, foundations move really slow
     * How do we build bridges to foundations to get them to use more efficient methods?
        * Using a "name brand" methodology can get you buy-in
        * Agile is really good about short-term reporting
        * We can tell you a month into the project what can get done in six months:
           * The other side is estimation of tasks
           * You never estimate in hours or days, instead you give story points
           * Define difficulty and time required relative to other things only
           * Then measure velocity (number of story points in an iteration)
           * Very big tasks are less accurately estimated
           * Velocity takes into account that estimation is hard
        * Software projects within nonprofits are a good opportunity to drive adoption of agile practices in other projects within nonprofits (like fundraising and grant writing)
  * Who's a good funder (short cycles, support agile methods)?


     * Post dot-com boom foundations
        * Hewlitt Foundation
           * Only institutions
           * Only general support
           * Only three-year money
        * Omidyar network
           * Define a solution, fund organizations regardless of tax status
     * Knight Foundation
        * Shorter grant cycle
        * Their interest in tech projects and their funding makes them see that agile practices are valuable
     * Awesome Foundation
     * Global Integrity Innovation Fund
        * Working prototypes of gov transparency tools
        * Up to 10k
  * RFP culture reproduces itself!
     * How can the "dam break"?
  * New session proposal: Create non-profit user stories!