Is an agile process possible without agile software?

By | Jul 15, 2018


What is this buzz word, Agile?

When we think agile we think of software processes and being able to change the direction of R & D or a project at a rapid pace to allow for the customization of software or the development cycle to provide rapid software features to a client through the act of software development but is that truly how people practice it and does it work?

The article that follows is a bit long but try and read it and understand it and let me know if you disagree with any of my points.

So what does it mean to be agile?

Let start off with a look at the agile manifesto. Agile is not a process and its not even a methodology to develop software. Some companies try and make money from the buzz word by creating processes and standards around it and they sell courses and certifications relating to their process but to be agile is a way of prioritizing some values more than others its not a process. It’s about being flexible.

Some of the key values of agile are:

  • Individual and Interactions over processes and tools. – In short anyone should be able to stand up and walk to another individual and ask a question instead of having to following a process and wait for the predetermined time.
  • Working software over comprehensive documentation. – So what this means is, instead of going through a design phase and producing  all the types of documentation known to man, i’ts more important to have working software in the end. This is where many companies throw the design phase out completely and miss the plot.
  • Being able to respond to change vs following a concrete plan. – This basically follows on the value above. Instead of doing a full design only do enough to get going.

So with these values in mind you need to find a balance – where you do a little of the one and more of the other.

The question should also be asked, should a company even be agile? Not all companies need to be agile.

  • If your company is producing software that is packaged and sold to customers then waterfall is a better process for you.
  • If you have a slow release cycle then chances are waterfall is the process for you.
  • If you are your own customer then chances are agile is more for you.
  • If you support a live software system and push out new patches to it daily / weekly then agile is more for you.

Can you achieve agility through a process?

Something I find amazing is that we try and follow a process to produce agile software…

This is an interesting thought… The company can be agile by following a process? A process is rigid strict set of rules and procedures…isn’t it?

This is something that many many people don’t understand. When you are following an agile process you are allowing for the people doing the process to be agile, so they can change direction quickly. This however does not mean your software is agile, and you can not be agile if  your’e software is resistant to agile.

Casualties of agility

Anyone that are honest with themselves will agree that in most software houses, agility is often synonymous with cutting corners to gain speed and does not have much to do with changing requirements.

We will come back to fix it later, be agile… does this sound familiar?

Some casualties of agility are often the phases ‘planning and design’ this means that we no longer have any analysts or architects in software houses as design and planning is bad…we can’t afford to have them as they slow things down…and this is where 90% of software companies miss the plot.

Even if the process make provision for design the step is skipped or applied as quickly as possible to get to the implementation phase to try and speed things up. Once the software is delivered and the client changes his requirements the developer and the process may be agile but how does your software handle the change… it usually doesn’t and then you end up with a patched system that looks like this.

Initially the system above is easier to make changes to but as the system grows it is easier to make mistakes and it becomes impossible to estimate.

Would this not be easier to work on?

By removing the analyst and architect from the process the integrity and cohesion of the software system is sacrificed in the pursuit of speed and thereby the risk of breaking something within the system increases. Something that many companies miss is that agility is born out of engineering and not out of a process or sacrificing integrity for the rate of feature delivery.

Agility through the act of engineering.

Software systems need to reflect the requirements and values of a company. In the same way that physical objects like mobile phones, motor vehicles were designed according to requirements.

If a company needs to design a mobile phone with the requirements of being water proof then it will be one of their primary requirements during the planning and design phase before the design is sent to the factory to be produced. Do you not agree? No manufacturer would try and add water proofing to their phone after it has been constructed. In the same way if you want agility in your business you need to design for it in your software – it is not something that can be added on later as an after thought.

The only way to be truly agile is to have a highly customisable software system consisting out of isolated components that can be re-used or re-ordered to allow for fast development of new use cases or variations with minimum effort.  It should be noted that the decomposition of these components for re-use/ re-order should be done correctly so that they are capable to function by themsleves – they should not have any dependencies on any other component. No company can be agile if the software system is not engineered to be agile to start with.

You can not have agility through a process if the object being manufactured does not allow for agility in its design.

