Why can’t we work in an “Agile” way?
Many software builders and companies, especially for startups,
“Release a product, test it, find problems, fix it and run it again and again in a rapid cadence”
can be the most important to survive. that is why the concept of “Lean Startup”, “Extreme Programming”, “Agile Methodologies” have been emerged and many product teams and even business teams are trying to apply those methodologies.
Despite those good methodologies and practices, I have got a question about,
“Are we really running Lean or Agile?”
to figure that out, we all should look back to check out how we have been worked, and how does that really fit in the agile methodologies’ core concept.
While I work as a project and a product manager for five years, I have experienced, interviewed, and listened to many engineers, designers, and product(project) managers complaining about the Agile methodology, and found the common process and consequences of their(and my) “Agile Practice.”
- Focus more on “features” than the “user needs”
- Try to “make faster” than “find the most important value point”
- Not explaining “Why it is important to do” now to the team members
- Stressed by “set deadlines” without proper discovery and planning
- Invisible pressures between the reporters and assigned for unsynced work process
- A bleak atmosphere all over the place and pleasant conversation is gone away
And by updating the product, those vicious circle runs on and on and led people to leave the team and let them frustrate about the Agile practice.
To begin with, That is NOT AGILE or any other methodologies.
No one wants their co-workers to suffer from making the product and no software development process make product suffering from it. So from now on, I will talk about
What is Agile’s core concepts & What should be considered to run LEAN in the very beginning
1. If there is no USER, the product is nothing.
As the book “INSPIRED: How to Create Tech Products Customers Love” said no matter how you work hard or add new techy features but if the users do not use the product, that is a huge failure.
Agile process’s primary goal is to let the product or the product team increase their “agility.” However, beyond that point, you need to know the user first.
As we know the user as possible, there is less chance to lose the opportunity to deliver the product in the beginning and that is the real starts of the Agile practice.
2. Start with what the users really want to solve.
Based on the research, only 16.2 percents of the product are completed on- time and on-budget. Why do you think it happened? Because it has been over-budgeted and failed to look over the user interactions.
While I was learning about how to build the product rapidly, the second thing that I have learned is slicing the “full” integration into many many slices.
We all know that “do-it-all button” can dramatically increase the fidelity, but we can still release without it and learn what the users really think about. And that is why the Agile process emphasis on release fast and learn from the release.
3. Deploy a small chunk continuously and rapidly.
As we chopping the tasks properly, we can deploy in many times watching users reactions and feedbacks. In the development side, it can help the product to de-risk risks such as technical debts and dependency issues.
As deploy time is longer and longer, the risks on both user side and technical sides are uprises dramatically.
User side: product team can make the product unwanted way and may late to go back and lose the time when the users really want to use the product.
Technical side: many conflicts and technical debts are not showing until the deploy to the user and the more complexity that product gets, the more time will take to take care of the legacy.
Continuous deployment can prevent it from the risks by checking the code status and user feedbacks at a rapid pace.
4. Software development is more likely to the marathon than the endless sprint.
While people talk about the Agile, people are obsessed with or get pressured to strict to the “sprint cycles” or “# of iterations” they have gone over. However, do you think the “process” is more important than the “people”?
Since agile’s core concept is rapid and constant release and evaluation, product team’s development cadence, and velocity can be the important factor.
We all know that setting expectations and time planning is important, but that should not interrupt the working environment and harm the mental status of the product team members.
The reasoning is simple. When one of the team members got stressed and it goes over the line, the team need to find new member and coach. If that member has almost all of the domain knowledge about the product or technical language is not general, it gets worse.
That is why the team- retro, and post-mortem exists. Doing such activity can help team members talk about any issues that they have got into, and talk about the hardships easily. the more talk the team members do, the more transparent team will be built.
Next time, I will show the bad-case of agile practice and explain how- to resolve and what should we think about based on that case.
Thanks for reading and will get back to you soon! and please talk to me if you have same/opposite idea of mine.
p.s. I am really not good writing in English, so feel free to let me know if there are any words that do not make sense anytime! :)
- This article is translated by my article in Korean at the Brunch, a writing platform in Korea.
- Inspired book link: Amazon
- Survey result for IT project success rate: The Standish Group Report Chaos
