Atomic has been practicing agile software development since our inception in the early 2000s. Back then we had to educate nearly every client on agile and its benefits. These days, many of our clients are already using agile practices within their internal teams.
A Quick Refresher
The Agile Manifesto was written in 2001 as a collaboration between individuals influential in the software community. The Manifesto has 12 underlying principles which boil up to the following perspectives, prioritizing:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
These simple statements have guided teams to create successful, scalable software solutions for decades.
As it has become more common, though, I’ve noticed it drifting further from its original intent. Here are two symptoms your team may be falling victim to this trend.
Symptom 1: Too Many Meetings
Scrum has become the de facto framework for implementing agile practices today. At its core, scrum is meant to be a tool for setting priorities, making continuous improvements to the process, and keeping collaboration high.
If the first word that comes to your mind when you hear scrum is “meetings,” then you’re not alone.
There are a core set of rituals that scrum advises, such as daily standup, sprint planning, sprint review, and backlog refinement. While some of these are essential, I believe that small, highly collaborative teams, can be more informal around others. If you are working closely with your small team, you should be incorporating feedback constantly for continuous improvement. Maybe you don’t need an hour every sprint for a formal retrospective. Remember, individuals and interactions over tools and processes.
I’ve also seen this core set of rituals get blown out into a much broader range of activities. Recurring meetings start popping into calendars (pre-refinement, demo prep, etc.). Remember, working software over comprehensive documentation.
Symptom 2: Rigid Deadlines with Prescribed Functionality
There’s a common misconception that agile is the absence of planning. This is simply not true. The Manifesto states that there is value in the “items on the right” (following a plan, processes, and tools, etc.) but that the “items on the left” are valued more.
For a product to be successful, it’s important to have a vision with a roadmap guiding the team from today to that vision. The roadmap should highlight key value adds to the product throughout time. And, the roadmap should be subject to change.
Today, I see many product roadmaps that are bulleted lists of features along with vague delivery dates. You might see something like:
Q2 2025 – Event Management Phase 1
- Event Creation and Editing
- Browse Upcoming Events
- Register for Events
- Personalized Events Calendar
There are several entries like the one above with delivery dates 12+ months into the future.
This is Waterfall masquerading as agile. If the delivery date is not flexible, nor are the requirements, you are not practicing agile.
Roadmaps like this deprive development teams of autonomy. They are entirely prescriptive on what to build, not focused on problems the solution addresses.
They also lack awareness of how software is built. Creating such concrete plans that far into the future limits the flexibility the business has to adapt to new information. Again, this is Waterfall, not agile.
Are there alternatives to agile practices?
I’ve recently become aware of 37signals’ product development method called Shape Up: Stop Running in Circles and Ship Work that Matters. I don’t see Shape Up as an alternative to agile, but a new framework for implementing agile that is closer to agile’s heart.
I have not experimented with Shape Up yet, but I would love to talk with anyone who has. If that’s you, please reach out!