What Is Agile

I’m going to try to write a book. It will be the third attempt at a book. The first one I started over 8 years ago on Java CAPS testing. I got about 30 pages in and it needed up abandoned. My last attempt was at DevOps.  This was started at the end of last year. I got a couple of chapters in, but it ended up being abandoned as well as I got stuck on a chapter. No time, I kept concentrating on my blogging and working on my Six Sigma Yellow Belt. This time, i’m going to try to write the chapters as blog posts. This kills two birds with one stone. I get a blog post out and a chapter. So it may be a couple of weeks between posts,but I will try to keep at least one per week.

So, here is the first chapter in its current form. Subject to change before the book is generated.

What Is Agile


  1. Able to move quickly and easily.
  2. Able to think and understand quickly.
    Oxford Dictionary (Online)

If you do a search for “Agile” online in the Oxford Dictionary you get the following which is related to the Agile methodology

Relating to or denoting a method of project management, used especially for software development, that is characterized by the division of tasks into short phases of work and frequent reassessment and adaptation of plans.
‘agile methods replace high-level design with frequent redesign’
Contrasted with waterfall (adjective)

The contrast to Waterfall is that Waterfall does the design up front of the whole solution, then you develop the whole solution. Finally you test then deploy the whole solution.

Although the definition is correct, I don’t like the following:
The phrase software development which I have emphasized denotes that Agile is specifically for Software Development, but this is now not true. Agile methods and techniques are now no longer in the software domain. It is being used to make cars (Wikispeed), Law Firms (Lonely Planet), Education, even the US military uses a form of Agile for combat.
As for Project Management again which I have emphasized, it no longer is specific for this domain. Agile in the Software Development industry is used for day to day activities, as it is with the other domains I have mentioned above.

For me:

Agile is an umbrella term for a set of methodologies that developed originally in the software industry but are being adapted outside of this domain to formalize continuous improvement, simplification of tasks and iterative/incremental approach to work, with the goal to allow change and adaptation to happen quickly and easily with minimal disruption.

Even this sentence doesn’t quite explain Agile as I see it.

In this book, I want to go through exactly what Agile is – at least to me. How to have an agile mindset, how to implement agile – at least one of the methodologies, Scrum and some techniques on how to expand Scrum to get the most benefit.

Firstly, lets go through the history of Agile.

History Of Agile

If you are reading this book. You most likely work in the IT industry. Either a Software Developer, Architect, Project Manager, Manager or so forth and are curious about this new Agile thing.
Well, Agile isn’t that new. In fact Scrum, the most popular implementation of Agile techniques is 21 years old at the time of writing, but the methods of Agile and the thinking process are even older than that.

In fact Agile techniques have been used for a long time, it just wasn’t called Agile.
For example, the construction of the Empire State Building. The building was designed in 2 weeks. They had 1 year to construct the 80 story high building ready for opening on the 1st of May 1931. They designed the building “after” purchasing the site. Construction at its peak was at 4 and a half floors per week and over 500 trucks per day coming to the site. The trucks would come up, their load unloaded and placed where it was needed then and there. No waiting, no putting aside, just work. Remember, this was 1930, so no computers to schedule everything. It was all done by hand and worked out on the fly. Planning was done for the weeks worth of work. Not months in advance, they just didn’t have the time. Workers had a problem solving attitude. Every day over the scheduled opening day would cost the company $10,000 1930’s per day. so whatever they could do to save time, even if it cost money was implemented. For example, they had a miniature railway to bring materials.
To top it all off, the project was completed 12 days ahead of schedule. That is amazing!
These techniques were not even new at the time, it was just how buildings were constructed.
This wasn’t standard across all industries. In fact the mass manufacturing techniques developed by Henry Ford and the teachings for Frederich Winslow Taylor were the standard.
Fast forward 10 years and then you have World War II. Men would go off to fight and women would be the ones working in the factories. These factories needed to be efficient. They needed to make the armaments. weapons, bombs, planes, tanks even clothing for the soldiers as fast as possible so that they could be used for the war effort. The quality needed to be high grade. Who would want their sons fighting a war with substandard equipment, but had to be made cheaply. W. Edwards Demming was part of a 5 man team that developed the statistical methods that helped the manufacturing standards during World War II. When the war ended, the men came back and things started to follow they way there were done before the war. All the efficiencies developed with the women were abandoned.

