What is Agile anyway
It had been eight years since we had seriously built a new website. Sure we'd moved platforms and migrated the site a couple of times. Patched and hacked at our old web design to try and make it responsive and accessible but band-aids only get you so far, and in the end, we needed to pony up the cash and the expertise to pull a new one up from scratch.
Last time we’d built the website we'd used an approach known these days as Waterfall.
The Waterfall approach takes time between conception and deployment.. months.. sometimes years.
Things change fast in technology and the previous years had seen a massive shift in how software was built so we looked to learn about a development model called Agile.
Agile was born as an iterative approach to building software to deal with all the unknowns software is notorious for. Unlike waterfall-led projects, discovery, design, development and testing are continuous processes. Delivery happens incrementally throughout the project, instead of one big bang at the end.
This is a super big change in the way of thinking for us and even more so for traditional administrators who are used to seeing proposals and timelines and dates for deadlines. And while we managed to run, for the most part, our project with an Agile model and mindset, it wasn’t easily done a Waterfall organisation where picking up the phone to order a new desk or secure more office space just didn’t happen, let alone work.
Agile Primer
Agile is an iterative model of software development. The iterations are called Sprints, and within those Sprints, we work on Stories that have been prioritised by the Product Owner.
Sprints can vary in length from project to project but are always the same within a project. The beginning of the sprint the Product Owner lets the development team know which features and functionality are to be prioritised, so the team can then plan what will be achieved by the end of the sprint - and that, by the way, is the goal of every sprint: to finish things to the level of minimum viable product - that is, sufficient features to satisfy early adopters.
During the sprint, stories are tracked on the board by way of daily meetings. The board is a very simple "to do", "doing", "done", "blocker" set up and the aim is to get all those stories from the "to do" left-hand side of the board to the "done" right-hand side of the board.
On the last day of the sprint, the team meets and talks about how the sprint went: we each say what went well, what could have gone better, and give shoutouts to people who did particularly well. Then the whole team gathers and invites stakeholders, business owners and customers to a meeting where the work that has been finished is showcased.
Agile also has a few philosophies that help created a culture of success:
satisfy the customer
welcome change
deliver frequently
measure progress
motivate people
high bandwidth
whole team daily
sustainable
technical excellence
self-organising team
continuous improvement
simplicity
Agile's values include:
individual and interactions over processes and tools
working software over comprehensive documentation
customer collaboration over contract negotiation
responding to change over following a plan
There are some key roles in agile too:
Product Owner - this person has the strategic vision for the project. They are also the guardian of the user stories on behalf of the stakeholders. The Product Owner has the final say about what is on the list of stories (called a backlog) and she prioritises the stories so the Team knows which ones to work on and when.
Scrum Master - ensures the team has everything they need to do their job. He runs the ceremonies such as the retrospective and planning. He identifies and works to remove roadblocks so the team's velocity remains high.
Development Team - these self-directed experts create a cross-functional team. Each member is a specialist in their particular area. They work and communicate clearly with each other. They do their work to the very best of their ability.
That sounds great and it works really well for producing functional software where there are many unknowns at the beginning of the project.
We created templates and components and a new website homepage following this model. It was intense and fast-paced and exhilarating and successful.
But now we needed to migrate content over to support that homepage. The development team created a wonderful menu component and so now it was time for us to figure out how to migrate the site.
How do we continue at this rate of speed, this standard of work, with content? With words and photos and video and tables and PDFs and all the stuff we had on our website. And we had a LOT OF STUFF on our website.
How did we decide what we needed to get the job done? Read A content team’s Agile journey.