Day 39 — Agile series 1/7: “Agile ain’t a method”
What is Agile? Is it about chasing deadline Sprint after Sprint? Or is it having a standup meeting every morning to know who’s doing what? Or is it putting work on JIRA board (or other tools) and closing tickets? Let’s talk a bit about what Agile is and what it isn’t. This post will cover the 4 main topics:
- Introducing Agile
- How we can benefit from true Agile
- Common confusion with Scrum
- How to do it right
What is Agile
Agile is a mindset, a way of working, derived from Agile Manifesto and its principles. To highlight the most common cited points from the Manifesto:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
The idea behind it is to build a learning mechanism in the process rather than having a rigid plan without frequent customer collaboration.
Just a bit of history
25 years ago, when computer technology advanced, businesses saw the value of using software product, and created a large demand of it. However there wasn’t enough talents in software product management nor user experience design. Because of that, the quality of requirement is low comparing to what we have today. To counter that, business analyst tried hard by using Waterfall process for more upfront analysis, but didn’t really achieve the goal. As a result, lots of software project ended up died in halfway.
A bunch of talented developers tried to solve this problem, they gathered and brainstormed and created the Agile Manifesto and its principles. This is when people started using the term Agile, and gradually popularize the concept in the software development industry.
The Impact
What Agile brings to the business world is a new way of thinking process. Before Agile, business relies on marketing data to form their product strategy. There was less product-level customer engagement during the product development phase. What really made Agile popular is the combination of startup trends in Silicon Valley, the book “Lean Startup” (especially the concept of MVP), and the popular methods like Scrum and Kanban.
With the Startup mindset embedded and more customer engagement, companies start seeing the increase of product quality and customer satisfaction.
Benefit of adopting Agile
As briefly mentioned before, Agile tries to drive the product development into the right direction by collaborating with customers. Constant product release is one of the means to end. Other than getting constant customer feedback, there are other benefits of adopting Agile:
- The idea of learn fast and often
- The willingness to fail and get back up fast
- The culture of collaboration instead of top-down
Common confusions
Many learn what Agile is by being involved in an Agile project, whether volunteeringly, willingly, or forced to. Because of the popularity of Scrum, some folks (especially non-tech personnel) have a false impression that Agile equal Scrum or Sprint. What lots of people don’t know is that software development methodologies like Scrum, XP, or FDD, exist before Agile Manifesto was born. Therefore adopting Agile in the product development process doesn’t mean we’re tided to a 2–4 week sprint, it means we need to collaborate more and learn often from the customers rather than focusing on deadlines.
Individuals and interactions over processes and tools. Chasing Sprint deadlines and deliveries is absolutely putting cart before the horse.
The unfortunate factor is that there’s a huge lack of education for product managers and designers to fully understand what Agile is trying to achieve. As a result, they’re still used to the “fixed deadline” mindset from Waterfall process. Some even joke about the term Wagile, meaning corporations claim to be Agile but truly, they are simply using some Agile methodologies without really being Agile (learn fast by engaging customers often).
A major conflict that we observed is the opposition between design and development team. Designers, who emphasize the quality of crafting, requires time & effort to perfect the product. Agile developers, on the other hand, want to release fast to get early feedback. In my previous post, I shared my experience working with designers and developers by strategically adopting different design processes to achieve the right goal, whether speed is more important at the stage, or insights instead.
How to do it right
There are a few things that’d be better to clarify before adopting Agile
- Agile is not a specific methodology, it’s a way of working that address early & constant learning. Overly addressing the process part is the opposite of Agile.
- Scrum’s Sprint is a way to manage tasks and create demo to solicit feedback, however it shouldn’t become a fixed-scope deadline that sacrifices the quality of work.
- Agile team is a self-learning team that constantly change the process and the way it’s working. Agile team includes product, design, and tech. In the realm of delivering customer and business value, the self-organizing team should be given freedom to influence the scope, the process, and the timeline.
I hope this experience share is helpful. Do you have any experience in an Agile environment and would like to share? I’d like to learn from your experience!
ABC. Always be clappin’.