Think of the first motor vehicles that were build at the start of the 19th century, it was a very slow process to deliver a single motor vehicle as one person was assigned to build a car from start to finish. This was called couch building. Usually a single person had to manufacture and fit all the components by hand. This meant that all motor vehicles built by the same company and even by the same person were unique as each component were unique designed for that car. You could not fit a body panel from motor vehicle A to motor vehicle B. This was a slow process. You could not even speed it up by adding more people to the process as the components influenced the design of each other. The only way possible to speed it up was to remove features… in other words doing less.

Henry Ford came along and revolutionized the industry by building agility in from the engineering point of view. All components and body panels had to be the same and be manufactured upfront according to a certain standard. This required some design and planning.

As a result of this standardization suddenly all motor vehicles had components that could be fitted on any of the same model motor vehicle being built. This was as a result of engineering. Next he sped up the delivery process by implementing a new conveyor belt process. This sped up the rate at which motor vehicles were delivered.

But Wayne…. Agile is when requirements change…

Motor vehicles that followed used the same concept and as a result of a little planning upfront by designing standardizes components, different vehicle could be assembled by changing the manufacturing process slightly. This is where the agility was. The agility was in that the engineering allowed for rapid change. It was not about making people change direction.

The image above shows agility through engineering. By engineering for change ford could produce variations of essentially the same vehicle because the engineering allowed for agility.

How does one build a software system that is agile?

To achieve this one needs one individual or a group of individuals to own / overview the software system and plan and design agility into it – right from the start. Enter the software architect.

To repeat myself, one can not be agile by sacrificing integrity. If agility is a requirement of the software system then it needs to be designed for it.

The software architect sits outside the development process and usually receives the requirements a few weeks before the implementation starts. The architect identifies volatilities, re-usable components and creates isolated sub systems. Work is then planned and given back to the product owner. The product owner then prioritizes the work and hands the project plan and requirements to the team to implement.

But where is the agility?

This is crazy Wayne! If we have to do the design and planning  above delivery will be to slow…We don’t have time for all this planning..

As I have said before the agility is not in the process… In the same way as where Henry Ford did some design and planning upfront which allowed for easy change doing some planning and design upfront will allow for agile software.

As the architect builds up and matures the components and sub systems the delivery rate increases as the system can re-act faster to change. So if a client decides to change his requirements the change can be absorbed easily because it was foreseen and planned for. So red leather instead of black…no problem.

This can obviously not be achieved overnight but by designing a software system based on sub-systems and components the risk is contained and agility is achieved as the components can be re-used and re-ordered to create new use cases or variations of them.


I will end off this article by stating that until a company, its leaders and the business as a whole has bought in and accepted that agility is an act of engineering their only solution to agility will remain to compromise the integrity of the software system and thereby increase their risk.

No process will ever help a software company to have an agile software system.


Amazing video I found that basically says the same thing as my article.

Please be sure to also read.

Leave a Reply

1 Comment threads
0 Thread replies
Most reacted comment
Hottest comment thread
1 Comment authors
Shaun Kiesewetter Recent comment authors

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

newest oldest most voted
Notify of
Shaun Kiesewetter

Wayne this is truly a master piece. As the saying goes … the architecture/design of the mouse and the elephant are in actual fact identical. The substitution of design for “process driven agility” leads to the functional decomposition of the system. This leads to an initial perceived success and good velocity, but as the real change creeps in, so does the debt.

The team quickly re-factors and refactors and refactors, only to refactor what has been refactored, as the functional system cannot absorb the change. The source code cyclic complexity grows to such a level, that nobody can anticipate the slightest change. As the product reaches the event horizon, most management will try add more process and more resources, perhaps they will even hire an agile coach.

Alas the agility was lost in sprint 1 when the foundation was cast on a rigid set of requirements . Much like a star implodes under its own gravity, so does the functional project collapse under its own complexity.

Should the system be correctly composed the design will facilitate the change at the foundation level, the more system is worked on the stronger it will become, and the more it will adapt.

But then again, clearly you know all of this.

Well done love your analogies 🙂