Birth of #Agile #Agile2014

Reading through all of the Agile 2014 tweets, my memory flipped back to my university years where I consider the seeds of Agile were sown. Although I am sure people at that time didn’t think that was the CASE. (pun intended)

I was taking my Advanced System Analysis course and the final chapter was on CASE tools. If you want a refresher, the wikipedia page is actually quite good.

I remember at that time in the late 80’s there was major discussion/movement on code generation and CASE tools. I guess it was the professions response to all the challenges with Software Development at that time. We had challenges completing projects successfully and within our estimates, so the CASE tools were going to ride to the rescue and generate all the code once we got all the requirements specified. In that way we would remove all the challenges and problems with the troublesome development activities. Which I guess were identified as the problem. If anything, this was the last gasp of the big requirements up front movement. If anything, these CASE tools required even more detailed requirements up front than were required before. A proliferation of modeling tools arose out of this movement to greater and lesser degrees of success. But thankfully none of these tools really provided an answer to the problems.

In my limited use of CASE tools, I was amazed with the amount of work required to define the requirements to be able to generate code. And then it seemed that unless the code was totally mundane, there would always be issues with the code. And don’t get me started on the performance of the code.

Two Solutions

What I thought was interesting was that I saw two solutions arise out of the CASE rubble.

1) Off-Shoring – In the spirit of sub-optimization, this solution followed in line. If we can’t design tools to generate the code automatically, lets figure out a way to ship the code creation to the cheapest possible resources. In many ways, this was a solution in-line with the principles of CASE. We need to create a detailed specification document that we can then take and generate code from,  either by algorithm or people.

2) Agile – although we didn’t call it Agile at the time, the other movement that arose was a recognition that sub-optimizing the development activities was the wrong approach. What we needed was an integrated, cross-functional team, not more requirement documents. We also needed to deliver more frequently to the end client and work side by side with them. This was the absolute opposite of what was typically envisioned with the CASE solutions. In hindsight, I really feel that this was the start of many of the flavours of Agile. (although they wouldn’t officially should up on the scene until years later)


What I find most interesting is when I look back, the CASE movement was all about trying to solve a problem with more and more technology. Which we know hardly ever works. Now there is additional technology that makes Agile solutions possible, but at its heart it is a system with less technology not more. It is about communicating and working together to solve a business problem. Whether we be business people, analysts, developers, or yes, even project managers.

If I only had the foresight back them to buy stock in 3M for all the stickies that the industry would successfully use over the next decades, I would be a rich man.

Rest in Peace CASE, Long Live Agile.



Author: 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?

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 )

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: