Living that Agile life at WWC

Unless you’ve been living under a rock, you’ve at least heard of IT shops going Agile. It’s been the hot “new” thing for the past ten years it seems. Scrum, Kanban, Lean, SAFe, LeSS, etc are all different frameworks or ways to implement Agile. There are as many different frameworks as there are companies. There’s a new flavor every week, and everyone wants to try it.

At its heart, Agile is based on 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.

Fairly straightforward and to the point, right? But it also leaves a lot of room for interpretation. That’s where all these different frameworks come in. Each framework is a group of people’s interpretation of the manifesto and how those values can be achieved. The frameworks are a handbook on how to “do Agile”. Entire sub-industries of Agile certifications and trainings have exploded over the past few years, with promises of making you and your organization the most agiley Agile team that Agile has ever seen. Except, I don’t think you can do Agile. You either are Agile or you are not.

Agile State of Mind

Agile has been and will always be a state of mind. It’s not something you do or a thing you have. It’s more about how you approach your work, and hell, life in general. You’re either flexible and willing to reflect and adapt….or you’re not. You are open to feedback and continuously incorporate that feedback into your day to day actions and behaviors. It permeates everything you do – it’s the attitude you approach things with. Agility is a state of being that you’re trying to achieve. This is one of the reasons why so many other industries outside of IT can and do adopt Agile thinking to their way of working.

Prescriptive vs Going with the Flow

In my mind, it comes down to how prescriptive does your organization or team want to be in your software delivery. Note that I did not say prescriptive in your Agile implementation. I am a firm believer in non-prescriptive Agile. Meaning, I lean heavily on the Individuals and Interactions part of the manifesto, and not so much on the Processes and Tools. Yes, I am a Certified Scrum Master through the Scrum Alliance. No, I don’t only do Scrum, nor do I expect that from my teams. I like my teams to pick and choose what works best for them and their current project. I want my clients to know they have a voice in how their product vision is executed. It comes down to what works best for that group of people at that particular point in time. It may shift and change – that’s ok, we adapt. I believe that going your own way gives you more success as a team. I’ve seen it both in large and small organizations. Teams that are successful are teams that figure out how they want to work together; they take the parts they like best from Scrum, Kanban, Lean, etc and mix them together to create their own secret sauce. The common thread here is a group of people taking ownership of how they want to work and having the conversations of ‘hey, let’s try this’ or ‘what if we did this?’. When I look at the qualities of successful Agile teams or companies, I see several common traits: flexibility, autonomy, proactive communication, transparency, adaptability, and potential to achieve a state of flow. Sure, frameworks can teach us how to sharpen those qualities, but telling someone to start being adaptable usually doesn’t go over so well when they’ve spent half their career following strict processes. (that doesn’t mean I think processes are inherently bad!) Telling a team to go “be Agile” is like telling someone who is upset to calm down. Yeah, you know it’s what needs to happen, but it’s not constructive and doesn’t help you get there.

Following a framework that promises to get you Agile is akin to forcing yourself to meditate because you heard it’s relaxing but you’re so focused on how to meditate, you lose sight of the relaxing part. A state of Agility is like being in a meditative state- you’ll know you’re there when you get there and it’s not a thing you can force. There are a ton of techniques you can try to get there, and a lot of experienced people that you can learn from along the way. But you (and your team) have to figure out what works for you.

Being not Doing

At We Write Code we try to strike a balance between defining useful processes and standards that could apply to all teams and clients. We have the knowledge and experience of all different flavors of Agile, and from our collective experiences we decide what works best for our teams and clients. We have the conversation on how we want to work. If something isn’t working, we bring it up and change it. We’re transparent with our teammates and our clients throughout the entire development process. We want to enjoy what we do and we think that shows in our work. Heavy processes and strict frameworks kind of kill that vibe. We add structure when we feel pain or take it away when it’s no longer needed. It’s definitely not a “typical” Agile journey.

What’s your path to Agile look like as a company? As a team? Are you following a manual or doing your own thing? What’s working and what’s not? We’d love to compare notes and resources to help you on your journey to Agile enlightenment!