When agile development was first introduced to me, I had no clue how it could be useful. How do I apply concepts like continuous development and stakeholder requirements to writing a blog post or creating a landing page?
Once I understood the principles and how a web development team would use it, I had to translate these concepts in a way that made sense for creative tasks or non-technical work.
Agile isn’t just a buzzword for developers and tech workers. It’s not a high horse for shutting down waterfall methods. Using agile principles helps with project management, client interaction, task prioritization, delivering results, and overall work attitude.
Let’s break down some of the core Agile principles and beliefs into language you can use for any task or project.
Working Software Beats Comprehensive Documentation.
Translation: Do the least amount of planning possible.
If you don’t start work until you’ve planned every detail and written all documentation, you’ll move more slowly, and your plans won’t match the final product.
With a web page, graphic, or product, that means starting with a creative brief or outline. Flesh out details from there and check in frequently to make sure you’re on track. Fix problems and take notes as you go.
Of course you still need to talk to your stakeholders, get your requirements, and make a project plan, but don’t let the planning phase overtake the production phase. You’ll check in and make changes along the way, so it’s okay to make mistakes and not to know everything up front.
Deliver Working Software Frequently.
Translation: Create something meaningful now.
Agile focuses on getting the right work started as soon as possible so you can test it and demo it. As your code/software/product takes shape, you can build on it more quickly. Find what’s working and what’s not from the product so far. Evaluate whether you’re on track with your project plan, and discuss with your team and stakeholders whether you need to adjust your plan, schedule, budget, execution, or resources.
Software development can take months to years from start to finish. The key with agile is to create a product, something you can use, as soon as possible. Your project might have a shorter timeline, but it’s still helpful to make sur your time isn’t wasted, even if it’s only hours or days instead of weeks or months.
The other benefit to delivering work early and often is the boost in motivation. Having one big, looming deadline is exhausting. If your team only gets to celebrate a launch that’s late and full of problems, they’re not going to look forward to the next release or project. Celebrating more frequent milestones and checking off more, tinier boxes keeps everyone feeling more productive and ready to keep going.
This ties in with another agile method, called sprints. Group work into defined time periods, like a week or two weeks. Plan how much work you can do in each period or sprint, then start working. Could you draft a design comp and get approval by Friday? Can you make a section in a week and demo it next sprint? Break up work into manageable chunks so you’re not overwhelmed by a big project or not motivated by a faraway date.
Value Individuals and Interactions over Processes and Tools.
Translation: Talk to each other and get the work done together.
You could spend days researching the right tool and meeting to discuss the best process to complete the work.
The best way to proceed is to focus on face-to-face interactions with stakeholders, the people who make decisions and the people who build the project. You’ll check in with daily meetings, or daily scrum, to learn about latest progress, blockers, and next steps.
Don’t skip this step, because this is the hard part for some companies. It means you have to trust your team. For managers, that means letting your team do the right work once you’ve come up with the requirements. Micromanaging has no place in agile.
For workers, that means speaking up, sharing opinions and ideas openly, and relying on the rest of your team to do their work the right way. In school, you knew which students you could count on to help with a group project, and you knew when you’d have to pick up the slack. At work, your whole team should be accountable and reliable.
This goes back to other agile principles, that the best teams are self-organizing, with great attention to detail and task management skills.
Welcome Changing Requirements, Even in Late Development.
Translation: Stay flexible with changing or misunderstood customer needs.
Your client asks you for X, and when you deliver X, you learn they really meant they wanted Y. Then they want to add features A, B, and C.
Requirements change. That’s a given for most projects. You need to be flexible to change and make sure changes won’t ruin what you’ve built. Instead of spending weeks building a finished product, sketch it in a few minutes or make a short demo in an hour. You’ll learn more about the requirements with a small sample than a fully completed version. Then you can change strategies or proceed with confidence at each check-in stage.
This is a key principle in customer-centered design, too. Most companies start with a new product idea that takes months to produce and get to market before they get feedback from focus groups and customers. What they could be doing is taking a more agile approach to product design.
Start with a very rough prototype. Draw it, make it out of cardboard, or jerry rig an existing product. It’s okay to get out the duct tape and markers at this stage. Get it in the hands of coworkers and friends and watch how they interact with it. You’ll learn quickly and fail faster before you spend a dime on production and marketing.
There you have it. 4 principles of the agile methodology broken down into simple language for a non-technical team.
Has your team embraced agile? What does your agile success look like?