What does Agile mean to us

All articles on our site are opinion pieces.  It is an educated opinion, based on decades of programming experience, but still just an opinion.

What does agile mean?

Agile is best expressed in two key points:

1. Breaking a software project into the smallest practical discrete modules.  These modules are built and released one at a time in an incremental fashion.  A better name might be “incremental software development”.
2. Customer and developer working closely together.  Customers provide bite sized snippets of specification to the developers.  Developers quickly build working prototypes and samples which are feed back to customers.  Developers can communicate quickly and openly with customers to clarify ambiguous requirements and resolve issues.

That’s it!  You will find plenty more complex and fancy explanations of agile,  however, the essence of agile means customers and developers working together to build incremental software modules.

 

Traditional software development

Agile is arguably the opposite of a traditional software development life cycle.  A traditional waterfall development cycle might look like this:

Specify -> Design -> Build -> Test -> Install -> Argue

Yes, argue is put there with tongue in cheek.  However it is not far from reality. 

The argue part comes about because there is a gap between what the customer expected and what is delivered.  This gap is neatly summed up as the software crisis.

 

The Software crisis

Prior to the 1960’s computer hardware was rather limited.  So computer programming expectations were lower and software programs were relatively simple.  Since the 1960’s hardware has become much more powerful and provided the scope for larger and more complex software solutions.  

Please don't miss my point here, I am not disrespecting programmers from days gone by.  In earlier days, programmers were highly skilled at making every byte and CPU cycle count; to squeeze every last drop out of the available hardware.  Today hardware is cheap, powerful and plentiful.  The programmers challenge today is dealing with complex requirements, tightly integrated systems, short time frames and high user expectations.

This change has lead to the software crisis which plagues software development even to this day.

According to Wikipedia, the software crisis manifested itself in several ways:

• Projects running over-budget 
• Projects running over-time
• Software was very inefficient
• Software was of low quality
• Software often did not meet requirements
• Projects were unmanageable and code difficult to maintain
• Software was never delivered

There have been many solutions proposed to mitigate the software crisis.  There is no silver bullet cure, however the most successful remedies involve software development mythologies which use an incremental or agile approach.

 

Benefits of agile software development

In a nutshell, the key benefit of agile is risk reduction and mitigation . Agile reduces the impact of the software crisis in the following ways:

Improved budgeting and better time frames

Budgeting for custom software development is difficult.  The clue is in the name “custom”.  Any custom creation is made specially for an individual and is different from previous work.  To budget for a custom software project, developers must use proxies and estimation, which has lead to some spectacular underestimations of cost.

An incremental approach, building modules one at a time provides an early and accurate indication of costs and time frames.  A software project will usually have some form of overall budget and time frame before the project begins.  As a project progresses and the first modules are delivered, a clear indication of costs and time frames emerges.  This indication is based on actual costs and working software, so there is a lot less guessing involved.  Because the indication is delivered early, it is possible to make adjustments to budgets and time frames early, well before the project is completed.

The close working relationship between customer and software developer will lead to other cost savings.  The team will identify better and simpler ways to approach each module, even eliminating some unnecessary modules.

 

Improved software quality and efficiency

When building a large software project, it is easy for bad code to slip in and propagate throughout the project.  The quality and efficiency problems which arise from the bad code may not be noticed until the project is live and completed. 

Agile does not directly address software quality and efficiency issues.  The direct way to improve software quality involves having skilled developers with good tools and processes. 

Agile provides indirect help with improving software quality and efficiency by giving an early indication when bad code has got into the project.  As the first software modules are delivered, customers begin using the software.  If the software modules are slow and/or buggy, the team are able to address these issues early and make sure the same mistakes are not propagated to the rest of the project.

 

Significantly better match of requirements and deliverables

It is unlikely a customer knows exactly what they need or want a custom software system to do.  In a non agile world, the developer gathers customer requirements, designs a system and presents the design to the customer for sign off before coding begins.  However, without having their hands on a working system, it is unlikely a customer will fully understand a design.

