WHAT THE HECK IS AGILE?
In the tech world, we’ve all heard the word “Agile” before, but what does it really mean? How is a person Agile? How is an organization Agile? Is Agile just a buzzword or is there some underlying tone of Kool-Aid drinking that should happen when someone hops on the Agile bandwagon? My hope is to explain my perspective on Agile and why it can be a powerful alternative to the traditional management methodology.
AGILE IS A MINDSET
Agile has a lot of powerful opportunities in the world of software (and beyond) but it has been all too often tossed around as the one-size-fits-all solution for companies that truly don’t understand where the real power of Agile resides.
AGILE IS NOT A TOOL, IT IS MADE UP OF TOOLS. AGILE IS NOT A FRAMEWORK, IT IS MADE UP OF FRAMEWORKS. AGILE IS A PHILOSOPHY, OR A MINDSET, OR EVEN A BELIEF.
And if you haven’t figured it out by now, I’m one of those Kool-Aid drinkers. Surprise!
WATERFALL VS. AGILE, AND WHY IT MATTERS
Ok, to give some background I have been in a project management role for about 12 years or so and I have always been in a technological environment (even serving in some engineering roles, but not at a development level). Most of my career has been in a traditional corporate Waterfall (PMP) environment and only in the past 3 or 4 years have I started to get more and more into the Agile arena. Once I was exposed to the truth behind Agile, I jumped in deep.
There is a significant difference between the two approaches in my opinion. Traditional project management is typically a very command and control environment. A project manager is given horizontal authority over the team members on their project. And rather than being an equal contributor to that team, they are a central control point. An Agile mindset flips that dynamic and rather than a “how is my team performing” mindset (serving the PM’s plan); the project manager or Agile Coach has an attitude of servant leadership to the team’s performance (serving the team).
Agile is certainly more suited for my personality, however there are many environments where a Waterfall approach is more appropriate than an Agile approach.
IT’S ALL ABOUT THE MINDSET
Now that you have a little perspective on where I’m coming from, I’m going to try and explain why I believe in Agile so much. One of the projects I’ve had since joining the DT team has been an interesting and challenging one. When I started at DT, my understanding was that we were a strict Scrum house (Scrum being an Agile framework). I worked hard to keep the team following a strict interpretation of Scrum, and though I approached it with the right mindset, I often failed.
That mindset is servant-leadership, and yes this is a current buzzword in the business-sphere... but remember, I’m a Kool-Aid drinker. I wanted to earn the respect of the team that I was leading by serving their needs, as much as I am able to. Again, I failed at this a lot… and continue to. But trying to hold onto this mindset is a core principle of an Agile approach; it is in direct conflict with a traditional project management mindset which is command and control.
THE BIGGEST REASON I LOVE AN AGILE APPROACH IS BECAUSE I HAVE MANY OPPORTUNITIES TO HELP THE TEAM BE AS GOOD AT THEIR JOBS AS POSSIBLE; I GET A LOT VALUE FROM THIS.
THE STRUGGLE IS REAL
We ran Scrum for months and struggled with various aspects of it the entire time. We struggled with estimation, grooming, planning, etc… but one thing I felt we did well were our retrospectives. This is one tool of Agile that I love, continuous improvement through introspection. The one thing we embraced well as a team was change. After all, a mindset of embracing change is at the core of what makes an Agile approach so powerful.
Accepting that change will happen allows a team to adjust quickly and effectively to what the business needs. We continued to come to the same realizations as a team: poor vision of the product, product owners not authorized to make decisions, mid-sprint changes to work scope, and directional changes on a regular basis. We tried a lot of different techniques to adjust for these issues over 8 months and they only ever made a marginal difference. I felt a consistent strain on the team the entire time, and I finally got to the point where I realized (later than I wished) that we needed a framework shift to support both the team (First) and the business (Second) - enter Kanban.
SERVICE TO OTHERS IS THE RENT YOU PAY FOR YOUR ROOM HERE ON EARTH.
KANBAN WAS OUR SOLUTION
Kanban, for those who are unfamiliar, is a lean manufacturing process developed by Toyota engineer Taiichi Ohno to better manage supply chain. Kanban is a just-in-time framework that utilizes a pulling mechanism through a workflow, and it has become the second most popular framework used in software development. I proposed this solution to the team to try and address the issues that we were seeing over time on this project and they decided to move forward. It did away with most of the Scrum ceremonies (planning, review, retro, grooming) except for a daily standup meeting to keep the team in sync.