Making the Transition to Agile: what we did, what worked, and what we learned
-
Upload
ari-davidow -
Category
Software
-
view
234 -
download
1
description
Transcript of Making the Transition to Agile: what we did, what worked, and what we learned
Making the Transition to Agile: What we did and how we built on it
Ari Davidow, PMPfor the MetroWest Roundtable
• Disclaimer: This isn’t a talk about Agile methodology, per se. It’s a talk about how one organization began using Agile methodologies and what was learned.
10 years+ of audio and video oral histories
6TB Data
New Web Development FY 09
• Fedora
– Tool for managing digital assets
– Foundation for future
So, we knew what we wanted.
It would only cost $250,000.
We wrote a grant proposal.
Back to the drawing board
What if we didn’t build a whole repository?
What if we only built the pieces we really need?
What would that look like?
What would that cost?
What is Agile Development?• A set of software development processes that focus on
putting usable code in people’s hands as soon as possible• A vision of software development as an ongoing process,
rather than as a one time project
Manifesto for Agile Software Development
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
• Individuals and interactions over processes and tools• Working software over comprehensive documentation• Customer collaboration over contract negotiation• Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
It was early. We didn’t know from Scrum, etc.
Agile Development
• Put usable tools in people’s hands quickly
Agile Development
• Use cards/whiteboard to note requests
Start with User Stories
• We spent a week describing what features we couldn’t live without
A user story is a brief description of functionality as viewed by a user or customer of the system (Mike Cohn)
As a <type of user>,
I want <capability>So that <business value>
As an archivist
I want a pulldown menu with my metadata terms
So that we can keep terms consistent
Our list of User Stories was minimal
• Archivist can delete files in an existing Oral History• Archivist can replace files in an existing Oral History• Archivist can add files to an existing Oral History• Archivist uses Fedora's Basic search to see what objects have been
ingested• Users can access datastreams from objects• Users can view ingest status• Users should be able to drill down into collections• Users should be able to log out• Archivist can delete whole objects• …User stories make it easy to focus on functionality, rather than getting lost too early in implementation specifics
Agile Development
• Short, iterative programming cycles (usually, 2-6 weeks)
Agile Development
• When you have grouped an acceptable set of cards into the time represented by a “sprint” (2-6 weeks), you have your next sprint planned.
Agile Development
• The rest of the cards go in the “backlog” to be refined further as you prepare for the next+1 sprint—what you’ll be doing next.
So, we prioritized the User Stories and arranged them into sprints:
• We estimated how much time each feature would take.
• We divided sprints so that functionality was delivered every two-three weeks.
• We arranged the stories so that the Archivist could begin working ASAP and provide feedback on what to prioritize next.
And we achieved….
The first JWA repository: Bella*
The least functionality that let us move the digital contents from old cassettes
and minidisks into active curatorial management.
*If we say that the software we used is called “Fedora,” is further explanation of how a Jewish Women’s Archive arrived at “Bella” as the appropriate name, necessary?
It worked
• Bella was built.
• JWA had a digital archive
• The team that built Bella open-sourced the project, now called “Hydra” and it continues to be a popular, successful, low-cost interface to Fedora
Lessons Learned
• Agile methodologies work!
Lessons Learned 2
Agile methodologies work sometimes …
… but Agile ideas can be useful even in waterfall situations
Delivering the right product
• Agile is especially good when you need to deliver a usable product—software, business process re-engineering—anything that can benefit from iterative development.
Kanban and other goodies
• Kanban provides methods for improving quality and speed by improving transparency, limiting workflow, and paying attention to the fact that a team may often work on several different types of jobs at once, often with very different priorities.
Note the “ready” columns, and the red numbers. In Kanban, you limit the “Work in Progress” (WIP) to facilitate better quality and speed.
Final lessons learned
• To be Agile, really does mean that it is important to keep learning and trying new things.
• It is important for the entire organization to become “Agile”
• There are a lot of great gameto help a team, or an organization think “Agile.”
Some Resources
• AgileBoston—http://newtechusa.net/user-groups/ma/ —especially imaginative speakers and camraderie. Each free monthly meeting is preceded by a half-hour class related to Scrum, or Agile development.
• Agile New England–http://www.agilenewengland.org–monthly meetings, likewise preceded by practice sessions, classes in Scrum and Kanban. Speakers tend to be more establishmentarian, likelier to be pushing recent books. Attendees seem to average a bit older
• PMI has an Agile SIG, and a new-ish certification focused on Agile methodologies: ACP