When you have customer and developer working closely as a team, the software is pretty much guaranteed to do what the customer requires.  The customer can see the software features emerge as the project progresses.  If the developer has misunderstood an aspect of the requirements, this becomes obvious early on and is easy to correct. 

Reducing the gap between a customers requirements and what is actually delivered is the greatest benefit of Agile.  

 

Agile projects are maintenance projects

Difficulty with maintaining code is caused by a gap between development and maintenance.  With a traditional software development approach, maintenance does not begin until after the project is live.  In this time, developers may have changed, knowledge is not passed on and forgotten, maintenance becomes hard.

In agile projects, the same developers who wrote the code are also doing the maintenance.  Maintenance begins as soon as the first software module is delivered and long before the project is finished.  When developers have to maintain code they will make it easy for themselves.  It is a case of self interest, if the code is easy to maintain, the developers lives become easy.

Agile also allows for changes in staff in the customer's business.  With software modules delivered incrementally, the customers staff will get exposure to the software long before it is completed. If staff working closely with the developer decide to leave, others can take over more easily because they have already had access to parts of the software.

Agile software projects deliver a working system

Complete non delivery of a software product is nearly impossible with an agile approach.  Discrete software modules get delivered within days or weeks of a project starting.  Even if a software project does not go though to completion, the customer will end up with a limited working system.

 

Agile Projects easier to manage and more flexible

As software modules come to life, customers will want change.  New ideas will come up, previous plans start to look less attractive.  With agile development, it is easy to change designs and plans to get developers working in a different direction.  There is no lock it to the original design.

 

Agile Misconceptions

There are consultancies out there who will sell you the instructions to become agile.  If you need a consultancy to tell you how to be agile, you have probably missed the point. 

Terminology

Agile software has a whole bunch of cool sounding words.  Using words like Scrums and Sprints does not make you agile. Doing incremental software development with close collaboration between developer and customer is being agile.

Meetings

There is no need to change the way you do meetings.  If you need to meet in the board room, over the phone, standing up, sitting down or in your pajamas at the local petting zoo, it does not matter.  The key is developer and customer communicate directly. 

A project may have many people involved with roles that sit between customer and developer.  The developer might be a sub contractor. Even so, the developer and customer must be able to collaborate directly to ensure the software meets the customers requirements.  No direct collaboration means there is a gap where problems can arise.

 

Sticky Notes

There is at least one consultancy out there pushing sticky notes as a key to agile development.  They say you should use sticky notes to replace whiteboards and your meeting room booking system.

Funny enough 3m have a reference to sticky note agile as well.

If sticky notes help developers work more closely with customers, great. If, somehow sticky notes help break software into byte sized chucks, even better.   Otherwise, continue to write stuff down on paper, whiteboards or on a computer, whatever works for you.

 

When Agile is not so useful

There are software projects where agile is not suitable.  There are three factors which make agile development less appropriate.

1) The software requirements can be clearly defined and understood by both customer and developer.

2) Human lives are at stake if the software fails

3) Large amounts of money could be lost if the software fails.

My favorite example of a project where agile is not suitable is the space shuttle guidance system.  The software requirements can be clearly defined, and the software must work 100% first time otherwise peoples lives and billions of dollars are at risk.  It is not possible to built a fraction of a shuttle guidance system and let the customer try it out before building the rest of the system.  The shuttles guidance system was so well designed and perfectly constructed, it ran on a well tested computer with 1.2 megaflops of processing power, even though 80,000 megaflops machines were cheaply available to consumers at the time.

I would argue the overwhelming majority of customer business software is not clearly defined, not life critical and not going to cost megabucks if there is a failure.  As such most business software should be written with an agile approach.

 

In conclusion

Agile software development means customers and developers work closely together to deliver a software project in incremental modules.

Agile reduces the risk of software projects failing to meet customer requirements.

Agile does not need specific techniques and processes, just co-operation between customers and developers.

Agile is suitable for most business software projects.