Deming and his colleagues efforts were not unnoticed. General Douglass MacArthur asked Deming and his colleagues to help Japan with their national census with statistical knowledge. In 1950, the Japanese Union of Scientists and Engineers had been studying Walter A. Shewarts techniques for reconstruction and manufacturing and since Deming had studies under Shewart, he was asked to speak and teach. One of those students of Demings was the co-founder of Sony.

Demings work in Japan was revered. An award for Quality was given in his name, the Deming Prize. Unfortunately in his own country his name was unknown and remained so until the 1980’s.

Another company that took these teachings on board was Toyota. More specifically, a man named Taiichi Ohno. He took the teachings further and developed techniques such as Just In Time (JIT) and eliminating waste (Muda) and Continuous Improvement (Kaizen). He is also considered the father of the Toyota Production System.
Toyota had a reputation of quality cars that were manufactured cheaply, and this didn’t come to light in the west until Toyota started exporting to the USA. Toyota made cars cheaper, and of better quality that any of the US manufacturers and it had them scared. Even so, it still took them decades to take on board the learnings. When they did, the name changed. You couldn’t have General Motors saying for example that they used the “Toyota Production System”, so the name changed to “Lean” to reflect the elimination of waste. Or “Trimming the fat”.

About the same time that this was all happening, many software developers were looking at better ways to develop software. The Waterfall method where you work out the requirements up front, design the system, implement, test then finally release was starting to fray at the edges. Customers would change their minds once they saw how things were working. They were not happy with the final product as it didn’t do what they wanted or since projects lasted 6months to 2 years or longer, by the time the software was released, it no longer met the requirements of the business. Something had to change. Something lightweight was needed compared to Waterfall. Using inspiration from Lean, a lot of new techniques were developed. DSDM (Dynamic Systems Development Method), (RAD) Rapid Application Development, Crystal Clear, (XP) Extreme Programming and Scrum.
Many of these techniques are still around over 20 years later, but the most common of these is Scrum.

In February 2001, seventeen software developers met together at the Snowbird resort in Utah to discuss lightweight software development techniques. Among those were the developers of Scrum. Jeff Sutherland and Ken Schwaber. There they published the Agile Manifesto.

We are uncovering better ways of develoing software by doing it and helping others do it. Through this work, we have come to value:
Individuals and Interactions over process and tools
Working Software over comprehensive documentation
Customer Collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

This is the moment when Agile became a thing.

Since then, we have had other Agile methodologies developed such as Kanban which was developed in 2010 by David Anderson and is modeled on the Kanban system used by Toyota to track the usage of parts and components during the manufacture of cars and Lean Software Development developed by Tom and Mary Poppendieck and DevOps which started Patrick Debois, John Alspaw, and Paul Hammond.

Many of the Agile methodologies have the following in common.

  1. The elimination of waste
  2. Continuous Flow of work
  3. Continuous Improvement
  4. People

Why Go Agile

There are many reasons why people start to go agile. These usually are

  • A CEO/CIO/ or some other level manager sees another company using Agile and decides that they should use agile too.
  • Agile is the new hot thing. We should do it!
  • My manager told me that we should use Agile.
  • Agile will make us go faster, reduce costs and increase quality.
    The one I like the best…
  • I want to improve and get better. I’ve heard Agile can do this.

Whatever reason you want to go Agile, I would like you to know what it involves which is why I am writing this book.
Agile can be easily implemented incorrectly. In fact, most companies that implement Agile get it done incorrectly because they do not research what they are doing. They see practices and just follow without understanding. The beauty of Agile is that even in these cases, there is some value still to be gained. The problem is that the value is only a small fraction of what can be accomplished compared to when Agile is implemented incorrectly. I will go through the pitfalls of going Agile later in the book.

Just remember, Agile isn’t a silver bullet. It can bring you all the above, but what it does do is let you know when something isn’t working sooner. What you do with that information is up to you.


Leave a Reply

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