By Elena Moldavskaya,
Business Analyst, Intetics Inc.
As a business analyst and expert, I have been involved in various Agile projects. However, one of them was so exceptional that made me doubt if Agile is really the best way to manage all types of projects.
The project promised to be a great experience. We worked with a famous company and an innovative product. The team followed the Agile approach to project management and had experienced Scrum master. “Now I have the opportunity to work with the right Scrum. I can learn how to organize the work the best way in a true Agile environment”, I told everyone who asked about the project.
Unexpected issues.
Things went fine until I faced issues revealed itself. The development process was slow and inefficient. We endlessly did lots of redevelopment, which sometimes yielded inaccurate feature delivery.
The expectations did not match the reality. We had serious challenges caused not by human factor but by the improper implementation of the Agile principles. Several clues proved the fact.
Clue #1. Backlog.
We had a huge backlog that would increase over time instead of reducing. Along with that, the team could not determine what is a user story and a task. Defining what is what took a great deal of time and efforts thus negatively impacted the sprint planning.
Clue #2. Stand-up.
We endeavored to follow the rules of a stand-up meeting and do it by the book. We studied a lot, visited workshops, used “special” stickers, used scrum boards of different shapes and sizes. We didour best to make it efficient. However, the road paved with good intentions led us to nowhere. We canceled stand-ups.
Clue #3. Demo.
Rolling out a demo was a challenge every time. 2-week sprint was never enough for that. The product we developed had lots of integrations with other systems. Therefore, several teams participated in the product development thus completing everything on time was not easy. Sometimes preparing for the demo was so time-consuming that we had to stop the development process several days before the demo day.
Clue #4. Retro.
Trying to follow the rules, we held the Retro meeting every sprint. During one of the meetings, the Scrum master used a check-in technique to involve the team in the conversation. He used the “one-word exercise” and asked the team to describe the experience during the last sprint. Honestly, positive word was a rare thing that time.
Expected solution.
Experiencing all these “downs”, we eventually decided to refuse Agile approach with its “ceremonies” and went back to Waterfall. It was clear and usual for the company and the team.
As we did it, things finally fell into place. Just like the development team, the product owner felt more comfortable with the approach and managed to regain the control over the product delivery. Rolling back to basics we successfully released the project and maintained the deadlines.
As seen Agile is not always the best way to manage all kinds of projects. Sometimes it just does not suit the project, company or even the team. So, the attempts to implement it may waste your time and money. However, there are lots of cases, when things went the opposite way.
The bottom line is that first, you should run the analysis to understand whether the methodology suits you. Do not rush into innovations to avoid the fails.
Images by freepik.com
