One of the tech industry’s most impactful success stories isn’t in a product or time-saving application. It’s not how much control the iPhone has over our lives, either. Instead, one of the biggest behind the scenes revolutions in technology is how our day to day work gets done. They’re agile.
Because technologists have the propensity to get bogged down with overthinking while trying to solve endless riddles and battling roadblocks, developers figured out a way to fight back against cumbersome processes and streamline everything.
The Agile Methodology grew out of their frustration and it changed the game. The best thing about “going agile” is that while it may seem like adopting its principles could be hard, it’s totally not. It’s pretty easy.
Working with agility doesn’t require an advanced degree or a pile of books to understand. If management and the team are committed to streamlining their processes and changing the culture of how their team works, agility is a proven agent of change; it’s a matter of establishing good habits.
If you’re on a non-technical team, but looking to improve how your crew accomplishes its goals, this article will help. We’ll show you how changes in process, communication, and visibility will upend what you’re doing, but also make things run smoother.
Going agile will help your team:
- Identify bad work habits
- Solve bottlenecking
- Improve team collaboration
- Create a culture of transparency
From Obstructionist Development to Constant Communication
Back in the day, developers relied on a framework for their updates in a “waterfall model” that emphasized a series of steps throughout the software development cycle. The idea for the methodology’s namesake was that it was like cascading steps down an incremental “waterfall” of progress.
Relying on this process helped software teams churn out new versions of products on an annual basis, not through continual releases as is the standard today.
In the days before everyone was connected on Wi-Fi, software companies could take their time and release software as an event. Do you remember when Windows XP dropped? That was a big deal and an even bigger marketing campaign. Just look up some of the videos on YouTube, they’re so cringe-worthy, yet amazing.
Today, we get an icon in the upper right hand of our screen saying we need to download a new update and that we can’t use our devices for the next ten minutes. There’s no fanfare, no red carpet events. It’s an update, one of many released throughout the year. This example is the apparent difference between agile and waterfall methodologies.
While in vogue, the waterfall process was pretty basic: Everything followed a logical pattern and never deviated from the path. The cliff notes version of waterfall development works as follows:
- Requirements: Everything is written down, obsessed about, considered and defines what application is being built, but not the “how”. Kind of the “let’s throw this big idea at the wall” phase.
- Analysis: The whole thing is analyzed and some crazy smart people generate models, then a business case is made so the boss lets the work happen.
- Design: The foundation of the work is laid down. The programming lingo is set, jobs are established and the plan is put into place. This step creates the bones of the project.
- Coding: Real source code is written, the project is starting to take shape.
- Testing: This phase is dedicated to seeing if the project has legs. Can it work, even in its baby stages? What can break? This is probably the essential aspect of waterfall developing.
- Operations: Testing is over. The project is ready for a live environment. The site or app or whatever is ready to go, or at least ready enough.
For a while, this was the gold standard. Today, not so much. Waterfall outdated itself because it couldn’t evolve. Sure, some teams still use the method, but they’d likely be remiss to say they’re not cranking out the work. With so many bootstrapped teams coming up, streamlining processes needed to be developed.
What Exactly is the Agile Methodology?
In its purest form, going agile means streamlining everything. Every process, every communication, hacks the fat off the bone for the sake of adaptability and moving projects forward, even against the odds.
Instead of relying on tired and inflexible practices, agility leans on communication and transparency as its most important tenants. The idea is to keep the developers and “the business” (aka the brass), marketing, stakeholders, etc. informed on progress.
The basis of the model is outlined in the original document, The Agile Manifesto, which owes its DNA to early delivery, adaptive planning, and continuous improvement. If your team is consistently hitting bottlenecks with its goals, agile can probably help alleviate that stress because of how the workflow moves through the daily and weekly channels of communication.
Transparency is the Way
Probably the biggest cornerstone of agility is transparency. Every member of the team needs to be open and honest about their work, what they’re doing, working toward what goal and what the next steps are. That’s it. Everything else is secondary.
Adaptability is what’s essential when working with an agile process. Waterfall remains static in the way it’s executed, while agility goes with the flow. (Pun intended.) Keeping in constant contact with the team throughout the lifecycle of the project helps to stay on the same page. The spirit of communication and collaboration, a few points need to be held as the gospel according to The Agile Manifesto:
1. Individuals and interactions over processes and tools
2. Tangible results over mountains paperwork
3. Respond to change instead of following a plan
4. Collaborate with customers, take their feedback seriously
So, how do you foster a culture of transparency and inclusivity? Start with a daily stand-up.
Stand, Don’t Sit
The daily stand-up is a critical best practice and is very beneficial to the life and success of your projects. The essential DNA of the stand-up is clarity and communication, and it’s so easy to do.
Every morning, or at least once a week, after everyone’s had their coffee, the team gathers at the same place, at the same time. No sitting. Real standing. Standing up vs. sitting reminds people to keep their update brief. Everyone gathers in a circle near their desks, over in the center of the room, near the snacks, whatever works for the team.
The team will go around clockwise and inform everyone on what they’re working on, what they have planned for the rest of the day and if there are any roadblocks. No need to dive deep, keep the updates to the highlights—or your 20%—only.
If you need more time to explain something to a teammate, let them know you need a side-session and move on. Don’t clog the stand-up with a lengthy breakdown. Save that for a meeting or a one-on-one. Once the person has given their update, it’s time for the next in line.
If a team member is remote, there are plenty of tools like Stride or Slack to use, which offer video right in the software. (For The ONE Thing team, we use Zoom.) Both applications have bots you can install into chat rooms to remind the team about stand-up time and even manually type in what you’re working on so it’s searchable if someone’s got a question.
The driving point of the stand-up is to let the team know where you stand on a project while also maintaining transparency about your progress. It’s practical, easy and free. And most importantly, it keeps the entire team on the same page about the things they’re doing to drive your business forward.
Agility Adapts to Your Team
There are a few agile ideologies and types of ways to get work done. Whatever mix is right for you, will often be the result of tweaking and testing. The two most dominant methods for a non-technical teams to go agile are Scrum and Kanban.
What’s Scrum?
Scrum takes an iterative approach, focusing on defining objectives before each sprint. When you’re relying on Scrum, everything revolves around the sprint.
A sprint is a cycle of time meant for the week’s work but is designed to provide value. Every day, someone on the team accounts for their time.
If there are 8 hours in a workday, everything is accounted for. Breaks, leaving early, researching, learning, writing emails — whatever someone needs to accomplish that week — all of it is broken down and discussed at the weekly meeting of the team.
The idea of the sprint is to be capable of managing roadblocks based on the ability to change course. At the beginning of the week, the team gathers and discusses what they’re working on through a 4-1-1. The team agrees these small, task-oriented projects are meaningful, and then they start the week’s sprint.
The “Scrum Master” keeps track of how the team gets stuff done, and the cycle repeats. Either once a week or once a month, the team will gather for a “retrospective” and discuss what was good, bad or ugly about the sprint. They’ll talk about what challenges they faced or if something could have worked better.
Scrum can be adopted for non-technical teams, but based on the nature of the beast, things can get in the weeds quickly if a timed approach isn’t feasible. If your team isn’t great with the minutia of a project, Scrum may be a little too geeky.
BUT, all hope isn’t lost. Not even slightly. Chances are, the answer to your team’s prayers is using a Kanban board. Kanban is simple to use and immediately reaps rewards.
Here’s How Kanban Breaks Down
Kanban has been around for a while. It was created by Toyota back in the day to increase productivity in factories. It works exceptionally well when coupled with a daily stand-up.
Think of Kanban like a big To-Do list. Whereas Scrum is worried about incremental chunks of time spent on a weekly basis, Kanban is dedicated to the amount of work you declare for yourself at the beginning of the week. Kanban isn’t time-based. It’s based on priority.
Once a week, the team gathers to plan work for the upcoming week. The tasks are manageable, not monumental achievements that require a lot of hours. The idea is to showcase the little things that go into the big projects, and if course needs to be changed, adjusted at will.
Once the team agrees upon the work, it moves to the board. A board can be a literal board on the wall with Post-It notes or software like Trello. Whichever your method, there are three columns:
• To do
• In Progress
• Done
At first, everything hangs in “To Do” and moves into “In Progress” as you’re working on your project. As stuff gets completed, it moves to the “Done” stage. If you’re using Trello, it’s easy to track the analytics of the team and how much work is getting done on a weekly basis.
Here’s a Real-world Scenario Using Both Kanban and a Stand-up
The team at Jade’s Kitchen Supply goes agile. Their internal processes aren’t fluid. Adopting a better way could help them fix some of the communication breakdowns happening almost daily.
Every morning, the core team of six workers meets at ten thirty. They talk about what they’ll be working on that day. If Melinda, who manages the delivery intake, notices something in stock is missing, she’ll call it out and hope that Arnold who does the ordering knows precisely what’s missing and will correct the issue.
This is beneficial to the rest of the team because the issue is brought up, is commented on and there’s no guesswork as to what’s going to happen. Accountability has been established and agreed upon.
Everyone offers updates on what they’re working on as a quick refresher. All of the tasks discussed were agreed upon last Thursday in the weekly planning meeting.
A big board hangs in the back of the shop with the three columns. As Simon, the stocker sees a tag to rearrange the pizza supply aisle, he sticks it in as “In Progress” and gets to work. Everyone on the team agreed on this needing to get done last week, they see it on the board, and they know it’s under control.
This transparency limits questions and concerns about time and what Simon is working on. Simon knows what he needs to accomplish. If he takes a longer lunch or leaves early, that’s fine. He’s committed and accountable for the agreed upon work. Same goes for the rest of the team and their weekly projects, as well.
And that’s it. The Stand-up + Kanban model can be applied to just about any workplace.
Other agile principles could work, but these seem to be the most natural and beneficial to a non-technical team. Books by the armful exist about the agile methodology, so it’s easy to fall down the rabbit hole trying to find new ways to get your team working faster than ever – pizza supplies and all.
What kind of models do you or your team use? Let us know on our Facebook page!