Share:

Breaking down barriers: Agile and Scrum at Miami University

by Elizabeth Jenike, IT Services

If you’ve ever wondered how an IT project gets done, let us introduce you to two concepts: Agile and Scrum.

In order to “stand up” (i.e., complete) projects with tight budgets and tighter deadlines, development teams are more successful when they’re precise. There often isn’t time to make mistakes or navigate misunderstandings. In the past, projects proceeded incrementally, moving from one step in the development process to the next. This was fine, as long as nothing went wrong in a middle step—because sometimes, due to the rigid nature of the process, projects would have to be restarted from the beginning.

Agile methodologies were devised by software creators as a response to the need for a more iterative, flexible development process. Gone are the days of waterfall development, where a more heavily structured plan and timeline are the norm, and customers aren’t necessarily involved on a day-to-day basis. Instead, Agile brings clients into the development process and breaks up the project into meaningful (but still discrete) chunks of work, or "sprints."

So, back to our vocabulary words: Agile and Scrum. Agile is the actual development process behind cross-functional team-centered, iterative work. The term was first used when a group of software gurus gathered at a ski lodge in Snowbird, Utah, and made the conscious decision to use the word "agile" instead of "lightweight." Scrum is the framework we use to implement Agile: the daily meetings, standups, and tools that make Agile possible. "Scrum" was taken from a 1986 study that compared high-performing, cross-functional teams to how Rugby teams operate: moving down the field as one unit.

Five values of Scrum

There are five key “values” that Scrum strives to support:

  • Courage
  • Commitment
  • Focus
  • Openness
  • Respect

You’ll notice none of these include any “tech talk.” This is because Scrum isn’t just about completing a development project: It’s about cultivating a team environment and working together to improve communication and overall outcomes. After all, if you’re working as a unit rather than as separate parts, it’s easier to incorporate everyone’s vision for the project—and to address challenges as they emerge.

The part about addressing challenges sooner rather than later is an important selling point for Agile and Scrum. Before Agile, the process looked like this:

  1. Product owners (i.e., the customer requesting the application) would give project managers a set of instructions for how they wanted an application to work.
  2. Project managers would relay those instructions to development teams.
  3. Developers would create that product.

Seems simple enough. However, this was akin to a high-stakes game of Telephone. Sometimes, the final product would fall short of expectations due to some communication error along the way. Then it was back to the drawing board.

Scrum takes out that middle step and puts product owners in conversation with developers. Here, teams work closely together and voice concerns as soon as they arise. This allows them to quickly troubleshoot issues, and communication errors can be snuffed out before they become problems. This leads to a better, more on-target product down the line.

When it comes to getting IT projects done on campus, and communicating effectively between teams, senior application developer Erin Mills knows exactly what’s up. Her voice is one of the loudest rising to evangelize Agile and Scrum, and her passion for working within these frameworks is infectious.

“We’re trying to build you the right thing!” she said. “We don’t know it’s right unless you tell us it’s right.”

Mills noted that the Agile process is essential in bringing campus power players and developers alike to a level playing field.

Humble beginnings

Miami University IT teams haven’t always used Agile methodologies. Around six years ago, project manager Mary Brooks was one of the first pioneers of Agile and Scrum in IT Services. After a few ‘pilot projects’ used Scrum to success, she was able to branch out and begin to work with more teams using these methods, because clients saw value in focusing on collaboration and daily communication.

Now, Brooks facilitates Scrum and team activities and working sessions, assisting teams in striving to become higher-performing, self-organizing teams. A lot of her day-to-day involves helping developers and clients understand what, exactly, Scrum and Agile mean.

“My role is more fulfilling for me because of the increased engagement with team members and the opportunities to provide training and support to continue the Agile transformation,” she said.

For Brooks, the benefits of the training she offers are two-fold. There are the concrete benefits of faster delivery of customer value, projects being completed on time, and increased customer engagement and partnerships. These are all tried-and-true outcomes of the Agile and Scrum process. But other outcomes are more organic. For instance, she enjoys seeing people find ways to increase efficiency and change their thought processes.

“I truly enjoy training and coaching folks in Agile and Scrum,” she said. “It's gratifying to see what happens as teams realize the benefits by making just a few changes in the way they do their work.”

Time worth spending

When Brooks started to incorporate Agile methodology into her projects, University clients had understandable reservations. The time commitment required of product owners is often one of the biggest challenges to overcome: The idea of attending daily standups and weekly meetings, and sometimes afternoon-long planning sessions, seems insurmountable at first.

Senior associate registrar Mandy Euen didn’t quite know what she was getting herself into when she was brought into the Registration Override Request Project (ROR) being worked on by Mills and her team. In fact, she was quite skeptical of Scrum and Agile, mostly because she didn’t think she had the time. She would have to meet with the team—either via Webex or Slack conversation or actual in-person meeting—every day or every other day.

However, as the project progressed, Euen realized that the daily or every-other-day meetings weren’t just for show. She gained an advantage from getting to know the developers and obtaining valuable, real-time feedback on her ideas. In the end, the time commitment wasn’t an impediment. In fact, Euen began to see their daily conversations as a definite improvement over the project process she had been familiar with.

“They were flexible and respectful of my time,” she said. “We figured out ways for me to be available.”

And in the end, it was worth the perceived hassle.

“This is one of the biggest and most complicated apps that has ever been built in-house at Miami,” Euen said. “Not only did they find a way to do it, but [the app] exceeded my expectations.”

Euen isn’t the only (eventually) happy proponent of the Agile process. Lindsay Carpenter, the assistant provost of budget and analytics at Miami, was one of those campus power players who came to IT Services for help creating an app. The Course List application project happened during a time when the development teams were still working out the logistics of not only Scrum and Agile, but also new team members.

“The first week was rough,” she remembered. “I was nervous that my first and only IT project was going to be an epic failure.”

What she learned by the end of the process, however, was that the initial bumps in the road smoothed out, paving the way for a lot of work to be done in a short period of time.

“My IT team really had taken the first few weeks to figure out not only the logistics of how to work together and who had what strengths, but had done their research and learned how to code in the Laravel language,” she said. “Not only was this group completing the requests that the stakeholders had identified, but they were making suggestions that made the site tremendously better. [...] The agile process worked well for the phenomenal group of IT developers I had on my team.”

Focusing on trust gets the job done

Being able to work closely with University leaders like Euen and Carpenter and having the kind of relationship that allows for that kind of transparent back-and-forth is priceless, according to Mills.

“When you work with somebody so closely, you build trust in each other,” Mills said. “When you trust each other and know each other better, you’re more likely to be open and transparent. It’s easier to have the courage to tell somebody the truth.”

Mills even noted that Euen, after completing the ROR project, expressed interest in continuing to work with her team on the other projects for which Euen was the product owner.

“It’s been a great experience, and I’m grateful for what they were able to produce,” Euen said. “I’m looking forward to working with the team again on this.”

Scrum also serves to support an idea that is not new: Via the Agile/Scrum vehicle, teams strive for (and can arrive at) technical excellence.

“When folks are willing to go along with the framework and the practices for a couple of days to a couple of weeks, they experience the transparency, the increased efficiencies, the quicker delivered value, and they quickly become proponents of the process and the transformation,” Brooks said.

Carpenter, for one, was beyond happy with the value delivered by her IT team during the Course List project.

“[The development] team could have just done what I asked them to do and accomplished the task, [...] but they went above and beyond to give me and the community an exceptional Course List tool,” she said.