By Sean Beld.
This fall, over seventy-five UCOP IT employees attended Scrum training sessions led by Trail Ridge Consulting. Separate training sessions were held for managers so they could learn about Scrum and how to foster a supportive environment for their teams’ Agile journeys.
The upshot of all that training? Well, we’ve formed UCOP’s first Agile team, as well as the first cross-functional infrastructure Scrum team with a focus on AWS cloud services. In December, the team successfully completed its third two-week Sprint.
An important objective of our move to Agile is to increase employee satisfaction by creating cross-functional teams that work together on engaging projects. By adopting this new framework, UCOP Information Technology Services hopes to deliver high-quality work in a timely way.
We’re eager to be part of and learn from the UC wide Agile community. We hope UC colleagues will share your Agile success stories and questions with the UCOP Agile team by emailing email@example.com. Let’s also connect via the UC Tech #agile Slack channel.
What are Agile and Scrum?
For those new to the terms Agile, Scrum, and Sprints, let me provide an overview. Agile is a development methodology centered around communication and responding to change, values which the authors of the Agile Manifesto solidified in a series of concise statements:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
The goal of Agile is to move away from the Waterfall or “relay race” model of product development and toward a more flexible and collaborative method where barriers to progress are addressed and resolved as they materialize.
For example, in the traditional Waterfall model, a team might spend one month gathering requirements for a new product, another two months on design, two more months on coding, and finish it all off with several weeks or months of testing. This approach leads to a lot of wasted time, since the customer usually doesn’t get to see the end product until the end of the process, at which time making changes is much more difficult and time-consuming. The Waterfall model also leaves testing to the final stages of development, leaving room for problems to go unnoticed until the project nears completion.
In the Agile methodology each project is broken up into development cycles, which in Scrum are called “Sprints” (more on Scrum later). Rather than breaking a project up into stages like the Waterfall model, the team delivers a core set of features with the first release, then addresses any remaining features in future releases. This way, a working product can be delivered to the customer at the end of the first cycle. This method speeds up delivery time and allows the customer to be involved in development by having functioning software they can actually use and give feedback on. Any feedback from the customer or issues detected by the development team during an iteration can be prioritized for future iterations, which prevents issues from going unnoticed until testing.
Scrum, which borrows its name from rugby, is a framework for implementing Agile. With Scrum, work is organized into short, iterative cycles called Sprints. Each Sprint is completed by a Scrum team composed of a product owner, a scrum master, and the rest of the development team. Within each sprint, the Scrum team meets daily – standing up – to discuss their progress, what they are working on, and how to address any issues that may be blocking progress.
Sean Beld is a web accessibility specialist in Information Technology Services, University of California Office of the President.