In the first part of this moderate indictment of the agile application development process, the general argument was how it came to dominate the development landscape and change the methodology from the disciplined waterfall method in the name of speed. The question is then at what price speed? No one, especially the business weenies, a.k.a product owners, would argue the value of shortest time-tomarket objectives in our ultra-compressed world of technology delivery. That said however, it is not without sacrifice in other critical segments like usability, supportability and that other neglected factor of customer satisfaction.
When the scrum master fires the starter pistol to begin a new app development, the agile programmers race to their open pit workstations, sip some low-documentation Kool-Aid, fingers poised to code, but code what? There is no product design. There is no technical specification to guide the creation of the app. There is no architecture on how to connect the disparate features to work together. There is just a general overview of what the app is supposed to do and maybe a feature list with scribbled notes on an index card or cocktail napkin. This is the first way that “agilers” save time.
The next timesaver comes in the form of sample screens or wireframes that illustrate what the app will potentially look like as well as how the user will interact with the app. This is very useful to the stakeholders to envision what the usability of the app, however it can lead to false expectations about product readiness. It also acts like a “wish” screen for them to add or change features during every sprint cycle. This is both a blessing and a curse. It ‘s a blessing when the features are added, but a curse when the final delivery and payment date never comes.
One of the threats to agile time saving is the dubious Agile Manifesto principle of “Welcome changing requirements even in late development.” Anyone that has ever dealt with egotistical developers knows that this is the equivalent of taking food away from the alpha sled dog at the Iditarod after the race. No one under any circumstance welcomes changes late in the process. No one wants to hear those six dreaded words “it’s great, but could you just… If a project is dragging on (as many agile projects do) good programmers get bored and want to create the next best thing. Without a clear statement of work up front, too much collaboration with customers/stakeholders leads to feature creep and can derail the project entirely. Agile developers are great project starters but often lousy finishers because there is no end in sight.
The most profound timesaver is the genuine lack of documentation from start to finish. No project plan, no design plan, limited code documentation, and minimal feature/function documentation. And by the way, who needs end user documentation? On a recent project, a top notch developer emphatically stated the “we don’t need documentation because we are agile!” Many coders take shortcuts on documenting their code because they believe no one else will ever review it.
Guess what? They change jobs, the code survives (think thousands of Windows 95 installs still in place), and the customer wants updates. The next developer has to sort through the source code line by line to understand the logic.
The end user is usually the biggest loser. They receive software that has little or no documentation to illustrate how the new features can make them more productive. They will be told that the application is intuitive and simple to use. If they are lucky, they might be directed to an online Vimeo cartoon that shows them how to use it. This also shows them that the software vendor doesn’t think much of their intellectual acumen, as cartoons are the only way to teach them. Moreover, end users become veritable lab rats forced to test endless updates that often fix one problem and create several more.
Hmm, I wonder if agile development is truly fast or is agile simply a synonym for lazy?