First Reference company logo

Inside Internal Controls

News and discussion on implementing risk management

machine cogs image

Which way is the true Agile?


When I started this article, I was looking for a catchy, colorful image to depict the “Agile Methodology”. After about 30 minutes, I started to realize that my fruitless search was actually confirming the entire basis of my article; that Agile is now being used as just another catchphrase or gimmick to convey that a project is up to date on the latest and greatest in newer methodologies for IT transformation. However, I hope to show you that Agile is more than just a trendy process and is also not “new” per se, despite how on-trend its adoption is in today’s business automation projects. 

The litany of Agile coaches and certification classes may have even surpassed the Six sigma craze. Hearing statements like “Agile our way” or “We pick and choose” has everyone abuzz. The running assumption seems to be that if we have Scrum boards and stand-ups, we’re doing Agile. For those of you who are confused by the hoopla and don’t have the time, or simply just don’t dare, to ask the burning questions; come on a journey with me back to the basics. Together we’ll review the birth and intent of Agile and, in a similar manner to how one might detect a counterfeit, hold the values and principles as our litmus test for when we recognize “Agile” or an “Agile our way” interpretation.

The majority of us were introduced to Agile with the birth of the Agile Manifesto in early 2001, at a ski resort in Utah. However, in his Tech-beacon article, Peter Varhol (Principal, Technology Strategy Research) rightly observed that the pain points which originated the need for a new methodology started much earlier and hit somewhat of a peak in the business industry in the early 1990s. 

“Industry experts estimated that the time between a validated business need and an actual application in production was about three years. The problem was, businesses moved faster than that, even 25 years ago. Within the space of three years, requirements, systems, and even entire businesses were likely to change. That meant that many projects ended up being cancelled partway through, and many of those that were completed didn’t meet all the business’s current needs, even if the project’s original objectives were met.

In certain industries, the lag was far greater than three years. In aerospace and defense, it could be 20 or more years before a complex system went into actual use. In an extreme but by no means unusual example, the Space Shuttle program, which operationally launched in 1982, used information and processing technologies from the 1960s. Highly complicated hardware and software systems were often designed, developed, and deployed in a time frame that spanned decades.”

Imagine, for a moment, telling your board that it will take 20 years to finish your project. To be fair, I would assume that they didn’t really know how long it would take, as they most likely didn’t make these kinds of predictions, and that 3 years was probably the norm for the business at the time. Nonetheless, it became a very expensive and frustrating standard that required a solution and not just in terms of expense. For the IT professionals, there was little satisfaction or real incentive to get to the finish line of a project only to find out that the work was no longer relevant, would not be used as built, or needed to be redone. That’s when 17 software thought leaders, who met regularly, discussed a “light” way of work for software development (the word “Agile” was yet not even mentioned). As my intent is more to explain, from a businessperson’s perspective, how the trend came into being, the basics, and then in my follow up articles continue to dissect the practical application of the methodology, I strongly recommend reading Mr. Varhol’s extensive article for a more in-depth account of the history.

We often hear how Agile has replaced the Waterfall methodology, but in reality, Waterfall still works for many engineering projects, just not necessarily for all software projects in certain industries. From those entrenched in Waterfall, and not really understanding Agile, you may hear “it’s only for small projects” argued in one instance and “it’s better for big projects” in another. Which is it? The now famous 17 were not the only ones coming to the realization that software development needed to be faster. Methods like RAD, Spiral Model, Extreme Programming, and SCRUM Software Development Process were also being developed and used to introduce iterative development.

Jumping back to Utah, the manifesto actually brought Agile into the limelight of the IT world with a public proclamation of what could then be considered somewhat of a hippie movement. Getting right into it, we will dissect the 4 high level values in terms of application from both my successful and not so successful project experiences:

1. Individuals and interactions over processes and tools

