Agile Project Management (Agile) seeks to answer the most common complaint about traditional project management: how can you plan a project and also be responsive to change. Traditional project management lays out a clear plan from start to finish. In typical software development projects, you’ll see waterfall design which will have stages like: requirements, design, implementation, verification, and maintenance that flow from one to the next. While this approach looks great on charts and graphics, it can be very labor intensive to make changes to a project that is being managed with this method. This can lead to a delays, lengthy change processes, and cost overruns. Agile seeks to counter this by instead focusing on smaller, regularly delivered chunks of work. Agile anticipates change and turns it into a feature and not a bug.
Agile began trying to answer why large IT projects were failing at a higher than expected rate. It became clear that the waterfall approach had a great deal to do with it. Outlining the requirements for large scale projects often ends up with missing details or with multiple teams working on individual aspects and botching the handoff. Because all the details were outlined in the start of the project, if anything needed to change the process had to be started all over again.
The Agile community developed several fixes to these problems. These can be seen in Scrum, the most popular version of Agile. Scrum seeks to deliver constant value by using an iterative process to continuously deliver results all the while being responsive to changes.
Scrum clearly defines the formation of the team. There are two clear roles in a Scrum team: the Scrum master and the product owner. The Scrum master is the facilitator for the team. This person coordinates meetings and handles any obstructions the team might encounter. The product owner is like the stakeholder representative. They have the vision of the end goal and prioritize work according to that vision. The remaining roles are all as members of the Scrum team.
The Scrum team has representatives with all of the skills and expertise it needs to complete the project. While it is possible to bring in subject matters experts (SME) this should be the exception and not the rule. It is also normal for each member to be assigned full-time to a team so that their focus is not divided. I’ve found this to be one of the biggest hurdles in library use of Scrum as it is difficult to assign someone to work on just one project. While you can split people up among several teams, it will impact some of the benefits of Scrum.
While the team structure of Scrum is simple, it’s iterative process and how it organizes of meetings is effective in a number of situations, including committees or task forces. Scrum uses strict timeboxes called sprints to complete work. Each sprint is normally two weeks long although this can be changed so long as it is consistent. At the start of each sprint a sprint planning session takes place. Here the team and product owner come together to review and prioritize tasks. Once the work for the next sprint has been decided it is up to the team to deliver on these items by the end of the sprint. To do so, the team has daily standup meetings. These meetings should never be more than 15 minutes long and should focus just on what has been accomplished and any impediments that team member have encountered. This constant communication is a key element of Scrum. At the end of the sprint, a sprint review is held where the team will show off completed work to the product owner and other stakeholders to get feedback. Then a sprint retrospective takes place where the team is able to discuss how the work went and any issues or problems they had prior to beginning the next sprint. Once that is done the process repeats itself. This should manifest in a system where the product owner is prioritizing work and the team is delivering on it in a timely fashion. This cuts down on wasted work and makes the team much more responsive to the organization.
This was a very brief introduction to Agile and Scrum and I have barely touched the surface. There is much to discuss here and some concepts, like stories and what done means in this context, can be valuable to libraries in realms outside of projects as well. Much of my own personal life planning is built around an Agile process as well, which I’ll be talking about later. If you are looking for more information I recommend Agile Project Management by Jim Highsmith or Exploring Scrum: The Fundamentals by Dan Rawsthorne with Doug Shimp.