They’re a small team of five, but the Web and Development team at University of Arkansas at Little Rock were ready to take on projects using agile methodology, because yes, it is possible for agile in Higher Ed.
Let’s back up. What is agile? Dan and Jenn outline what agile is, and isn’t:
- Individuals and interactions over process and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Woah woah woah wait. This is pretty opposite from what we’re used to in higher ed. But, for Jenn and Dan’s small team, it works. Agile is not artifact heavy, process obsessed, and is not just for software development. Agile is a way of viewing the world around you, alongside the way you view work responsibilities and tasks. It’s easy to assume that agile methodology is an excuse for scope creep or a way to eliminate planning or documentation, but Jenn and Dan – and the rest of their team – can assure you that it isn’t.
Jenn and Dan compared agile and waterfall, another common working method. And yes, the TLC reference was made. Stick to the rivers and lakes that you’re used to, folks. Agile is ideal for a team environment, as it is adaptive and innovative while providing more transparency as well as solving real problems.
Waterfall follows a basic structure, moving in a line. The key difference lies in the “design,” “test,” and “build” phase. 
There are a variety of types of agile including XP, Crystal, Kanban, but most importantly, your own. Doing what works best for your team and finding the balance of workflow comes with time and testing new methods.
Jenn and Dan described the “sprint.” This is a short, sustainable burst of activity to complete or nearly complete a story. These sprints are two weeks long, generally, and sometimes sent back into the backlog, depending on the size of the project. Each team member moves at a different pace depending on the nature of their position, but each sprint lasts the same amount of time across all team members.
Collaboration is key, and a working space is integral to collaboration. The UALR team meets in a small space, allowing for better collaboration, and a little bit of perspiration. UALR also implemented other important aspects of agile that many of us may already use, such as daily standup/scrum, all the way through to a burndown (measure of how quickly you are moving through stories).
Jenn and Danrecommend Trello as well as Jira, to work agile into your team’s workflow. Trello is free, and used by Jenn and Dave at UALR. They’re big fans.
The best agile method, though, is what works for your team. Jenn and Dan use a blend of Scrum and Kanban to create the sweet mix of productivity. It took some time to figure it out, and at the start, their “fresh” agile was truly…fr..agile. The key was to create a process that removes process (and no, that’s not a typo). The removal of unnecessary process through process is one key aspect to an agile workflow.
Documentation is important, which is why the UALR team uses Trello to document as well as remove the cumbersome processes of daily work tasks. The other resource? Team members. Each team member has a unique talent, important to agile. With a mix of these considerations, and others, Jenn and Dan moved forward without fear.
It’s hard to swallow sometimes, but failure is ok. Failing frequently, fixing them, and sharing success is an important part of productivity on Dan and Jenn’s team.
Trello is a free service, which is helpful to the ULRA team. Step one is the backlog. All projects, no matter the origin, go to the backlog list. For each project vision, a story is formed. It’s important to ask: Why do this? Who is this for? What is the elevator pitch? What is the scope? This breakdown should be done before the start of each project so that every team member is on the same page, while also understanding the expectations for the project.
At the start of the sprint, Jenn takes about an hour to determine the most important projects to tackle, and update next iteration for ongoing projects. It’s important to note that for the sake of sanity, we need to say “no” more than we say “yes.” You’d think this would cause some pushback, but Jenn and Dan report that there was little. To determine what is a “no” or a “yes” Jenn looks at the Eisenhower Matrix, which analyzes projects based on importance and urgency.
Then, the team gathers for a sprint kickoff. Another 1-2 hours. Stories are weighted by magnitude in a round of “story poker.” UALR uses an arbitrary scale to weigh the importance of each task – T-Shirt sizes, fibonacci numbers, ice cream flavors…the list goes on.
Next is the standup, or scrum. This is a daily 15 minute meeting where every team member shares:
- what they did yesterday
- what they are going to do today
- what roadblocks they are having
The sprint ends by moving stories from “to do” forward. To do goes to in development/progress, then testing moves to “DoneDone.” If it doesn’t reach DoneDone, it goes into the backlog. Wash, rinse, repeat.
To measure velocity, Dan created a simple spreadsheet, which displays the number of hours/team for each sprint. Dave noted the level of “sanity” for teams, as well as a dizzying record of historicity, displaying two week sprints which can span back well over a year. This record is something that is incredibly helpful to pass along to leadership to determine what has been done. Trello uses tags for stories, so if you ever need to filter through to find specific types of projects, it’s simple.
Like any major change in higher education, it requires buy in, but how is it done? Everyone must be open to change and willing to commit. Once the team got buy in from IT, they moved forward by adopting agile to the team. Like any new process, the team at UALR did hit some snags, including burnout, an out of control backlog, and scope creep. With practice, it’s clear that these things can be handled based on the successful projects Jenn and Dan showcased. It’s all about finding what works best with you and your team.
By thinking strategically, including knowing your capabilities, testing them with an internal project, picking some easy wins to practice, and picking a solvable problem, and assigning a champion to keep detractors at bay, Jenn and Dan slowly introduced agile as well as mastered it, continuing to hit their productivity “sweet spot” for all their projects.
Resources:
Books:
- The Agile Samurai
- The Lean Startup
- The Elements of Scrum
- Practices of an Agile Developer
- Scrim: The Art of Doing Twice the work in Half the Time
