Is #agile #sub-optimal?

I had a comment that was posted in relation to my Solution Driven Development post that took me on a journey of reading on Sunday. It was a comment submitted by Gebhard Greiter.

To be honest, the comment and its references proposed a more rigourous and prescriptive process that what I prefer to see in my Agile projects. (I’m just not sure I’d recommend that the designer is a separate person than the coder) But I appreciated it’s sentiment. Gebhard, like myself, is struggling to find that correct balance between traditional and Agile processes. I commend him for the principle and strength of convictions, even though my preferences in project execution are slightly different than his.

His proposed balance between the two sides of the methodology can be found here:

Comparing two process models for Software Development

There were also some interesting links or sources of information in the comment. The first one was the Principles of Agility 2011. This link then referenced a Gartner report and quote on the potential downside of Agile. I found the entire article that generated the quote and you can read it at the following link:

Agile Development costs more in the long-term

Is Agile Sub-Optimal?

After I read he article, I had two thoughts. One, that the article drew some broad generalizations and perhaps drew some conclusions I would not have drawn. Two, is the author may be onto a small nugget that has been bugging me for a while.

I’ve always been bothered by the lack of ‘project memory’ if I following Agile by the book. If I use User Stories on stickies, Manage via a Kan Ban board, and my retrospectives, application and automated test cases are primarily my documentation at the end, can I answer the following questions?

1. How can I search prior projects for leverage opportunities? Must I read through the code and tests and somehow determine leverage opportunities?
2. How can I review prior projects history for a history of how estimating worked so my estimates can be better this time?
3. Since we acknowledge that I there is never enough time to create all the automated test cases, how do I know if a new requested change is implementing behaviour that is beyond the intent of the application and will cause downstream effects that I can’t anticipate because we don’t have an automated test to ensure its correctness currently.
4. How can I ensure my solutions are consistent across projects if they don’t have high level knowledge of each other?
5. How can I easily have new team members support the system? Do they read the code and the tests?
6. etc….

Active Architecture

I had written a blog post that described my approach to creating Active Architecture Stories as a means to create just enough design documentation so be able to answer half of the questions above. I think the other half can be solved by using one of the leading Agile Project Management tools out there like TargetProcess, Rally, or VersionOne. Any of these tools will allow you to start to build up that ‘project memory’ that can then be leveraged by other projects.

Summary

But the question remains, “Are we sacrificing long-term Enterprise objectives by developing project in an Agile way?” I don’t believe that anyone that argue that Agile is not the best way to execute a project. But I do think that sometimes Agile’s sole focus on value for the project and client may cause us to lose focus on the value the IT Department and the Enterprise requires across all the projects. By its very nature, Agile Software Development projects are silo-ed projects with primarily full-time members and with little governance roles breaking down the barriers between projects.

Sometimes we may need to create documentation that the client does not see value in currently. As professionals we know that there are some documents that will be required in the years following go-live that will pay for themselves 10 fold.

Am I proposing functional specifications? Absolutely not. But I think there is a place for more documentation and some up front design and architecture than is usually suggested. The real question is what documents are required that will ensure I can take advantage of all my re-use opportunities and also be able to efficiently manage the application for the next 15 years.

Perhaps we should also ask those questions when we are determining if we need to create documentation.

Re-posted from http://bornagainagilist.wordpress.com