What do "Agile" mean in context of software development ?


What do “Agile '' mean in context of software development?

Term agile means to be able to move quickly and easily.”  World of software development of 80’ and 90’ was far from being able to quickly and easily manage any changes. Every business need for new software had to follow a strict “Waterfall” path of development.

There is nothing bad by definition with this (Waterfall) approach. It’s perfectly reasonable to work all stepps (requirements, design, implementation, verification, maintenance) one by one. For example when you would be asked to build a bridge there would be nothing bad in first gathering requirements (who needs that bridge and for what), then designing it (making a strict technical plan) then implementing that plan exactly as planned (start construction work). Finally you will have to cover verification (check if that bridge is safe and serve its purpose) and maintenance (make sure that bridge will not collapse and will be useful for end customers in the next 100 years). 

Bridge has to be built with a constant set of requirements to serve its needs which can happen only if you will finally build the whole bridge. There is no value for the end customer in a bridge done 65% or even 99.9% To deliver value faster you can’t change plans in the middle of construction work. It’s rather obvious.

If you will apply this (waterfall) method to software development it will be clear that the end customer will have to wait for value until the very end of a whole process. You will have to know all requirements at the very beginning and you will not be able to change them unless you are ready to handle all the risks that come with a possible 2-3x times longer development period. (budget waste, waste of company production capacity, pressure from stakeholders etc.)

Now let’s ask yourself if the world is changing now in 2021 faster than it Was changing in 80’-90’ ? Do customers change their behaviours and choose different applications to solve their problems/needs more frequently ? Do product’s have to change more frequently due to that “world acceleration” ? 

Answers to those questions are rather obvious but imagine that there was a brave group of software engineers who saw that the world is “accelerating” way faster than the others. Those American & English software engineers proposed in february 2001 “Manifesto for Agile Software Development” (later “Agile Manifesto”) - a bald statement that changed the future of software development. 


Manifesto for Agile Software Development

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

  • Individuals and interactions over processes 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.


Moreover that group of engineers proposed a list of 12 principles behind the  Agile Manifesto .
            We follow these principles:

  1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
  3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  4. Business people and developers must work together daily throughout the project.
  5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  7. Working software is the primary measure of progress. Agile processes promote sustainable development.
  8. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  9. Continuous attention to technical excellence and good design enhances agility.
  10. Simplicity - the art of maximizing the amount of work not done - is essential.
  11. The best architectures, requirements, and designs emerge from self-organizing teams.
  12. At regular intervals, the team reflects on how to become more effective,  then tunes and adjusts its behavior accordingly.


more about Agile Manifesto:


Combination of such a manifesto and it’s principles had a tremendous impact  on the world of software development. There was an urge inside of industry “biggest brains” to get rid of “waterfall” as the only way to produce software. 

Approach that they proposed gives a main advantage in the form of faster delivery of value to the end customer combined with faster feedback. As a result we are now able to lower the risk that comes with delivering a project that at the end of the development process will NOT cover end customer needs.
Those needs can change at any time and they will change only more frequently in the 21st century. 

Want more? Read whole "How To Agile?" script!

Useful knowledge sources - books/essays/websites/YT channels etc.
(not only about Agile etc)  

About frameworks/tools: 

Scrum Guide - version 2020
“Scrum with CanBan” scrum.org guide - version 2021 
Labirynty Scruma - Jacek Wieczorek
Scrumban: Essays on Kanban Systems for Lean Software Development, Corey Ladas
Kan-Ban - Agile Project Management with Kanban, Eric Brechner
Succeeding with Agile: Software Development Using Scrum

Inspirations : 
Zainspiruj mnie kuba - PL YT channel
Atlassian - YT channel 
Development that pays - YT channel 

Books that are loosely connected with Agile/organization/management topics: 

Cargo Cult Programming - Richard P. Feynman

The Machine That Changed The World - James P. Womack, Daniel T. Jones, Daniel Roos
It’s Not Luck - Eliyahu M. Goldratt (TOC)
THE GOAL - Eliyahu M. Goldratt (TOC)
Slack - Tom DeMarco
Project Phoenix - Gene Kim & Kevin Behr, George Spafford
Elegant Puzzle - An Elegant Puzzle, Systems Of Engineering Management - WIlliam Larsson
Five dysfunctions of a team - Patric Lencioni  
Extreme Ownership - Jocko Willink  & Leif Babin



Suggested Posts

Let's talk