Agile Methodologies Help Transform a NonprofitBy Guest Author | Posted 2015-02-05 Email Print
Re-Thinking HR: What Every CIO Needs to Know About Tomorrow's Workforce
This nonprofit transformed its business practice, implemented a new case management system and adopted a new business process—all with minimal disruption.
As scrum master, I taught all team members the basics of agile, using descriptions from The Scrum Guide by scrum originators Jeff Sutherland and Ken Schwaber.
· Agile: A methodology that uses small, manageable increments of activity to develop a product.
· Scrum: A framework within which people can address complex problems, while productively and creatively delivering products of the highest possible value.
· Scrum Master: The person responsible for ensuring that scrum is understood and enacted according to scrum theory, practices and rules.
· Product Owner: The person responsible for maximizing the value of the product and the work of the development team.
· Team: The professionals who do the work of delivering a potentially reusable increment of “done” product at the end of each sprint.
· Sprint: A time-box of one month or less during which a finished, usable and potentially releasable product increment is created.
· Sprint Planning: A meeting to decide the work to be performed in the sprint.
· Backlog: An ordered list of everything that might be needed in the product.
· Stand-up/Daily Scrum: A 15-minute meeting for the team to synchronize activities, inspect work done since the last daily meeting and create a plan for the next 24 hours.
· Sprint Review: A meeting to inspect the work completed at the end of the sprint and adapt the backlog for the next sprint.
· Sprint Retrospective: An opportunity for the team to inspect itself and create a plan for improvements to be enacted in the next sprint.
Each team created and prioritized the backlog in their first sprint meeting. They did this by writing ideas down on cards, sticking the cards to the wall, and arranging and organizing them into prioritized groups of tasks. For example, the team on the practice manual project identified the creation of a table of contents as the first item in their backlog.
Once the backlog was established, we used fixed sprint lengths and followed typical agile processes, including the day 1 sprint planning, daily stand-up meetings, a one-to-two-week sprint, an end-of-sprint review and a retrospective at the end of the project.
The following factors were critical to success:
Involving Executive Leadership
One major obstruction to the success of an Agile project is lack of involvement from leadership. However, the nonprofit had strong commitment at the senior leadership level. At the beginning, I told the executive team that if this was going to work, they would need to give at least an hour of their time every two weeks to attend sprint reviews on what had been produced over the previous two weeks. They did this.
Dedicating the Right Resources
A common objection to agile is that business people can’t be spared, but in the case of the nonprofit, the right people across the organization were sanctioned for the effort and dedicated to the task. Operating managers negotiated with executives on their output targets for the coming year, reduced the workloads of people dedicated to the strategic effort, and moved resources around to backfill positions where necessary.
Creating a Project Charter for Each Team
Although Agile stresses collaboration over documentation, some documentation is necessary. One thing that kept the teams focused and organized was the creation of a brief charter for each project. In the very first sprint meeting, each team had to create a one-to-two-page document that stated the goals of the team. This charter had to be approved by stakeholders before any further activity commenced.