I found myself nodding my head in agreement when I heard this value for the first time. Of course, it just makes sense; the individual is the only one capable of being responsive to change and of catching assumptions that don’t quite pan out. It’s also a lot deeper than that because it speaks of interaction, communication, and the ability to not only develop a mutual respect, but to develop trust as well as understanding. This requires a level of vision understanding that makes its way from the Board decision to approve the project down to the teams executing the work (See Value #3). Is this the way businesses spend millions of dollars on “transformation”? Let’s be clear, developing new software for any business is not really a “transformation” but that’s for another article. Do we value the individual facing the customers and users? Do we understand the business and customer needs vs the reality of how we currently meet them? Only individuals can give us those answers, not managers and not project people. They can certainly ask the questions, but the answers need to come from the front-end users and the customers. The importance of a new system should not be determined by which systems get decommissioned. This will never be an expense statement decision only, and if it was, I guarantee that it would be the project with the 0% ROI. It is a company-wide strategic decision that serves all branches of the company in one way or another. Once this information is gathered and a clear vision is formed and understood by the “whole” company. This brings us to individuals on a development team level where this value is crucial. Whether you allow the business to be part of the teams, the elaborations, analysis and team planning, the “individuals” with the proper vision, determined previously, will then analyze and present what can be done and in what time frame. The scope and timing with this preparation and alignment will experience very little fluctuation. What is more important? Understanding the work, agreeing on the design, and having something concrete to test or figuring out who should be talking to who and who needs to be in charge?

2. Working software over comprehensive documentation

 I’ve heard so many interpretations of what this value means; “don’t document”, “document very little”, “it’s Agile, there’s no requirements”. All of which are bogus! This is a software project, there are best practices, Agile audits, and some of the same pain points (scope creep, technical debt, lack of clarity). Of course, we document. Let me try and rephrase this; We try not to build the entire project on paper before we develop anything. Documentation is done in a “language” that the whole team can understand, from the business SME, to the BA, to the developer and tester. The documentation sets the basis for planning, and explains the “why” so the team can analyze and agree on the how. I’ve also heard, “it means putting unfinished items for the end user in the market”, let’s be careful, users need to be able to complete functions and tasks from A to Z, putting working software out there just means some automated features may be missing within the function but it does not stop the user from buying the product, getting service when required and still experiencing the benefits of the product.

I’m hoping you’re starting to see a trend through my interpretations, these values adapt to software or business interchangeably. Just as Agile can simplify bringing new software to a market or users, applying the methodology properly can also simplify how we make business decisions, how we need to be creative and iterative with our strategies, and how we can speed up our problem solving by realizing that in breaking down silos, allows teams closer to the work to align and make decisions. We would effectively stop trying to catch up with the changes in the market and actually be ahead of them. A software, a system can only support and will only be as good as the existing mission, vision, and strategy.

3. Customer collaboration over contract negotiation

This value speaks to the old way of trying to negotiate all changes and the reasons for those changes ahead of the actual build. This boils down to actually betting on how well we listened and understood. How many questions did we ask? How much did we not know the business was changing? How would we have known that this SME did not have automation knowledge or understand the vision? Proper collaboration and elaboration at the start of a project defines the anticipated changes and how they will be handled. When that strategic planning is missing, we waste time and money figuring out what is new scope, a change in requirements, and the underlying reasons etc… Customer collaboration and agreement also requires banishing the ego and concentrating on accomplishing the common goal. Involving the customer/stakeholders throughout the process as a member or members of the team vs providing progress reports.

4. Responding to change over following a plan

Great segue to this value, responding to change over following a plan, no it does not mean we throw the plan out of the window or that Agile encourages no plan at all. I’ve run out of fingers to count how many times I’ve heard this in the past 8 years. It really means that whether the change is due to a business result or a system change that is necessary; responding accordingly in order to get back on track, solutioning together, and putting the business needs first takes precedence over wasting time on discussing “how” it disrupts the plan. 

I hope that this article has given you a practical understanding of the Agile methodology, the reason for its existence, and removed some of the “created” myths that are still confusing those who are new to Agile. It is a powerful methodology when it’s understood and done properly. If you’re building a bridge, you may not need the iterative cycles and you will probably not be able to launch an MVP of your bridge very easily due to all the permits that will be denied. However, if you have a product or service to build and launch, Agile provides the right environment for an optimized, relevant, up to date build and increment deployment with value.

By Gilaine St-Cyr Schneider, Principal Consultant at Reset and Grow

Occasional Contributors

In addition to our regular guest bloggers, Inside Internal Controls blog published by First Reference, provides occasional guest post opportunities from various subject matter experts on the topics of risk management and best practices in finance and accounting, information technology, environmental issues, corporate governance, sales/marketing and operations, not-for-profits and business related issues in Canada. If you are a subject matter expert and would like to become an occasional blogger, please contact Yosie Saint-Cyr at If you liked this post and would like to subscribe to Inside Internal Controls blog click here.

, , , , , , ,

Leave a Reply

Your email address will not be published. Required fields are marked *

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