Enterprise Adoption of Agile Development Will Not Be Easy
Agile software development is going mainstream. It has arrived in major corporations across the globe along with high expectations. This sets up the inevitable – a fall from grace.
My time in the software business is measured in decades not years. I’ve seen many solutions to the problems of building quality software on time. None have delivered on their promises.
In the 1990’s I was a major proponent of the Rational (now IBM) Unified Process even beta testing new releases of the toolkit. RUP was a hybrid of waterfall and iterative approaches. While RUP had many good qualities, it suffered from being too complex and difficult to master.
Agile has gone in the opposite direction. The basic concepts are easy to grasp but suffer from a lack of controls demanded by big companies. Regrettably, this prompts many large firms to blend waterfall and agile techniques. Good luck with that!
Let’s cut to the chase. Software development is risky. Time, money and quality are on the line. Any approach to developing software must attempt to control the risks.
While waterfall works for some, it has an inherent problem of pushing risk out to the end of the project. By the time serious problems are discovered, it is too late to address them and stay on schedule.
Agile techniques have evolved around the goal of spreading risk more evenly across the development lifecycle. The idea is to have development teams admit that they do not have all the answers and will strive to unearth problems, inconsistencies and conflicts as early as possible. But how?
Agile techniques can help mitigate risk but they are not simple solutions and could make things worse if not implemented properly. One hurdle to being agile is defining what agile means. There is no standard definition and there are many approaches. The most common methodologies include Scrum, Kanban, eXtreme Programming, Test-Driven Development, Feature-Driven Development, and the Open Unified Process.
Let’s not forget “Scrum-but,” “like Kanban” and “similar to …” You get the idea. Agile development has decomposed into many variations. Too many. When someone tells you agile did not work for their project it is likely because they were “mostly Agile.”
There are a few things that any approach claiming to be Agile must do.
Early delivery to the business users is critical. By frequently delivering software to the user community, you identify key issues and risks much earlier in the process while there is still time to adjust. You also isolate requirements that may have been misinterpreted or missed entirely.
For any Agile approach to work, the user community must be actively engaged in the effort. Demos and PowerPoint presentations are not enough. They must use the software and provide regular feedback to mitigate risk. The users are not a substitute for QA. They do not have the training and discipline to conduct detailed quality assurance, but their feedback is invaluable.
The need for active business community participation is a huge hurdle to agile adoption. In big firms, the business folks have grown accustomed to telling IT what they want and receiving it several months (or years) later. Software that is often buggy and incomplete is expected. It will get fixed over time, right?
Making Agile work demands constant software validation. The software cannot be tested at the end of the development effort. Testing must be an integral part of the development process. If the software is fragile, it is better to know as early as possible.
Without constant QA testing, buggy software will be delivered to the end users. As the software crashes and hangs, they will quickly become frustrated and uncooperative.
For Agile development to move beyond being a niche solution, major corporations must adopt it and use it successfully. This will not be easy. Additional controls are going to be needed along with more statistics and reports.
Some argue that Agile teams do not need project managers. They will now! Instead of a single master project plan, teams will need a high-level plan supported by a set of more detailed, iteration plans that will change along the way. This will place a larger burden on the project manager and the team.
Agile teams recognize that they cannot get every detail right the first time and will need to refactor some parts of the code along the way. This concept is difficult for many to grasp but important to the success of agile teams. It is up to the project manager to ensure that refactor does not become a euphemism for seeking perfection or adding features. The goal is software that is good enough not perfect.
Management often expects the same type of documentation from an agile project as a waterfall one; process diagrams, requirements docs, functional specs, design specs, test specs, etc. If you were to try to produce such documents for every iteration, there would no time to write the software. Ultimately, what really matters is working software not the supporting artifacts – another new concept for management to embrace.
Any new approach to developing software takes time to get right as the development team adjusts and the business community becomes engaged in the effort. Agile will succeed in big companies- it just won’t be easy.