This guest post is written by Boris Liberman, Senior Software Engineer at VisionMap. He has spent the last 18 years developing systems for enterprise storage, automated trading, and high performance computing.
Imagine you’re given the task of producing a system. The system has already been designed up to the point where your team of qualified engineers is guaranteed to be able to make it. But, given that your system is a non-trivial software system, there is still an element of uncertainty. So you employ Agile.
From the design of the system your team easily divides the whole production process into stages. Each such stage becomes an iteration. Everyday people gather for a brief daily meeting. They report their progress so that you can easily track the progress of the whole project. When iteration ends, the team gathers and reviews their work. At the end, either with minimal slip or even in front of the projected schedule team delivers the project without known bugs. Life is good.
But sometimes, Agile doesn’t always work. Here are three instances when Agile fails:
1. There’s not enough research.
Consider this situation. You have a project that supposedly involves research. The design is preliminary and the team is diverse as far as the engineering and social qualities of its members go. You play by the same general rules. You meet every day, you divide the work into iterations, you have retrospective meetings, so on and so forth.
However, it becomes clear over time that each iteration cannot be completed as a single piece of work. You absolutely have to spend an entire iteration designing the work that will have to be done. During the next iteration you have to get that work done. Now, each design effort turns out to be a bit of research with great uncertainty as to the results and duration.
The outcome of this is either “design to time,” which leads to a potentially low quality/under-featured product, or a project that slips its schedule because the problem turned out to be more complex than was originally anticipated.
2. The schedule (inevitably) slips.
It would seem to me that when correctly executed, Agile provides very accessible means to spot potential schedule slips early on. Iterations are short and people report their progress daily, thus giving the team leader (or another person in the organization who has this responsibility) ability to track the project progress.
However, it takes a mature organization to deal with these issues. The actual complexity of the problem does not decrease because the team uses Agile. As such, Agile does not provide a solution for the situation where the assessed duration of a project is significantly less than the time that it will actually take, making the timeline difficult to follow.
3. Your team isn’t jelled.
Finally, if your team is not really jelled, you have to pay extra special attention to the developers, since under Agile framework the cost of an error can be very significant, due to the very likely possibility that there is a lack of detailed project plan existing before the Agile process kicks in.
The process of “jelling” the team, where people grow to trust each other, understand their team’s strengths and compensate for team member weaknesses, is a very lengthy process. Agile is very much a double-edged sword here. If people on the team are predisposed to openness and are of relatively similar experience, background, etc., the team will jell easily. Otherwise, extra effort has to be invested here from the standpoint of the organization.
Imagine you have two developers who would absolutely not agree to work as a pair, or that you have a developer who is very secretive about their work. It is entirely possible to resolve all these issues, but I don’t think that the Agile process can help here. It is more a matter of how an organization as a whole can jell a team, a process separate from, yet integral to the success of using Agile.
So why bother with Agile?
Agile is a sound set of practices based on common sense. However, it would seem that modern software projects face more uncertainty than Agile can handle with ease. And if true research has to be performed under Agile process, it seems contradictory, because Agile is more of a manufacturing practice. You have to spend your precious time thinking and learning and trying and ultimately choosing just the right path for your project out of a great many paths, and such an activity probably should not be rushed.
Although it is possible to execute an Agile project on time, on budget and with high quality outcome, it is assumed that a great deal of work was done in advance in order to prepare the design of the system. It also requires a really jelled team that can play the notes exactly. Basically, it’s not a one size fits all solution, and while it may work in certain situations, there are times when using Agile isn’t beneficial.
Whether you use Agile or not, it’s never too early to get started. Apply to FD to connect with cofounders and advisors today!