Agile is not a project management framework. It’s a mindset. The world is littered with certifications and frameworks for how to apply Agile. We are inundated with the message that if we just apply this Agile framework, if we just have that Agile certification, all of our company’s problems will magically disappear. The world is full of consultants who claim to know exactly how to transform your company into an Agile nirvana.
There is no one size fits all for applying Agile. The only people who can decide how to apply Agile at your company is you. Let’s forget about certifications and frameworks and get back to the concise simplicity of the Agile Manifesto.
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
Why Are We Nuts Over Certifications and Frameworks?
The Agile Manifesto is simple to understand. To me, the Agile Manifesto emphases the basic simplicity of just talking to one another, eliminating silos, and empowering people. But people and companies struggle with how to apply this mindset in practice. We desperately want someone to just tell us the how instead of bravely working together to figure out the best how for you.
And so, a whole industry has sprung up around the message, “You don’t need to do all that messy work yourself. Let us tell you exactly how to be Agile.” Methodologies provide examples of how to do Agile. But they cannot make you be Agile. As a result, applying a methodology without the mindset just results in more dysfunction and chaos.
This Is a Company “Doing Agile”
Here’s the typical pattern I see in companies that are “doing Agile” without understanding the why of Agile:
- Someone in a company decides to “do Agile.” The software development teams start doing daily standups and sprints, maybe also retrospectives and reviews. But the delivery teams don’t necessarily know why they’re doing these ceremonies.
- The rest of the company doesn’t know a thing about Agile and still thinks in terms of very large projects.
- There’s a Project Management Office that acts as an intermediary between business stakeholders and the delivery teams. The PMO works in terms of milestones, requirements, and deadlines, which the delivery teams have to translate to something that fits into sprints and stories. It’s a square peg in a round hole.
- The executive team has not bought into Agile. They don’t really understand how to empower people or create a truly collaborative environment. The culture trusts titles, not people.
- There’s a line manager assigned to each delivery team. The manager calls the shots, in addition to doing the team members performance reviews. The delivery team isn’t able to truly self-organize.
- The delivery team feels like Agile is yet another heavy, complicated project management process that they’re forced to endure.
- The people who want the stuff and the people who build the stuff are not the ones who plan work. A legion of other people—executives, the PMO, product owners, product managers, and development managers—plan the work.
- Business stakeholders don’t get what they want because they’re out of the loop most of the time. The delivery teams feel like they’re building software without knowing who uses it or why it’s important.
- This whole project delivery process is heavy, cumbersome, complicated, and wasteful. The process is so overly complex, projects fail and it takes forever to deliver products to market. And many times, people end up blaming Agile.
This Is a Company “Being Agile”
In my technology career, I’ve worked at one company that truly embodied the spirit of Agile, organically and naturally. They did this without subscribing to a particular framework. Ironically, they didn’t call themselves Agile. I didn’t even know about Agile at the time. Here are some examples of how this company exemplified “being Agile:”
- Business people, developers, and users worked directly together. There were no intermediaries.
- Managers focused on creating an environment where teams could thrive. They trust teams to self-organize. There was only mentoring and coaching, no micromanaging.
- Teams were 100% cross-functional, frequently stepping outside of their normal roles to help get stuff done. Everybody pitched in.
- Team members were co-located and communicated throughout the day.
- Everyone understood how their day-to-day work contributed to a larger goal.
- Teams demonstrated products directly to the end-user, getting instant feedback.
- It was safe to try something new without the fear of “failing.”
- Sometimes conflicts arose. That was OK. We talked about it, figured out what to do better next time, and moved on. Transparency and communication was the norm.
- Silos were not tolerated.
- Documentation was lightweight and “single-sourced.” We wrote something once and referred to it often.
- People laughed a lot. We worked hard, too, at a sustainable pace.
Ditch the Certifications and Frameworks and Get Back to Basics
My challenge to you is, stop doing things in your company that don’t make sense. If something feels heavy and like a big waste of time, it probably is. Just because a particular Agile methodology or certification says “you must do this” doesn’t mean you have to. Throw the book out. Reread the Agile Manifesto and the Principles and think about what they mean. Know that there are a lot of other people in your company who are also questioning all of the heavy, convoluted processes. Those people are your team, your crew. Create a culture based on transparent communication and silo busting. You don’t need to be the CEO to make a change, to question and improve the culture. The change starts with you.
What’s one small change you could make today toward “being Agile?”
Editor’s note: This article was originally published on Medium.