Is Agile Development Dead? Confessions of an Agile Mind
ast Friday, I had the opportunity to attend Polar Talks where the topic was Agile Development. However, the members of the panel discussion didn’t glorify the agile approach. On the contrary, the moderator posed a rather provoking question time after time:
Is Agile Development bad?
I cannot give you a straightforward answer to this question because there isn’t one. What I can do is reflect the discussion that took place between the representatives of the IT community last Friday. You can draw your own answer.
Mile Zajkovski is a senior developer in Singular Skopje with more than 8 years of experience with Scrum. I did a brief follow up interview with him to dive deeper in the flaws of Agile Development.
Agile development does not solve all problems, but it helps in their early discovery. — says Mile.
However, whether the emerged problems are addressed properly depends on the team, the scrum master and of course the product owner. In the end, developers may end up with an easy solution that solves the task at hand quickly, rather than the best approach that takes longer to build.
The tension to complete as many tasks from the Product Backlog may sometimes take the focus from the big picture. Wrong estimation of time and effort may be one source of the problem.
EM: Do story points help with better estimation?
MZ: Story points have their place in story estimation. In the early stage we still don’t have all necessary information about the story. We don’t have the complete description, design, work breakdown, acceptance criteria etc. At this time we do estimation with story points. This is a rough estimation technique. It saves us from the unproductive discussion whether it will take us 22 hours or 26 hours to finish it. At this point we don’t know. But from previous experience, we know that it is around 5 story points.
In theory, the agile development should perceive the problems before their occurring. One of the goals is to prevent bugs rather than fixing them. However, the pressure for delivery in each sprint is a huge stress generator and may cause teams to report unrealistic progress to their clients.
EM: Do we build the architecture before the first Sprint?
MZ: Creating the architecture is a complex topic that requires a discussion on its own. The general guidelines say you need to have some architecture in place before you start the first sprint. But the most important decisions will come as the problems arise. The design proposals that must be tested in order to be proven and accepted. This task is like any other task and can be done in every sprint that requires it.
In addition to the pressure to get as much done in a single Sprint, we have the impatient clients with their unrealistic expectations. The discussion highlighted the importance of keeping clients in the loop. It is crucial that they truly understand the agile approach. Even more important, not letting the pressure for fast delivery hurt the product. Bottom line, the conversation with the clients about potential delays in delivery are uncomfortable. However, they are absolutely necessary for a quality output.
What to expect next?
When we look back to how the development methodologies have evolved we realize that a methodology becomes obsolete after 15 years of its first appearance. Given that the agile approach surfaced in the IT community for the first time in 2001, we can expect some disruption in the field. However, the discussion rested that although not perfect the agile methodology will prevail the development field for couple of more years.
