At an institution as progressive as Kent State, where technology is fundamentally changing the way students learn and faculty teach, perhaps the only certainty is that nothing stays the same for too long.
"When I started at KSU as a student in the late 90s, everything was paper-based,” says Systems Development and Innovation’s Project Manager and Interim Executive Director, Sameer Jaleel.
"Now, we expect technology to predict our wants and needs, and when that’s not feasible, we expect to use technology to control every process, and we expect immediate, real-time results.”
"Computers were involved for the backoffice users, meaning someone was hand-entering everything--and that was the normal use of technology back then. Our expectations of technology have since changed multifold. Now, we expect technology to predict our wants and needs, and when that’s not feasible, we expect to use technology to control every process, and we expect immediate, real-time results.”
Speaking from 20+ years of experience at KSU, Jaleel emphasizes that the university’s willingness to adapt to change has been a critical to its success over time.
Continuous Improvement
Such adaptation is commonly referred to as a practice known as continuous improvement, and it is the driving force behind organizations seeking to improve their functionalities. So what, specifically, does continuous improvement look like at KSU?
From a tech standpoint, the answer lies within Systems Development and Innovation’s active development of digital products and applications for the KSU community, which includes all students, faculty, and university departments.
When crafting new digital products, SD&I addresses problems that either users, stakeholders, or the department itself identify. These could include:
- fixing FlashLine bugs
- helping students find out when the next bus is coming to pick them up
- helping students locate where buildings are located on campus
- updating the KSUMobile app’s interface to make it more user-friendly
SD&I’s products, in effect, serve as solutions to these issues. And as such, SD&I makes sure that collaboration is always involved in this process.
"If a project is being developed for a particular stakeholder, we meet with them biweekly and show them our progress,” explains UX Developer Jade Green-Gamble.
Green-Gamble is part of a team that contributes to the design of all products SD&I develops, so she is always looking for ways in which user experience can be improved--mostly by working directly with stakeholders and users themselves as the changes are being made to the product.
"We show them what it is we have been working on and how it works. And they can say, ‘Okay, yeah, that’s the right direction,’ or, ‘What about this part that’s really important to us? Is there any way we can implement x, y, z?’ It’s definitely a lot more collaborative in this way.”
Development Workflow
The development process is as follows:
- SD&I first creates a minimum viable product. This is a stripped down version of the product, including only the elements essential to its functionality
- The product is released to stakeholders and a segment of the public for user testing. At this stage, users have the opportunity to provide their feedback, informing what works, what is missing, what people want to see, etc.
- Accordingly, SD&I can revise the products based on this feedback, ensuring that products that meet diverse user needs are being delivered
Agile Development
This workflow is an example of something known as an iterative process, because it is just that--a process that allows for changes to be made.
But as iterations have become more efficient in practice, what has grown out of this process is something known more specifically as agile development, as changes are made continuously and with valuable input from stakeholders and users. This ultimately keeps the development team on their toes throughout the sprint cycle, during which time they exclusively focus on the specific development effort.
A primary benefit of this approach is that it allows for changes to be made post-release, effectively enabling developers to work backward and products to be consistently updated, if necessary.
Green-Gamble says that agile development helps her understand that though SD&I always aims for its releases to be perfect, they don’t have to be absolutely perfect right away. "We know we are going to learn from what we do put out and then improve upon it and put out something even better. Overall, it is a much better approach to design.”
After Green-Gamble completes user testing, SD&I Application Developers bring her and the UX team’s designs to life through front end development.
Eddie Zgonc is one such developer involved in this process, and he explains the necessity of being open to revisions under the agile model.
"As a developer, I have to be open to those critiques and to those changes along the way."
"You’re working alongside and having regular check-ins with the client so that they can see things develop as they’re actually developing,” he says. “So as a developer, I have to be open to those critiques and to those changes along the way. It is a lot different than things I have done in the past because usually you get the mockups and you stick with them, but here it’s like a living, breathing product as it evolves.”
Zgonc echoes the sentiments provided by Green-Gamble, highlighting the role collaboration plays in the development process from start to finish. He also adds that when things are transparent for everyone involved, the end product is much more likely to meet the stakeholder’s initial vision.
A Necessary Change of Approach
Agile replaces an older method of development known as waterfall, which was widely used in IT organizations until fairly recently.
Under this model, developers research user needs, develop an entire product, and then send it down the hierarchical line to the end user when it is finished (one-way channel).
The issues with waterfall development are that:
- clients do not discover product features until the development process is over
- feedback is not being collected from users throughout the process, so developers risk falling short of meeting user needs
- it does not allow for working backwards as easily or seamlessly
Thus, agile development has largely been implemented instead to avoid these issues.
Making The Switch to Agile Development
Though SD&I is not exclusively agile in its workflow process, since early 2016 every project has incorporated elements of agile development in some form.
In the fall of 2017, the Events Calendar was launched, and more recently, the FlashLine pre-release UI was introduced through SD&I’s Pioneer Program. Aside from the cleaner UI, the navigation interaction has improved, as well as the mobile experience.
"Student user testing is agile in the sense that we can receive feedback about designs prior to development,” Zgonc says. “We can put a design in front of a student and see how they interact with it, see what’s working, see what’s not, and proceed from there, iterating before we even put a line of code down.”
Two-Week Sprint System
SD&I’s development operates under a two-week-long sprint method, meaning that something is being delivered at the end of every two-week cycle--whether it is an updated version of FlashLine with any front end/back end bug fixes or an entirely new product, such as the Jobs Description application.
What is helpful about this is that different departments are able to test SD&I products more frequently, which allows clients to fine tune their needs; SD&I can then make those changes without compromising the overall development timeline.
Moreover, this system allows SD&I to track progress more effectively over time. Developers meet with Jaleel for a show and tell type exercise at the end of each sprint, where they are given the opportunity to present work and discuss any challenges encountered along the way.
At these meetings, Jaleel outlines what he looks for:
- Are we hitting the mark? Are we delivering what was expected for this phase?
- How are we doing with the overall project? Are we headed in the right direction? Are we going to meet our deadline?
- How is the team doing? Are they experiencing any internal or external obstacles? Are there things that may not seem like an obstacle now, but could it snowball into one later and cause disruption?
This review process is known as agile retrospective, and it is yet another component of agile development that exists to improve future workflow.
What Will Happen Next?
Though it has been difficult to transition from waterfall to agile, from an organizational standpoint, SD&I has been largely successful in its implementation of this new method.
"For our teams to be so new at it,” explains Green-Gamble, “I’m surprised to see how quickly it’s been adopted and executed as well as it has.”
Jaleel adds, “Though a bulk of our workforce might have adopted this way of operating because leadership pushed them towards it, I would like to believe that somewhere along the way they found value and meaning in it. We have seen considerable success in several areas where our stakeholders are deriving value through brief iterative release cycles, and we are approaching a higher level of predictability in our efforts. As an IT business unit that does not leverage budget or dollar figures to prioritize projects, we aim to get better at effort estimation to timetable our projects, and this approach and the predictability it offers goes a long way to enable that, compared to our past ways.”
And so with waterfall on its way out the door, does this mean agile development is officially here to stay?
After all, it’s hard to imagine a development process that is even more transparent, collaborative, or iterative than agile; but why should developers and stakeholders alike stop searching for one?
Why shouldn’t we embrace a future whose technology is increasingly progressive--beyond what is thought to be possible right now? And why shouldn’t Kent State University be ground zero?