The project manager is not keeping up with deadlines, bugs are in every line of code, and the budget is under fire. But don't worry, a miraculous red pill glimmers on the horizon. An agile world in which everything flows like a dream. For those who cannot manage good results in traditional project management, it’s perfect. Sit back as we watch one of the biggest mistakes about agile, in real time.
The dark side of agile development 2/5: Do you know how? YES/NO
Let me start with one cruel truth, so as not to waste your time: if you don’t have capable people on your team, agile (or SCRUM) will not save you. In the previous article, where we pondered the possibilities of developmental methodology, agile’s method seemed to be a free-spirited practice, where even the major deficiencies can be easily hidden.
It may not look like it, but this method has far greater demands on developers and designers than the traditional Waterfall method. Why? People are expected to have a higher degree of discipline, independence, and responsibility.
The orthodox approach to software development management dates back to the times of non-IT project management. The original thinking of the evidence-based decision making process has strong roots. However, some project managers have a dangerous tendency to introduce more and more metrics, KPIs, and quantitative criteria to measure productivity in software product creation. In the end, you can get into a situation where you could have great results, based more on the number of reports delivered than on real-world results.
How to work with agile
The agile method works within short time periods, so-called sprints. Each team member has clearly assigned tasks, and is responsible for submitting his/her part. On the other hand, the Waterfall method uses longer time periods, and so potential incompetence or insufficient skills won’t be discovered till much later. In addition, all activities run simultaneously, and therefore it is often difficult to evaluate specific outputs of individuals. Coordinating the transfer of tasks is also more complex, as it’s usually a large piece of software being worked on.
For example, you plan to deliver a given software package in six months. But over time, you find that three different people have been passing the code back and forth, and it’s too difficult for everyone to fix the resulting confusion within a set time frame. Or, you find that the code is written haphazardly, containing loops and workarounds. In this way, technical delays accumulate and, as a result, the software is more expensive to fix than to write it again cleanly and carefully from the beginning.
So much for the ills of the Waterfall model. But before embarking on major project changes, remember: there is no point in implementing SCRUM unless you have competent employees and clients.
Why you really need great developers, I need not elaborate. But why do I mention the client? Because from the time the project is assigned, the client becomes the owner of the product, and an integral part of the SCRUM team. The client is expected to be able to define their requirements well, and to understand and agree on each step with the supplier.
At eMan, we have skilled people in-house, so we can stand behind and offer the agile approach. And as I mentioned: you can easily ascertain whether we are telling the truth, because with agile, success is easily measurable as the delivered software is functional. So all problem solutions start and end with one question: Do you know how? Yes / No.
On the other hand, the agile method can also be abused and distorted by large companies to suit themselves. Next time we’ll tell you how to know when something is amiss.
Further reading: When Waterfall Principles Sneak Back Into Agile Workflows (HBR)
