One question I often get asked when speaking about agile with others, especially when they don’t work in IT, is “Who can learn agile? Is it just for software developers?”
Agile started out as an approach to managing software development projects. However, its principles and practices can be used for any project and in any industry. Agile is all about starting simple, working in small chunks, and seeking out feedback early and often, so that you can continuously improve and course-correct along the way.
In my professional experience, I have seen a fair share of agile use outside of software development. That includes in-house legal counsels using agile and working in cross-functional teams to manage different aspects of compliance for their organizations. Human resources departments using the Scrum framework to manage change during reorgs. And marketing people building up new touchpoints and marketing campaigns to engage customers.
This is what I love about agile: it’s a simple set of principles that you can use to work in an iterative and incremental way (I’ll show you exactly how this happens in the next section of this post). It’s not prescriptive. Neither is it technical. It’s simply a way of planning projects out and making things happen by choosing action over inaction and welcoming change and disruption as they happen.
Here’s how anyone can apply agile principles in their life and work, today:
- Always focus on creating value, whatever value means for you, your organization, your customers, and your stakeholders.
- Make choices that lead to doing the right things, getting efficiency gains, and achieving competitive advantage. Prioritize important over urgent work.
- Work in small batches and ship outcomes frequently. Seek out as much feedback from humans and insight from data as you can. Learn lessons and course-correct.
- Discuss the things that matter most and collaborate on turning them into reality. A decision- and action-oriented 15-minute conversation is often more valuable than a 300-page document.
- Agree on the “Why” and the “What.” Then hire (or contract) smart people and let them figure out the “How.” Micromanagement has no room in agile because it prevents you and your team from delivering value.
- Pay attention to doing things well today. Identify ways to do things better tomorrow. If you keep on making small changes that make you more effective and efficient every day, in one year they are going to pay solid dividends.
- Keep your plans simple. Have a vision and a strategy, but let them be grounded in reality, focusing on the real problems, and supporting long-term solutions. Keep your plans and roadmaps lightweight and up to date. Welcome change along the way.
- Reflect, reflect, reflect. Set reminders in your calendar every week, month, or quarter. Then get together and have an open conversation in a safe space: “What are we doing well? What can we be doing better?” Encourage everyone to participate and pick up action items so that, next time you reflect, they’re proud of the change they made.
This, more or less, is my interpretation of the 12 principles of agile. As you see, you don’t need to code to use them. You don’t even need to know how software works. Take them, try them out, make them yours. Agile is all about small methods and big outcomes. Like a dance or game, everything else is about moving aptly and staying in sync with your environment.
What Is Agile Project Management?
In 2001, 17 software development thought leaders got snowed in at a ski resort in Snowbird, Utah. Since they couldn’t ski, they started talking about how each of them work with clients and built software. Finding a surprising number of similarities between their ways of working, they put them down on a whiteboard and created the Manifesto for Agile Software Development.
They chose the word “agile” because it meant “to be able to move quickly, easily.” At the time, most software projects were managed with what is known as the waterfall methodology. Most software development projects started with a months-long analysis phase where requirements were rigorously collected and a detailed project plan was made.
The project plan outlined every single task and sub-task that had to be done from start to finish, along with who should do it, when it should be done, and how much it should cost. After months of analysis and planning, the development work would finally begin, followed by testing, then followed by release. It would then take a team of programmers several months until the big day came and their software was ready for customers to use.
Despite the best effort of companies to keep their waterfall software development projects on schedule and within budget, most of them came out as complete disasters. Some took years to complete. By the time the software was ready, it turned out that the wrong thing was built or the original thing was no longer needed. Others didn’t meet customers’ expectations or solved the wrong problems, taking just as much time and money to rework after the big launch.
Successful software projects, it turned out, were as much about experimentation and discovery as they were about analysis and design. The problem was that the project management methods at the time were simply not leaving room for this.
The agile movement gained ground among software developers in the early 2000s, giving a much-needed alternative to the prescriptive and deterministic ways of waterfall.
In its purest form, agile is all about working in an iterative and incremental way. Instead of planning out every single task and dependency within a project, an agile approach focuses on setting a structure in which to iterate.
Here’s how this typically pans out. Say that you have an agile project to build a mobile app. You have a budget of $120,000. Your average cost of labor is $50 per man-hour. This means that you can afford a team of 5 people working for 3 months (20 days/month, 8 hours/day).
When you use agile methods for your project, you don’t try to predict everything that you’re going to do in the next 3 months. You don’t even know how it’s going to end. You only know that you have a team of 5 people, working for a period of 3 months, on a mobile app.
Some of you who are not familiar with agile methods will say that this is extreme. But agile is all about acknowledging the fact that you can’t tell the future. You can only take one small step at a time, continuously improving your approach and course-correcting as necessary along the way.
Instead, you set a structure. The team is going to work in two-week iterations. So they have 2 iterations/month, or 6 iterations in total until the project ends. The team has a conversation with you to understand your vision for the app and what needs it should solve for you or its users.
Then, they roll up their sleeves and get to work. In two weeks, at the end of Iteration 1, they show you a demo. They’ve created a first version of the app that you can download on your iPhone and test. It only has a home screen, but with an early UX design and 2 features.
You share your feedback with the team and they talk with you about what is most important to build next. Off they go, designing and developing two new screens and 4 new features for the app. At the end of Iteration 2, you have a working app with 3 screens and 6 features.
At the end of Iteration 3, your app is ready for early adopters. You make a website, invest $5,000 in ads, and get 100 beta users. You continue working with the team in the same way until Iteration 6. By then, you have a mobile app with 5 screens, 14 features, and 30 engaged users.
The three months are over and the budget is spent. You have a mobile app with working features and first adopters. You can then take a strategic decision about what to do next. Maybe you could keep the app as-is for now and invest in advertising, acquiring more users. Maybe you can use the feedback from your existing users to improve the app in a subsequent project.
You tell me what you would do in this situation in the comments below. No matter what your answer, you now know what agile software development is — and how it works.
Does Agile Work Outside Software Development?
An agile approach to project management can (and very often does) work for non-software projects. Some of the most popular uses of agile methods outside software development include the US National Public Radio, John Deere, and Saab.
One thing about agile that often surprises most people is that it draws inspiration from the lean manufacturing movement from post-war Japan in the 1930s. Lean manufacturing started when Toyota Motor Company introduced a new way of management and work for its factories.
Called the Toyota Production System (TPS), this way of work focuses on eliminating waste from a plethora of non-value added activities that manufacturers did at the time. Toyota came up with a “leaner” way to produce cars without producing excessively or keeping unnecessary inventory.
The concept of continuous improvement in agile comes from kaizen in lean manufacturing. Kazen is Japanese for “change for the better” and consists of five founding elements: teamwork, personal discipline, improved morale, quality circles, and suggestions for improvement.
Sure, agile originated as a movement among software developers. But from day one, it was grounded in principles from other sectors and occupations. Perhaps this is why the agile principles and practices can work just as well outside the IT function.
In 2007, US farming machinery maker John Deere started experimenting with agile. In 2010, John Deere had a product launch set for January 2011. Behind schedule, the team realized that the launch would become a flop unless they radically changed their ways of working.
So John Deere went all-in on agile for this project, broke down functional barriers, organized into agile teams, and introduced Scrum, the most popular agile framework, to 150+ people. The product launch was a success, and the tractor maker stayed on its agile journey. Today, thousands of John Deere’s employees practice agile.
The US National Public Radio (NPR) uses agile methods to create new programming. The last time NPR did a waterfall-like radio show launch, they invested $2 million in the Bryant Park Project, a show aimed at young listeners that got canceled in 10 months.
In 2012, NPR looked into how things were done in the world of software development — and started using agile methods to quickly and cheaply launch new radio shows, test them out with their target audiences, and decide whether to invest in or discontinue them.
Swedish defense & aerospace giant Saab uses agile and Scrum to build fighter jets faster, cheaper, and better. Over time, the company created the Saab Agile Framework, which combines practices from lean, Scrum, Kanban, Extreme Programming (XP), and others.
The agile practice at Saab focuses on enabling teams to continuously improve their performance. The goal is for every Saab engineer, every day, to carry the highest-priority task with the least number of distractions and obstacles. This creates an environment of clarity and commitment.
In Conclusion
No, you don’t need to be a software developer to learn agile. Agile is for everyone.
As long as you keep your rules and methods light, focus on doing the right thing well today, and keep your eyes and years open for how to do it better tomorrow, you’re agile.
Have big and bold goals. Keep your plans simple. What’s more important is that you stay disciplined in taking action and achieving excellence along the way.
For all the rest, you’re going to learn plenty of lessons and get feedback from others that help you course-correct on your journey — no matter what geography, industry, or field you’re in.
