Agile Development – Boon or Bane?
Software Development Management Consulting (SDMC) is a tricky area of business, which isn’t what it appears to be on the surface, unless one is aware of what one is going to be up against. Projects can turn out to be failures. One needs to work with professionals who understand that making the effort to do things correctly at the outset of the Software Development Life Cycle saves time in the long run!
About half of an SDMC “project rescue” work results in failure, largely on account of how it is managed. “Agile” is unfortunately often interpreted as a green light to throw all discipline out the window – projects run off the rails and nobody knows exactly why. The problem is that it’s in vogue these days to hire the least well-paid resources possible, with the right buzzwords on their resumes, and have non-technical managers oversee them. Managers conduct “success theater” and don’t actually manage the work, since they are not able to.
For instance, one cannot just attend a software development forum to learn about Agile, and then immediately attempt to implement it across the organization as a philosophy. Getting the product out fast is not necessarily the optimal method, rather than making the process of work more efficient.
Reasons for Failure
Management knows what needs to be done to an extent (say build a framework with reusable components), but generally does not actually direct or manage the work, while “Agile” remains obsessively in their dialog.
A certified Scrum Master should be able to figure out if information within the group is held in the form of “tribal knowledge”. It is necessary for each person on the team to poll the other members concerning basic information about how things are done within the organization, and within the group. The Managers need to insist that a common sharing site (e.g. SharePoint) is stood up with quick approval and activation. One shouldn’t end up with a few fixes, when there is way too much to repair.
Management should not be focused strictly on burn-down charts in issue tracking software such as Jira. It may not be burning down at all, since the stories that are getting developed may have been done by Business Analysts (BAs) that may not have the requisite software knowledge. BAs need to insist on putting developers in touch with businesses to get the actual detailed information required, without constant criticism. Managers need to investigate if things are not happening, and cannot simply rely on the fact that the burn-down chart is not going down.
A complete analysis of the entire operation may result in a work plan for gradually cleaning up code and building the component framework, and should be implemented by the team as a whole. It cannot just be opportunities for projects with extremely short deadlines that are artificially imposed by the businesses and agreed to by Management, mainly due to budgetary considerations. A situation should not arise wherein one needs to postpone major infrastructure building until one has more time. Of course, this is the steady-state of most software development operations these days.
In a follow up article, we will cover why Agile itself is not the problem, but not comprehending it clearly is.