36
Making the Transition to Agile: What we did and how we built on it Ari Davidow, PMP for the MetroWest Roundtable 24-October-2014 [email protected]

Making the Transition to Agile: what we did, what worked, and what we learned

Embed Size (px)

DESCRIPTION

In 2008 the Jewish Women's Archive (JWA) tried Agile Software development as a tool to select the necessary User Stories and develop a working, lightweight interface to the Fedora Commons digital archive. The project succeeded. That software was later taken by the developer and open sourced as the "hydra" project.

Citation preview

Page 1: 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

[email protected]

Page 2: Making the Transition to Agile: what we did, what worked, and what we learned

• 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.

Page 3: Making the Transition to Agile: what we did, what worked, and what we learned
Page 4: Making the Transition to Agile: what we did, what worked, and what we learned
Page 5: Making the Transition to Agile: what we did, what worked, and what we learned
Page 6: Making the Transition to Agile: what we did, what worked, and what we learned
Page 7: Making the Transition to Agile: what we did, what worked, and what we learned
Page 8: Making the Transition to Agile: what we did, what worked, and what we learned

10 years+ of audio and video oral histories

6TB Data

Page 9: Making the Transition to Agile: what we did, what worked, and what we learned

New Web Development FY 09

• Fedora

– Tool for managing digital assets

– Foundation for future

Page 10: Making the Transition to Agile: what we did, what worked, and what we learned

So, we knew what we wanted.

It would only cost $250,000.

We wrote a grant proposal.

Page 11: Making the Transition to Agile: what we did, what worked, and what we learned
Page 12: Making the Transition to Agile: what we did, what worked, and what we learned

Back to the drawing board

Page 13: Making the Transition to Agile: what we did, what worked, and what we learned

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?

Page 14: Making the Transition to Agile: what we did, what worked, and what we learned
Page 15: Making the Transition to Agile: what we did, what worked, and what we learned

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

Page 16: Making the Transition to Agile: what we did, what worked, and what we learned

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.

Page 17: Making the Transition to Agile: what we did, what worked, and what we learned

It was early. We didn’t know from Scrum, etc.

Page 18: Making the Transition to Agile: what we did, what worked, and what we learned

Agile Development

• Put usable tools in people’s hands quickly

Page 19: Making the Transition to Agile: what we did, what worked, and what we learned

Agile Development

• Use cards/whiteboard to note requests

Page 20: Making the Transition to Agile: what we did, what worked, and what we learned

Start with User Stories

• We spent a week describing what features we couldn’t live without

Page 21: Making the Transition to Agile: what we did, what worked, and what we learned

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

Page 22: Making the Transition to Agile: what we did, what worked, and what we learned

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

Page 23: Making the Transition to Agile: what we did, what worked, and what we learned

Agile Development

• Short, iterative programming cycles (usually, 2-6 weeks)

Page 24: Making the Transition to Agile: what we did, what worked, and what we learned

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.

Page 25: Making the Transition to Agile: what we did, what worked, and what we learned

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.

Page 26: Making the Transition to Agile: what we did, what worked, and what we learned

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.

Page 27: Making the Transition to Agile: what we did, what worked, and what we learned

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?

Page 28: Making the Transition to Agile: what we did, what worked, and what we learned

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

Page 29: Making the Transition to Agile: what we did, what worked, and what we learned

Lessons Learned

• Agile methodologies work!

Page 30: Making the Transition to Agile: what we did, what worked, and what we learned

Lessons Learned 2

Agile methodologies work sometimes …

… but Agile ideas can be useful even in waterfall situations

Page 31: Making the Transition to Agile: what we did, what worked, and what we learned

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.

Page 32: Making the Transition to Agile: what we did, what worked, and what we learned

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.

Page 33: Making the Transition to Agile: what we did, what worked, and what we learned

Note the “ready” columns, and the red numbers. In Kanban, you limit the “Work in Progress” (WIP) to facilitate better quality and speed.

Page 34: Making the Transition to Agile: what we did, what worked, and what we learned
Page 35: Making the Transition to Agile: what we did, what worked, and what we learned

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.”

Page 36: Making the Transition to Agile: what we did, what worked, and what we learned

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