Why Do We Love and Hate Agile at the same time?
Agile has brought joy to most of us in the software world. So why do we dislike it sometimes?
Working on an Agile project is like a trailer into a movie of life itself. Most developers working on Agile will go through a gratifying and, at times, ordeal experience through the years. We all need Agile to build software progressively. Sometimes we forget the principles behind the Agile Manifesto. Each principle warrants entire chapters in a book. Let's look back at these principles and analyze why we sometimes hate Agile.
What is Agile exactly?
All team members need to understand why we are going Agile in the first place.
Agile enables you to move quickly, easily, intelligently in short bursts, take a step back, review changes, and move effectively towards your product goal. It doesn't mean I write some code for two weeks and change it in the next few weeks.
First myth: Agile says we don't need documentation. Nope. Agile puts emphasis on working software than comprehensive documentation.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
I love this principle because it enables me to work in shorter timescales instead of grinding for months at a time. This frequency can play spoilsport when we uncover hidden complexities with the current task. The fun begins when someone asks us to patch it up and fix it in the next cycle. And yes, there are times we do this.
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Welcoming the change should happen after the aforementioned shorter timescale. Everyone likes it when it's no longer necessary to continue on the code we've been breaking our heads. The downside is when the change is to update the existing code that we just put together the day before. We all hate it when we get a 'critical change' 1/2 days before our sprint ends.
Focus on Product Scope
As a nice person once taught me about life, There are two things in life. Must have and nice to have.
Working software is the primary measure of progress.
The same is the case with Product development. The primary focus should be on the essentials rather than putting 'excellent' to have things out there. What usable feature did we add to the product in the last few weeks? — should be the question to ask.
The developer's satisfaction when adding new working features instead of decorating things is next to none. As a Front-end developer myself, styling is a must to make a feature accessible/usable, but I'm not too fond of it when the whole purpose of my two weeks is styling for no good reason.
Simplicity — the art of maximizing the amount of work not done — is essential.
This principle should be at the center of every product owner's plan. Focus on your product, your core team, and how it helps your user.
Never add fancy things. Keep it focussed and simple. Just because the guy next door did it doesn't mean you have to. It might not work for you.
Agile and the Dev Team
Agile does talk about technology and the Dev Team.
Continuous attention to technical excellence and good design enhances agility.
The best architectures, requirements, and designs emerge from self-organizing teams.
Yes. An excellent robust design helps future proof your application. Conversely, a bad design will bring you to a standstill. A good design and technical excellence take time. Architectures and Design stand tall for a few years only through collaboration with your team. Don't 'draft' something and present it to the devs. At least once in your Agile life, you would have seen this. Someone is presenting draft version v1.0 on the call and finalizing it after the call without incorporating any feedback.
Same Page, everyone!!! If the need arises, try explaining the architecture & Design to everyone ( including the business team ) in layman's terms. Make sure to collaborate, and everyone is aware of the Architecture/Design. You are designing for the future, not the review in the next couple of weeks.
The Human Element
Business people and developers must work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Everyone, Stakeholders, business people, and developers alike, are part of the same team, with the product binding us all. Regular communication leads to better collaboration between the business and the tech team.
The level and timeline of the feedback received also enable the team to deliver a better product. Attend meetings to collaborate, share feedback, and add value. Not provide attendance.
You start losing motivation when you stop talking regularly to your business team/dev team. Eventually, lose track of what the other is doing. We should capture Design flaws, if any, at the beginning of the cycle. End games always end in tragedy.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Most developers have said this at some point or the other. 'We are not machines.'. I remember reading somewhere, 'Ask for a break from your Product Owner.' Nope, you will not get one. A good team will always start small, build pace and hold it as long as possible. Good leaders use 'no.' efficiently, perform due diligence on requirements, and effectively control the pace to ensure longevity.
Customer
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
The highest priority of Agile is to add value and provide a competitive advantage to the Customer or the end-user. Every software does focus on customers, but when you start working with Agile, you get a lot of opportunities to provide the Customer with relevant features/remove their hurdles as soon as possible.
To keep your product relevant in the market, we need to have a way to incorporate changes late in the game. Agile provides that out of the box. The principle of welcoming change gets interpreted according to peoples' needs in the real world. They only like 'change' and 'late' and leave the Customer in the wind. One way or the other, the Customer pays the bills. So respect them. Avoid bringing your fancy pet projects into the fray and think you can scrap if it doesn't work out.
Conclusion
Yes!. Agile makes sense and adds value to your product. But that might not be the case always. Suppose Agile is not adding value to your product; it is time to rethink your approach. Don't give a bad reputation to Agile. Misguided interpretations and miscommunication can break our trust in Agile. Even the certified ones are sometimes misguided or give into the hierarchy. Always look back on the guiding principles and become better agile practitioners.
References
Principles behind the Agile Manifesto: https://agilemanifesto.org/iso/en/principles.html
