Agile, People, Project Management, Software Development

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.


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

About Terry Bunio

Terry Bunio is passionate about his work as the Manager of the Project Management Office at the University of Manitoba. Terry oversees the governance on Information Technology projects to make sure the most important projects are being worked on in a consistent and effective way. Terry also provides leadership on the customized Project Methodology that is followed. The Project Methodology is a equal mix of Prince2, Agile, Traditional, and Business Value. Terry strives to bring Brutal Visibility, Eliminating Information islands, Right Sizing Documentation, Promoting Collaboration and Role-Based Non-Consensus, and short Feedback Loops to Minimize Inventory to the Agile Project Management Office. As a fan of pragmatic Agile, Terry always tries to determine if we can deliver value as soon as possible through iterations. As a practical Project Manager, Terry is known to challenge assumptions and strive to strike the balance between the theoretical and real world approaches for both Traditional and Agile approaches. Terry is a fan of AWE (Agile With Estimates), the Green Bay Packers, Winnipeg Jets, and asking why?


2 thoughts on “Is #agile #sub-optimal?

  1. The benefits of Pair Programming in XP
    are achieved in SST by the rule that Designer (= Black Box Tester) and Coder should be different persons.

    To have four eyes is always better than to have only two.

    Many projects have Designer (= Coder) and then an extra Black Box Tester.

    However, I often saw Black Box Testers who did not have a sufficiently deep understanding of what the software under test should actually do in more complicated situations. Hence I belive that

    Design should be reviewed by an end user,
    but implementations of this design should always tested at least by the designer.
    Drivers for regression test should also be maintained by the designer.
    The end user will do acceptance test only.

    Posted by Gebhard Greiter | September 6, 2011, 10:32 am
  2. Most agilists seem to think that working like hackers is the key to agilty – and so they tend to forget important principles of good software engineering.

    One reason for this problem is the Agile Manifesto itself. It suggests a way to agility that is dangerous (and certainly not the best one).

    So far we only learned that being agile has become necessary. The best way to agility however has still to be found.

    Hence I would like to see the Agile Manifesto replaced by the following two definitions:

    Software Developer’s Definition of Agile:

    Agility means to have a process in place that will allow us (and urge us)
    to react on changing business requirements as soon as possible
    — long before the complete product is ready for delivery.

    Project Manager’s Definition of Agile:

    Agile Project Management means to have a process in place
    that is to maximize team efficiency.

    The question we need to answer is: How can we be agile in this sense without giving up useful principles of good software engineering (especially in a fixed price project)?

    Posted by Gebhard Greiter | September 18, 2011, 3:48 am

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: