Applying Agile and Waterfall Workflows to an Academic Web Team

|
Content Author:
Misty Treanor
Applying Agile and Waterfall Workflows to an Academic Web Team

Following a year as the CALS/LAS Web Team’s project manager, I decided I needed to learn more about Agile workflows. I had heard about Agile, and I was told our team used the methodology, but I wasn’t sure how or where improvement could be made. 

linked in logo and penKnowing we have access to LinkedIn Learning as ISU employees, I went to see what courses were available, and I was happy to find the Atlassian Agile Project Management Professional Certificate. Becoming certified took over 7 hours and was composed of 6 different courses. 

A quick overview of Waterfall vs Agile

Waterfall: A one-way workflow, this process entails a clearly defined execution sequence that is rigid in the project phases. The current phase does not advance until the previous phase receives final approval. Changing the plan that took a long time to create is difficult. 

Agile: Perhaps given this name because it requires the ability to pivot quickly, an agile workflow is a mindset, not a structured plan or sequence, that involves understanding, collaborating, learning, and flexibility to create high-quality results. This methodology is adaptable to changes as the high-level development plans are not written out in excruciating detail, so it is not rigid, they are organized in priority order. 

Groups that work in software development likely already know what Agile is, but most people generally work using the waterfall methodology, whether they know they are using it or not. 

Going through the Agile certification process, it became clear that the intended audience was software development agencies. While this team has several very talented developers, it is not a for-hire team, and we also have an on-demand customer service component, so an entirely Agile mindset would not benefit our team. We need to mix in some waterfall methodology.   

Good thing for the CALS/LAS Web Team, I’m now educated in both methodologies!  

If you’re a budding new web team looking to improve your project management, or improve your team’s workflow in general, this overview of how we piece the two methodologies together might help to enhance your processes.  


Waterfall Components waterfall graphic

Plan > Analyze > Design > Code > Test > Deploy 

Our team basically does waterfall, but we apply Agile to it. We don’t have the benefit of being contracted to do one project at a time or even just a few at a time. However, we use our stand-up* meetings to apply Agile to the pieces of Waterfall. This combination helps ensure folks do not stay blocked by others for long.  

For many projects, we also treat the planning phase more like an Agile project by breaking it down into categories or subsections of the overall project (Agile would call these story points) and then working on them in small batches*. This allows for adaptability* instead of planning ourselves into immovable boxes.  

Where our team aligns consistently with the waterfall methodology would be how we deploy our code. We have a rigidly structured release process. Before a new piece of code, update, feature, change, etc., is applied to our websites, it must go through the planning, analyzing, design, code, and test phase as its own pull request before it gets merged into the release’s main release update. The main pull request will then also go through the entirety of the waterfall process to verify that the new code interacts nicely with our existing codebase. Moving forward, I would be interested in reducing setup times*, automating various parts of this*, and eliminating waste*. However, I am not a developer, so that will be a much larger work in progress! 

*Denotes an Agile component you’ll be introduced to in the next section 


Agile Components Agile graphic

We use sprints, scrum boards, and stand-up meetings to facilitate collaboration and tracking. The sprint is a time period to keep team members accountable for their time, scrum boards organize projects by client, and stand-up meetings are team meetings that give everyone a chance to share progress and request support if needed.  

We meet twice weekly to share our priorities for the week and then check in later in the week and update the team on progress. 

  • We do not use epics or story points as they do not fit into the workflow and client needs! 
  • Normally, an Agile team would not add new tickets into the current sprint mid-sprint because that would alter their story points and time estimates, reducing the accuracy of their future time estimations for projects. On an Agile team, the sprints are all built by the scrum master who is already planning for the next sprint while the current one is going. So, if changes are happening mid-sprint, that means the effort the scrum master should be putting into the future sprint is being lost in the current sprint that should be in the hands of the developers. Additionally, changing work mid-sprint could also shift the balance of work amongst the team or create unexpected blockers when the sprint’s focus unexpectedly changes. However, we serve our academic clients and must add tickets to our sprint as client needs and issues arise; we cannot wait until the next sprint as a true Agile team would.  

Using these pieces of the agile workflow allow us to focus on improving three areas of the Agile mindset: 

  • Limit work in progress / small batch size 
  • Reduce setup times 
  • Automate what should be automated 

Limit work in progress / small batch size batch size graphic

  • Each team member should only have tickets in the active sprint they are currently working on or genuinely intend to work on that week. 
  • Your project manager should create a dashboard with required tracking to keep all team members accountable for their workload each sprint. Each member can create their dashboard, but it should minimally include current sprint tickets, on-deck tickets (tickets for the next sprint), and backlog tickets (tickets that are low priority and can be addressed with extra time). The dashboard should also include a heatmap of tickets amongst team members and a live activity feed of all team members for work being logged. 
  • The project manager should train each member on their dashboard and how to use the ticketing system appropriately to limit the work in progress. Additional filters can be added to meet various needs.  

Reduce setup times steps graphic

Our team is actively working on different processes to reduce setup times, including: 

  • Ensuring student workers have the necessary permissions to empower them to work independently 
  • Creating templates and showcases for clients to review when new projects are started 
  • Extending the catalog of available tutorials 
  • Consistently writing blogs over common issues to provide clients an evergreen resource instead of writing up or modifying the same response via email several times monthly  

Since our work does have a significant element of client-focused work, the more we can point folks to high-quality, accurate information, the less time we spend rewriting or searching for old responses or examples. Thus, our projects can get off the ground more quickly! 


Automate what should be automated automation graphic

Many of our current automation efforts are on the back end of our development. Being able to automatically export a live copy of our websites into a testing environment is a long-term goal of ours. Currently, this type of action requires numerous actions to copy a website’s live back-end database and get it working in a testing environment before any work can begin. Having the ability to automatically export a live site directly into a testing environment would create a “product” that showcases several Agile components. 

Our team also hosts the ISU faculty websites. We’ve created a platform that allows faculty members to create and upgrade the level of their sites without needing our assistance - something the team found important to empower them to do.   

Additionally, as a web team of a content management system, each new feature we develop we do with the intention of folks being able to edit content through automation. A recent example would be the Accordion and Carousel blocks our team created for our Sites+ sites. While we must be contacted to place the blocks, they were set up to work through predetermined relationships so that our clients can edit them without us, thus increasing automation and reducing human intervention.  

Conclusion 

Take what you need; leave the rest behind. Working within your team’s strengths and building values around them is more important than requiring 100% of either workflow. The progress, responsiveness, and success of the team wouldn’t be as great if it weren’t for the mixture of methodology, and it’s been fulfilling getting to work on this “review and improve” after a year of managing projects.  

Do you have project management strategies to share or questions about our process? Contact websupport@iastate.edu

Body