Welcome back to the second edition of Z to A pulse! In this edition, we plan to nitpick at a widely accepted process that is now gaining popularity as a management fad.
Have you ever been at the receiving end of Are you Agile? Or often go around saying – I work in Agile?
It looks like it isn’t the effortless and smooth process it claims to be.
I recently read an article about how people often think Agile is the suave, quick, and clean transformation that Cinderella had, but often, it is the complex, messy transition of an innocent man to an American werewolf.
So why don’t organizations often see through the flaws of this widely accepted approach?
My name is Sharon Koshy, Marketing Strategist at Zuci and I discuss this in detail with Saifudeen Khan, a Senior Solutions Architect at Zuci and an Agile Evangelist himself.
Let’s get real about – Why Agile Transformations Fail
Sharon: As more companies adopt this pragmatic approach towards product development, what are the basics they are failing to understand about Agile Transformation?
Saif: I have seen that people don’t understand the meaning of it. They feel it’s a shorter waterfall in the guise of Agile. Every project has a phase where requirement – development – testing/validation – deployment happens. Agile is meant to be a shorter sprint, but businesses are now treating it as a shorter waterfall and following the same rhythm of gathering requirements until deployment. This is a primary mistake when it comes to adopting Agile.
It’s a conscious call that businesses must make if the project will work best in the Agile, Waterfall, or Iterative model. Just blindly opting for Agile thinking it will fix all issues is a big blunder.
Sharon: Can a company fully adhere to an Agile Manifesto?
Saif: Agile Manifesto was designed by the founders of the respective processes based on the problems they had envisioned in their circle at that point in time. While it does give us some concrete guidelines, we must remember that each company, project, people, and culture vary. So, every business must understand that these processes must be custom tailored to meet the end goals. There is no one size fits all Manifesto.
We also went through each of the principles and decoded its real meaning:
- What it says – Individuals and interactions over processes and tools.
What it means – Individuals must show ownership; eventually, you will document the stories to showcase what you have done.
- What it says – Working software over comprehensive documentation.
What it means – This does not necessarily mean the absence of documentation, rather documentation is considered a part of working software, and additional time is not spent over here.
- What it says – Customer collaboration over contract negotiation.
What it means – Since there is a shorter sprint, the better the chance to run with the customer and visualize if the business can deliver the ask. This is because the interaction happens more often (once in 2 weeks) as opposed to a traditional waterfall.
- What it says – Responding to change by following a plan.
What it means – Change is inevitable. Agile says that since the team is closely knitted, the change can be brought in immediately. It gives an additional advantage to go back and make the changes in a shorter duration without impacting the release.
Sharon: What role does an organization’s culture play while adopting Agile?
Saif: Culture plays a very important role in Agile. Predominantly the organization does not have much visibility in the traditional waterfall. But in Agile, everything must run from Top to Bottom. The primary requirement I see for Agile to work in an organization is to have the buy-in of the important stakeholders and for them to agree that Agile will bring in some value. Once you pick up a story, you’re committed to delivering it in the two/three-week sprint. If some other priority comes in during the interim, the process will fail unless, as a team, there is a clear sprint planning where everyone agrees to pick the backlog and prioritize it during the next sprint. If the team continues to run on ad-hoc demands, the agile process will stumble.
The second aspect here is – Ownership. A traditional service-minded approach will fail in this scenario. The culture should be one that is driven by ownership where the team realizes the value this will bring to the customer.
Thirdly, keep people informed. If one feels that the timeline cannot be met, it is imperative to speak up on Day 1. This trait should come as a part of ownership in Agile. Communicate from the very beginning so that all the parties are on the same page.
Sharon: How important is communication and collaboration for the success of Agile transformation?
Saif: The moment the team realizes that instead of working in silos they need to break the barriers, everyone wins. The cycle should be such that the developer makes sure the tester wins, and the tester works to ensure the developer wins. This is the height of collaboration that Agile demands.
Sharon: Customer or Technology – what should be the focus when it comes to Agile?
Saif: I don’t necessarily see these as two different things. Sure, the customer is the focus. But a good customer will also understand the technology you are proposing. You cannot build something for the sake of it. A customer does not come with a predetermined technology in mind unless in the case of legacy systems. They will always be keen and open to understanding the technology you’re suggesting as long as it has the advantages they’re looking for. So, there is no fight between customers & technology when it comes to Agile.
Sharon: Some techniques to avoid an Agile Transformation failure?
Saif: Keeping these things in mind should be helpful –
- Awareness of Agile is the bare minimum requirement in the organization. Once this is in place, it’s easier to build momentum.
- I always start with a matrix in my mind as to – who is responsible, who is accountable, who is the consultant, and who are the people that need to be kept informed. This can then be published to the stakeholders, which is a good practice to have.
- Next, it’s the estimation techniques. Agile gives you different methods like poker, intuition, etc. to estimate the efforts that lie ahead of you. It also gives you the flexibility to go back to the resource working on the particular sprint to get the effort estimation, and it’s important to validate their competitiveness. At this point, one can suggest, for example, going with the poker method. The estimation shown by the majority of the poker cards across the table is taken up, and the resources must work in that estimation category.
- Lastly, for every sprint, ensure that the story points, the velocity of the team, and priority tasks, are published to the stakeholders and others involved. This is so that everyone available in the meeting can discuss any deviation or ad hoc priority, and some capacity can be reserved for such tasks before you move on.
People should start believing that Agile is not a one-stop solution for all the problems, it will help you identify problems in the early stage so that you have time to correct them. It then depends on the stakeholders to take the necessary steps.
If you undermine these problems and leave them to co-exist without solving them permanently, you are going to fail.
Question For You:
What are your thoughts on Agile Transformation – would you give it a yay or a nay? Let us know in the comments.
Thank you for reading! Stay tuned with us for future editions where we will be back with an exciting take on other topics about engineering excellence.
Other Interesting Reads:
