Is agile working still relevant for library and information professionals? In my opinion, "agile working" has simply become "working" but you need to look at the possibilities. As the needs of users change, and as technology evolves, information services must adapt in order to continue to serve their users and organisations well. If we want to inform organisational strategy, prove our value and make a difference, we need a clear plan of action!
Software developers are perhaps best known for agile working. Generally, agile projects are defined by short bursts of work that are intended to produce a deliverable result - within 1-4 weeks. These bursts of work are usually called sprints.
"In software engineering, the agile methodology allows you to continuously deliver business value, immediately get feedback and adjust further steps accordingly. But agile practices and tools can easily be extrapolated to almost any non-tech project. Agile Manifesto states some great principles of empowering people and the new-age approach to management. Mature frameworks like Scrum provide great tools and techniques for every project where progress tracking, team collaboration, and transparency of processes are important." - Software Team Lead at Vable
Agile methodologies are defined processes that incorporate methods of defining and assigning work, as well as structured meetings. They include frequent iterative processes, clarifying the requirements of the project as it progresses - rather than attempting to establish the requirements in detail before the plan is initiated, as in traditional project management (also called “waterfall” methodology).
Agile methodology is a good option for any business environment that changes rapidly, but is also useful in environments where it is hard to nail down precise requirements without having something tangible in place. Agile methodology is also very user-focused - stories are written in terms of the user’s needs, and how the user behaves.
We have gone beyond clunky collaboration using Word or Google Docs. It is now the norm to use a solution to ensure that everyone is connected, included and aware of what the team is working on. Without this visibility, team members are working in isolation. Not good. A number of tools exist to manage ongoing projects and initiatives, whilst ensuring the end result is kept in mind.
Agile tools (and artefacts) such as Kanban boards, and product and sprint backlogs are key to the team being able to progress forward. The Kanban board is there to provide a transparent view of the work in progress, and what is planned for the sprint. Platform software such as Jira, Monday, Pivotaltracker, Trello and Salesforce-Agile Accerator can support communication and transparency to give a live view to the whole organisation on the progress being made and issues faced.
There are various methodologies, but one of the best-known agile project management frameworks is Scrum, which is relatively rigid compared to other frameworks. Scrum is a term that came from rugby - it refers to when the players huddle together. The three roles in Scrum are the ScrumMaster, the Product Owner, and the Team. The ScrumMaster is there to facilitate the process and help the team function by removing any obstacles, while the Product Owner has the final say about the product, and makes sure the team understands the vision. The Team is self-organising, and determines how to execute the vision the Product Owner communicates to them.
So what of the current manager? Agile teams work as a collective, without a traditional project leader - your manager’s duties would instead be spread out across the roles of Product Owner, ScrumMaster, and Team. Instead of acting as a traditional manager, the ScrumMaster would be there to help the team by removing obstacles in the way of the team’s tasks, and help prioritise the backlog.
Managers would need to learn to trust the agile team as a whole in order for agile methodology to work for the business - that means the manager must recognise that it is now the team’s responsibility to solve problems, not the manager’s.
All organisations have to remain agile, including libraries. Librarians need to ensure that the structure they work within doesn’t hold them back - that might mean redefining that structure. The Library at Chalmers University of Technology in Sweden recognised that libraries are undergoing a great deal of changes - including new technologies and different user demands - and this makes them good candidates for developing agile processes. They adopted the principles of Scrum throughout the library after introducing Scrum to cross-disciplinary teams involving librarians and developers, working on projects like developing a new website.
The library staff at Chalmers felt that the greatest risk of implementing Scrum was that “we will continue to work as previously, that the change means no change in our operations and that the change won’t matter”. Libraries often experience “death by committee”, where the process of change is too slow because there is too much discussion and speculation - this overlaps with the waterfall development process. Agile processes are a reaction to the slowness of the old method.
Chalmers Library’s software development team included librarians in their projects so both developers and librarians could share knowledge and develop mutual understanding. Using cross-functional teams of librarians and developers led library senior management to discuss how to implement agile principles in the whole organisation.
We at Vable use agile methodology - both in the product team and the marketing, customer success and content teams. The process is slightly different due to the nature of each team’s work. We are constantly going through an iterative process of seeing what frameworks will work best for us. We constantly ask "is this working and how can we improve it".
For instance, do we need weekly team meetings, or can we have them fortnightly? How can we get the most value out of our initiatives? How can we improve how we support our clients? All these questions ultimately revolve around the client experience. And that is why we must maintain our agility, even if we don't want to call it working agile!