Content
The purpose of this article is to explain the Agile concepts, history, basics and fundamentals.
They say "A picture is worth a thousand words". Picture use does not mean that the article is light; in fact I am trying to teach a pretty sophisticated concept in an easy way. So I have used too many images to to map the theory into something you can be imagined or drawn and provide a better understanding.
During my work experience, I found a lots of people have a miss understanding of Agile. They are using some Agile methodologies like (Scrum, RUP) but they do not know what Agile itself is meaning.
So I wrote this article to provide a basic understanding of Agile software development. It focuses on the Agile theory in common so the reader does not need to have a technical background.
Also, it could be a reference to understand Agile philosophy.
It is a philosophy, Culture, mindset or a set of values.
A small group of people got together in 2001 to discuss their feelings that the traditional approach to managing software development projects was failing far too often, and there had to be a better way. They came up with the something named agile manifesto, which describes 4 important values that we will discuss it in details later in this article.
Agile software development is a different way of managing IT development teams and projects. Also, we can say it is as an alternative to traditional sequential development, or waterfall.
It just made perfect sense to me to explain the agile like a fat person that he want to lose weight and become agile.
This example will go through the values, principles that he should take care of it. Then the Methodologies (diet programs) that he need to apply.
On the above image we can see a fat man in the left image (not agile) and then he became thin (agile) as image on the right.
Let us Interview this person to tell us how he changed himself.
- Q1 – Please let us know how did you become Agile and you lost the extra weight?
Answer:
I put to myself some values then embody the values and provide more concrete examples through a set of principles. Then I applied (values and principles) through some diet plans (Methodologies). - Q2 – Please let us know the values?
Answer:
- Changing eating habits over following a diet plan.
changing your eating habits like start cooking healthy food with less cholesterol and enjoying dark chocolate, coffee without sugar, fresh juice is more important than following a diet plan. - Control the amount you eat over eating a specific healthy food.
It will be hard to stop all of your bad eating habits at once. So it is more important to control the amount you eat and make it less and less. - Doing sports you enjoy over following a specific fitness movement.
Practising the sports that you enjoying is more important than doing a set of specific movement that you will feel boring about it later.
"That is, while there is a value in the items on the right we value the items on the left more."
- Q3- Please, let us know the principles?
Answer:
- Stop counting: counting every calorie or gram of fat is simply not conductive or useful for keeping extra weight off over long run.
- Evaluate the food you eat: Pay attention to the quality of the carbohydrates, protein, and fats you eat. Avoid refined starches and sugars and saturated fat.
- Embrace variety: Do not base your diet on just a few food.
- Get enough time of sleep: Your body needs 8 hours of sleep every day.
- Become more self-aware: like Start drinking green tea and going to the gym between 3 to 6 days per week.
- Please let us know the diet plans (Methodologies) you tried?
Answer:
I have tried Atkins diet, Caveman diet, Blood type diet and Fat flush diet. And I found the blood type diet is more suitable for me.
The basics of Agile is very similar to the above example; It has Values, Principles, and Methodologies.
- Agile Manifesto (Values): The 4 Agile Values serve as the foundation of Agile philosophy.
- Agile Principles: The 12 Agile Principles embody the Values and provide more concrete examples of what Agile means at a lower level.
- Agile Methodologies: Methods that support Agile values and principles (Scrum, XP, ..etc).
-
As I mentioned earlier in this article In February 2001, 17 software developers met at the Snowbird, Utah resort, to discuss lightweight development methods. They published the Manifesto for Agile Software Development to define the approach now known as agile software development. Some of the manifesto’s authors formed a nonprofit organization that promotes software development according to the manifesto’s principles.
Agile Manifesto reads, in its entirety, as follows:
“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 a value in the items on the right we value the items on the left more.”
Agile Manifesto (Values) Explanation
- Agile Value (1): Individuals and interactions over processes and tools.
If processes and tools are seen as the way to manage product development and everything associated with it, people and the way they approach the work must conform to the processes and tools. Conformity makes it hard to accommodate new ideas, new requirements, and new thinking. Agile approaches, however, value people over process. This emphasis on individuals and teams puts the focus on people and their energy, innovation, and ability to solve problems.
- Agile Value (2): Working software over comprehensive documentation.
The documentation does not produce any value. Only the software produces value. The Agile Manifesto, asks us to focus on the outcome (working software ) and to make tradeoffs to minimize the means (comprehensive documentation ).
It doesn’t mean that you should not create documentation; it means you should create documentation that provides value and at the same time does not hinder the team’s progress.
In another words working software will be more useful and welcome than just presenting documents to clients in meetings.
- Agile Value (3): Customer collaboration over contract negotiation.
In traditional development model, the software company and the customer requiring to document exactly what they want and what they are going to do. This provides a means to assign blame when projects fail.
In stark contrast, Agile suggests that we should favor shared collaborative efforts over contractual obligations.
If you actually collaborate with your customer frequently, you will find the contract will not be pulled out at every meeting.
In general we can say the contract will not matter as much as the people who signed it.
- Agile Value (4): Responding to change over following a plan.
A lot of traditional methodologies around software are all about trying to control change.
Agile says, "We're not been going to control change. Instead of controlling it, we should embrace it, we should expect it to happen and when it happens we should figure out how to deal with it.
"Humphrey’s Law" says that customers never know what they want until they see working software. So we have to expect a lot of changes during development.
Agile methodologies are based on the knowledge that, change is not something to be feared or avoided. Change is the driving force behind added value. So do not resist change, but do be resilient to it.
- The Proposed 5th: Craftsmanship over Execution.
Robert "Uncle Bob" Martin proposed that the Agile Manifesto be updated with a fifth value, "Craftsmanship over Execution".
We value well-crafted software over working software. It’s very important that the software works, but even more important is that the code is clean, that it is easy to read and therefore easy to change.
-
There are a Twelve principles underlie the Agile Manifesto, Those principles embody the Values and provide more concrete examples of what Agile means at a lower level.
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- Business people and developers must work together daily throughout the project.
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- Working software is the primary measure of progress.
- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
- Continuous attention to technical excellence and good design enhances agility.
- Simplicity--the art of maximizing the amount of work not done--is essential.
- The best architectures, requirements, and designs emerge from self-organizing teams.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
-
Agile methodologies are methods that support Agile values and principles.
The most popular Agile methodologies are (XP, Scrum, ASD, Crystal, DSDM and FDD) and It has been adopted by a growing number of organizations worldwide.
How To Choose Between Agile Methodologies
Agile is not tied to one particular methodology. You need to decide the appropriate methodology for your organization because some methodologies do not fit your culture, your people, your market, or your tools. If the chosen methodology is not going to work, you need to change to another. Also, you can build out your own Agile methodology and improve it over time based on Agile values and principles.
As you can see in the above info graph there are a lot of methodologies under Agile umbrella. The main differences between them are the number of rules to be followed for example Scrum(9 rules), XP(13 Rules), Kanban(3 rules).
Note that a fewer rules to follow a more adaptive you get.
Traditional software development methods which might be more properly called Waterfall is a linear (sequential) approach to software development.
The Waterfall method has been prevalent in software development, Dr. Winston W. Royce (1970) was one of the first people to describe the Waterfall approach.
Waterfall has obvious appeal. It provides an easily understandable process that seems to progress in a logical sequence (Analysis --> Design --> code --> ..etc). Moreover, it’s a familiar process because it is similar to how we build other things, such as buildings and cars. The gates provide a form of risk management, in that the process cannot proceed to the next step without an authorization of the preceding step.
The main issues with Waterfall are you don’t realize any value until the end of the project, you leave the testing until the end, and you don’t seek approval from the stakeholders until last day. This approach is highly risky, costly and less efficient.
-
Waterfall employs a sequential design process. Development flows sequentially from start point to end point, with several different stages (Analysis, Design,.. etc). In contrast, the Agile method proposes an incremental and iterative approach to software design. It was essentially developed in response to the limitations of Waterfall, The design process is broken into individual models that calls “sprint”.
-
In waterfall the customer will not realize any value until the end of the project but in Agile Customer feedback occurs simultaneously with development
-
There is a very closer collaboration between developers and the business on Agile which is missing in waterfall
-
The cost of change in Waterfall projects is relatively high. In contrast on Agile the changes to requirements can be incorporated at any point of the process – even late in development and will cost less.
-
The Delivery risk in in Waterfall projects is relatively high because it will leave the customer until near the end of development cycle. In contrast using Agile there will be continuous delivery of working software that will reduce the delivery risk.
- It needs customer availability and cooperation
- It needs customer with a clear vision (The project can easily get taken off track if the customer representative is not clear what final outcome that they want).
- Only senior programmers are capable of taking the kind of decisions required during the development process. Hence it has no place for newbie programmers, unless combined with experienced resources.
- It is hard to quantify the total effort and cost to deliver a project.
- Projects with aggressive deadlines
- Projects with high degree of complexity projects
- Projects with high degree of novelty (when we are doing something that is new, or at least new to the team building it)
- Project without a clear requirements that may need a lot of changes to be implemented.
- Differentiate between doing agile and being agile
A lot of times when an organization try to do agile. They have a checklist as to the things that you’re supposed to be doing. So they are doing agile instead of being agile. Being agile mean is to think based on agile principles. But doing agile mean is following one agile methods like Scrum, Kanban, Lean, etc... - People working together
How to get your team members work together, For example two groups (developers and testers), they’re in separate groups in a traditional software development process and they don’t know how to work together. Therefore the organization will struggle to teach them how to work together, what are they going to do if they sit together and how are they going to work. Because the whole idea behind agile is to get everybody working together to build quality into software instead of trying to test, fix, retest, fix, retest, fix.
Be careful, and don't move to agile if everything is working. You should use agile as a way to improve, and if you really feel like there’s some places that your organization is not delivering what's needed to the market, then you consider agile. If you’re not having those problems, don’t move to something new. Change is hard. (Jeff Payne)
Agile may not be perfect, but it is better than the alternatives
- 17/12/2015 Article Added.
This member has not yet provided a Biography. Assume it's interesting and varied, and probably something to do with programming.
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
