The Meaning Of Agile
Caveat Emptor
Having spent almost two decades in the financial services industry, mostly in trading and banking, I wanted to share a few insights and learnings I have discovered along this journey. Especially as it relates to software development and what I found are some ways to maximize the most productivity and best value out of product and engineering teams.
I intend to have this be a multi-part series. I am not sure how long it will go, but guaranteed there will be follow ups!
Before I get into the observations and eventual best practices, I must caveat that every situation, company, culture, product and team are different. There is no cookie cutter process that one can just lift and transplant. In fact, even within the same company there will be minor tweaks and restarts along the way to ultimately achieve the best outcomes.
That being said I welcome feedback and fully admit that I am still learning everyday so what I say here and propose are my views alone and can adapt.
Back To Basics
Going back to the title of this article - The Meaning of Agile. I wanted to first set base expecations. I am not this Agile zealot that believes one framework is the one to rule them all.
Srum, Kanban, Scrumban, SAFe, Scrum of Scrums, Spotify Model, PRINCE2 Agile, XP, Lean, Test Driven Development, Design Driven Development, Behavioral Driven Development, the list goes on and on. Apologies if I may have missed the particular SDLC process you are currently using, but it seems like a new one pops up everyday.
Some of these process I know very well, some are still very new to me, but all were created to try and improve the software development process. I know a number of these practices have been extended to different areas and industries, but I want to stay focused on the original intention - creating great software.
The Original Manifesto
The original Agile Manifesto can still be seen on this web site to this day.
The manifesto was written in 2001 by a number of prominent software engineers and architects who yearned for a better way to develop useful, working software. It was created on four values and twelve principles. The four values are:
In fact you could further distill these down into:
领英推荐
Now to further reduce these into five key words: (so you can remember)
Over the years an entire industry was created in Agile frameworks, consultants, coaches, trade groups, conferences and certifications. So I can see why when someone says "Agile," they are utterly confused as to what it actually means.
Isn't Agile Just Sprints, Points and Standups?
I would guess that 9 out of 10 people in software development would equate Agile to be Scrum. Specifically Scrum ceremonies. Yes Scrum is an Agile method, but it is not Agile itself. This is the most common misconception and unfortunately why we have seen a growing backlash on Agile. Mainly because some of these practices go to the extreme and by just ruthlessly following a set of prescribed processes teams and companies believe they are doing Agile.
One of my favorite practitioners in the software development space is Jeff Patton. I highly encourage you to watch some of his videos, or even take one of his classes. He distilled the process of software development into a few simple steps.
That's it you say? Yup...Pretty much...That's Agile in a nutshell.
Agile Won't Work For Us
So I go back to my very distilled Agile values and cry a little everytime I hear someone say "Agile won't work for us..." What they are really saying is that interactions, working software, collaboration and adaptbility won't work for us. Obviously, that's a pretty big extreme, but that's the connotation.
One example I would like to give is SpaceX, love Elon or hate him, SpaceX has done some remarkable things in the research and development of rockets. Guess what? They use Agile principles. Remember when the Falcon 9 rocket(s) exploded? They used that "failure" as a learning opportunity to iterate and do better the next time. Sound familiar?
Now, you can imagine that a mistake by SpaceX could mean someone's life. I would argue that's the biggest risk for failure for any type of software development project. Does your new chat application or wealth management software have more on the line than someone's life? To me, it is clear what the answer should be...
If you read this far, thanks for sticking around. I promise in the next article there will be a bit more humor and tangible nuggets of information that can help you in your product development journey.
But for now, please leave a comment and let me know what you think!
Insightful! I think keeping a tight iterative cycle makes a huge difference. This means doing frequent releases, which can be a challenge to large financial institutions, which i think why many just stick to only the rituals.