“Agile,” as it relates to project management, has been a buzzword for quite some time. Chances are you’ve not only heard of it, but also participated in a project that was run in agile. I was introduced to it about six years ago when I worked at a web development company. A co-worker presented it as an alternative to “waterfall,” the lengthy and roadblock-prone project management style we were currently using.
When introduced, this new “silver bullet” approach was quite intriguing. In design and development, changing requirements from clients can invalidate days (even weeks) of work, leading to unhappy clients, over-budget projects, and frustrated team members. Agile promised shorter delivery times, less time spent defining requirements, more time spent building, and a consistent, workable pace. In short, less wasted work plus happier clients and staff.
We decided to give it a shot, and after a few sprints, we were hooked. We implemented the most popular agile method, called SCRUM, which breaks projects into two-week design, development, and testing cycles. We pre-set client meetings, daily internal check-ins (called standups), and a delivery at the end of each cycle. The idea was this: Our clients would control what we worked on and when, we’d define each deliverable together as we went, and the world as we knew it would be a better place.
We learned that agile isn’t so much the process itself, but a set of principles used to create working processes and methodologies. These include SCRUM, Kanban, Extreme Programming (XP), Feature Driven Development (FDD), Crystal, and more.
The concepts behind agile were defined in 2001 by a group of developers who met at a summit to write the agile manifesto. Their original vision includes four value statements, with the left side of each statement carrying more weight:
Agile is built on the following 12 foundational principles:
Because agencies and internal teams are constantly challenged to do more with less, agile seemed like a godsend. For many organizations, agile was first adopted by the software or web development team, then spread to the design team. As other teams took notice, they developed their own versions, adapting it to their working styles and thus improving their processes.
Switching to agile is not without its challenges. While there are many benefits to working in SCRUM, there are also some serious complexities. When we tried to approach every project with this new methodology, we realized pretty quickly that it simply isn’t right for all of them. Some are too small, or lack the necessary budget. Others don’t have the complexity that would necessitate such a rigorous, open-ended process and large team. And some clients have internal approval systems that don’t allow working iteratively. Here are three of the biggest hurdles we faced:
1. Steep learning curves
SCRUM agile in particular comes with a lot of terminology: Sprints, Standups, Retrospectives, Backlog, Grooming, User Stories, Product Owner, Burndown. Some are self-explanatory, but others need to be experienced to fully understand. It can be difficult for both internal teams and clients when you first start working this way.
2. Lots of meetings
During a two-week sprint period (again in SCRUM) we had 3-5 client meetings for Backlog Grooming, Sprint Planning, Prototype Review, Sprint Review, and a Sprint Retrospective. Plus a daily internal Standup meeting to discuss the previous and upcoming day’s work.
3. Especially challenging for small teams
For organizations that share staff resources across projects and teams, shifting priorities are a given. A set schedule of meetings and continuous project work can be difficult for these lean teams to manage. SCRUM in particular works best when working with a dedicated project team. When handling projects with defined sprint schedules, it can be difficult to run more than one or two simultaneously.
These and other limitations prompted many companies to develop their own unique styles of agile. They adhered to key principles, but adapted the processes to fit projects of varying types, scopes, budgets, and working styles. They stopped trying to work in “pure agile” and started developing hybrid processes. Most of these merged agile and waterfall methodologies to make projects predictable, yet retain as much flexibility as possible.
Now that agile has been thoroughly tried, tested and hybridized, a critical mass of collective learning has given rise to a newly updated modern agile. These are its four new guiding principles:
1. Make People Awesome.
Steve Jobs used to ask his colleagues, “What incredible benefits can we give to the customer? Where can we take the customer?" In modern agile, we ask how we can make people in our ecosystem awesome. This includes those who use, make, buy, sell or fund our products and services. We learn their context and pain points, what is holding them back, and what they aspire to achieve. How can we make them awesome?
2. Make Safety a Prerequisite.
Safety is both a basic human need and a key to unlocking high performance. So we always establish safety before engaging in any hazardous work. We protect people’s time, information, reputation, money, health and relationships. And we endeavor to make our collaborations, products and services resilient and safe.
3. Experiment and Learn Rapidly.
You can’t make people awesome or make safety a prerequisite if you aren’t learning. So we experiment frequently. We make our experiments “safe to fail,” so we’re not afraid to conduct more of them. When we get stuck, or we aren’t learning enough, we take it as a sign that we need to run more experiments.
4. Deliver Value Continuously.
If it isn’t delivered, it isn’t helping anyone become more awesome or safe. In modern agile we ask ourselves, “How can valuable work be delivered faster?” Delivering value continuously requires us to divide larger amounts of value into smaller pieces that can be delivered safely now, rather than later.
At Simon/Myers, the evolution of agile has been a huge help in refining our digital processes. Today, as our project needs dictate, we pull processes from both agile (mostly SCRUM or Kanban) and waterfall, then work directly with our clients to create project plans that fit their budgets, timelines, and working styles.
Interested in learning more about Simon/Myers' agile framework? Check out our ISA Website Overhaul case study.
TechBeacon article, "To agility and beyond: The history—and legacy—of agile development".
TechBeacon article, "50 shades of agile: Software development since the Manifesto".
"Principles behind the Agile Manifesto" on agilemanifesto.org.
ReQtest article, "What is Scrum and Agile? A quick guide to Agile and Scrum".
InfoQ article, "An Introduction to Modern Agile".
The in-aisle retail shopping experience for faucet category products was inconsistent and confusing - making comparisons and verifications difficult, resulting in overwhelmed and frustrated consumers, as well as lost sales.
You wouldn’t shoot a photo before focusing your lens. You wouldn’t shoot a gun before aiming at your target. So why would you execute on tactics before defining your strategy?
Related Featured Work