Agile Software Development
It is also an Iterative Software Development Process. That means we are not going to develop the whole thing at a time. We will separate the project into parts by part. But there are some different characteristics the Agile method has which are slightly different from the Iterative Software Development Process.
So, why do we need the Agile or Iterative Software Development Process?
The primary reason is, we need to accommodate changes. In Linear process development since we do not have any flexibility to adopt changes, that’s why Iterative/Incremental/Agile Software Development comes.
The next question will arise why do we need any changes? Why changes are coming?
- In the software development industry, there might be some competitive advantage. If you are talking about the service-related company, every month they are coming with some new services to the client so that they can remain champion in their market competition. For example, a mobile company. There are at least 5/6 operators in Bangladesh. To remain to stay in the competition they are changing their business strategies, offering new services, packages now and then. Because if they do not follow the market competition strategy they will remain backdated and other companies get ahead of them. So, to remain in the competition they need a change every month/ every three months/ six months.
- Technologies are changing rapidly. The technology which is the latest today may be backdated after 6 months. New technologies are coming and coming. This is another reason for changes.
- The most important reason and a major reason why changes are happening in the software development process is to deal with customer requirements. In the beginning, the customer does not know much about the software. They don't know the functionalities, the features. The customer does not know the complete picture of the software. After delivering some prototypes to the customer, he realizes what he needs. So, that's why the customer asks for changes, modifications of the developed features. Maybe they ask to remove some features because do not need that features, may ask to add some features. So, the customer will ask for any kind of changes. So, to adopt those changes we need to change our software development process.
These are the basic reasons why changes may happen.
Now we need to know what Iterative Software Development has been doing?
- Since Agile is an Iterative process so we are going to divide the total project into parts by part. Each iteration is a self-contained mini-project where the Waterfall model can be used.
- Before delivering the whole project to the client we may deliver this particular part of the total project to an internal release. This internal release will reveal some problems or drawbacks that we need to work on before delivering to the actual client.
- Most importantly, the iterative process will provide us with some hints or some ways to find out the requirements of the next iterations. If we are talking about iteration no N which will help us to find out the requirements of iteration no N+1. This is how the previous iteration is used to help us to find out the requirements for the next iterations.
What is an Agile Model?
- It is a lightweight method. We are working with small parts, not with all the parts at a time. Just concentrating on a single part, not the other parts at a time.
- People-based rather than plan based. In Agile, there is no fixed plan like the Waterfall model. What happens in Agile is, all the team members choose the tasks by themselves. Nothing is assigned to anyone. Teams are coming and choosing that they will do these(one part) works for next 1 month then another team comes and choose another part. Like this, the works are done by pick and choose. This is called people-based. One important thing is, as there is no fixed plan, so the persons who are choosing the tasks must be experienced.
- No fixed single method/model. There are many methods in Agile development. It is not like that we must follow one method/model. We can work combined with more than one method/model (Hybrid).
- It is a set of guidelines. We are given some suggestions or guidelines not any kind of plan. We can plan according to our choice. There is no fixed plan, we should just follow the guidelines.
Agile and other Iterative Models (What is the difference?)
Here we will discuss the Agile and RAD model.
The main difference between Agile and other Iterative models are in the iteration length. In Agile, every iteration should be a maximum of 1 month/30 days/ 4 weeks and intentionally do not exceed it. If we have a 6-month project, we need to divide the project into 6 parts or at least 6 parts because each part should be given a one month time. So, it must be a maximum of 1 month or less because if an iteration has more than 1-month length then it will not be an Agile model. We can divide the project into more than 6 iterations but cannot divide in less than 6 iterations because then any of the parts will take more than a month. That's why we need to fix the length in 1 month.
On the other hand in RAD(Rapid Action Development), only the first part of the project must be delivered in 90 days. It doesn't matter how many days the project will take and how many days the other iteration will take.
So, this is the primary difference between Agile and other Iterative development models.
Now the question is, we can solve the drawbacks of the Waterfall and other linear sequential models by following Iterative models. Then why Agile Model?
The answer is the customer’s early feedback. No other iterative model can give more frequently early feedback than Agile. Because, if the iteration length is small then we get customers’ feedback very early.
One disadvantage of the Waterfall model is, the product is not delivered early and so the product is also visualized at a very later stage. As a result, we get the customers’ feedback at a very later stage.
In the Iterative process model, we may get the customers’ feedback a little earlier than the Waterfall model. Suppose, if we divide a 6 months project into two parts then we will get feedback in three months. But we have to wait for three months. But in Agile development, the maximum time box is 1 month. So, we get some feedback delivering the product in one month from the customer. So, we are getting this feedback very frequently. So, if the customer request any changes we can adopt that at a very early stage. We can also find out the problems very early. If we can solve the problems early we will get less complexity in the project, we will have less risk in our project (as we are in a very early stage), we will have plenty of time to fix any issue, we can take frequent feedback from the client and modify the product.
So, the less the iteration length the more we get better feedback, the project complexity will be less, the overall risk will also be decreased as well as higher productivity and success rates.
What is Time Box- Scope?
Timebox is the iteration length and Scope is the task that is filled in the iteration length.
Suppose we have a 6 months project. If we follow Agile then we have to divide the project into at least 6 parts (It can be more than 6 but can not be less than 6. Because if it is less than 6 then there will be a part whose iteration length will be more than 1 month).
Now, if we divide the project into 6 parts then every parts’ duration/length will be at most 1 month. This 1 month is called the Timebox.
And in this 1 month, the number of tasks that will be assigned is called the Scope. Suppose, there are 10 functions in the project. 2 of them are selected for the first month, 3 of them are selected for the second month, another 2 are selected for the third month, like this way. So, for the first month, 2 functions are selected. these are called the Scope.
Now, there can be a situation like suppose 5 tasks are selected for a month. We have to fulfil them in that month. So, the timebox is 1 month and the scope is 5 tasks. After 28 days, we see that the task that remained left can not be done in the time we have left in our timebox. So, there are two possibilities. One is extending the timebox (making the time box into 32 days) and another one is reducing the scope (complete 4 tasks instead of 5 and the left one will be done in the next timebox). So, according to Agile, can we extend the timebox?? or, we can reduce the scope?
According to Agile, we have no authority to increase the timebox. If any task is incomplete left it like that way. We have to deliver what we have done in that timebox. The incomplete task will be added in the next months’ iteration. We will fix the iteration and will use the scope like a variable. We can reduce the scope.
Agile Proponents Believe (Depending on which particular foundation Agile has come?)
The Linear process and Iterative process development are very rigid because we make few changes in this development. In comparison to the Waterfall model, there are a few more changes in scope in the Iterative model but still, it is less because there are no specific rules in these models about iteration. But in Agile the chances are huge because agile is giving us more scope of changes. In the iterative model, we can divide a project according to our wish (2/3/10 …). That's why Agile has come. As the system is rigid and we have to do a lot of work so Agile is saying why we are not fixing any specific rules for iteration? why we are not making the iteration shorter? If we make a rule like, we have to divide a 6 months project into at least 6 parts then we will get many advantages like the risks will be reduced, will get better feedback, the complexity will be less and many more.
Agile Value Statement
In 2001, Kent Beck and 16 other noted software developers, writers, and consultants (known as Agile Alliance) signed a manifesto 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
We find 5 things in Agile development as value statements.
- Client interaction is excellent. When we deliver something to a client every month then we can interact with the client, taking feedbacks from them and working with it, if clients request any changes we modify them.
- Client representative in the development team. A person is selected as the representative of the client who will work as a part of the software development team. He is the product owner. He is a person from the client who is dedicatedly assigned by the client to the software development company. So that, when the development team need to ask anything they do not need to visit the client, they can just ask the representative who is already assigned by the client.
- Delivering each iteration to the client. We deliver every iteration to the client, take feedback from them, working in the documentation process. We are working with requirements, designing, coding, testing, delivery, feedback in every single iteration. These things are done at a very early stage. If we think about the waterfall model, we cannot even start coding before 3/4 months. At first, we have to work with requirements, then designing then we can start coding. As a result, the working software will visualize lately but in agile we are getting the taste of working software at an earlier stage.
- Customer collaboration. Since there is a customer representative in the team so after every iteration he will collect the customer feedback.
- Changes are adopted easily.
There are some assumptions in the Agile model.
- It is difficult to predict in advance which software
→ In particular software development, we are not sure which requirements are stable, which will change during the development process. We do not exactly know at the end of the software development which requirements will be the same, where changes will be made. That's why we need Agile to adopt these changes.
→ After collecting the requirements, we fix their priority. But we do not know about their changes. It may happen that we fixed the priority of a requirement high initially but in a later stage, it becomes medium/low priority. Again a low priority requirement can become a high priority one. So, how priorities are changing we do not know at the beginning of the software development process.
2. Design and construction are interleaved in many types of software. That is, both activities should be performed tightly so that design models are proven as they are created. It is difficult to predict how much design is necessary before construction is used to prove the design.
3. Analysis, design, construction, and testing are not as predictable (from a planning point of view) as we might like.
Agile Menifesto (Guidelines and Principals)
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Though we plan, expend money, whatever we do if our customer is not happy then it will be a total waste of money and time. So, in any kind of development, the primary measure of success is customer satisfaction. If the user is satisfied, then though there is any problem with the software/product, things will go right but if the user is not satisfied, even if we did everything we need to do, things will go wrong. So, Agile says, no matter what, you must satisfy the customer.
- Welcome changing requirements, even late in development. Agile process harnesses (control) change for the customer´s competitive advantage. Users can ask for any kind of changes at any point of time in the development process. So, we need to prepare to accommodate those changes even if late in the project development and should handle those changes properly. If we say to the client that we have already discussed the requirements and now any kind of changes is not possible then the client will be upset and dissatisfied. So, anyhow we have to welcome the changes.
- Deliver working software frequently with a preference for the shorter timescale. We have to deliver the working software frequently. We already know that the maximum iteration length in the Agile model is 1 month/30 days. We must divide a 6 months project into at least 6 parts. We can also divide it into more than 6 parts. So, the lesser the timebox the more frequently we can deliver the software and get more frequent feedback.
- Business people and developers must work together daily throughout the project. In the software development team, we will include a client representative so that both the development team and the representative can work together. Let's say, we are developing software for a bank. So, as the development team is mostly from a Computer Science background, they do not have all the processes and details about a bank. Now, if we have an expert (business people) from the banking sector then we can clear our queries from him/her. So, while working on any domain we need an expert from that domain in our development team.
- Build projects around motivated individuals. Give them the environment and support their need, and trust them to get the job done. In Agile development, we do not select any task for any team, we rather give them chance to pick the task. Let's say if we assign the designing task to a particular team member who is an expert in coding and assign the coding task to a member who is an expert in testing then they will be demotivated because they are not getting the tasks that they should. That’s why Agile does not assign any task rather it says to choose by yourself.
- The most efficient and effective method of conveying information to and within the development team is face-to-face conversation. Since the total requirements are not clear and changes can come at any time, we are not sure what is going to happen so we need face to face discussion with team members and the client. So that, the communication becomes easier. In Agile, everyone will work in a large space desk by desk, with no extra room for anyone so that, the physical barrier can be reduced.
- Working software is the primary measure of progress. When we deliver the first iteration, we are delivering a small part/function from the project. Suppose, if we have 10 functions in our project we are working with 1 function in the first iteration. After completing it the client wants to see if it is working or not.
- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace persistently. We need to follow sustainable development in Agile development. We divide the 6 months’ project into 6 parts and worked very efficiently in the first two months but became lazy in the third month then it is not good. Thinking that we are on the right track and kept relaxing and end of the iteration could not the task in time. Then what will happen? The unfinished task will be added in the next iteration and will create extra pressure. That’s why Agile suggests maintaining the speed. Sometimes fast, sometimes slow it is not good practice.
- Continuous attention to technical excellence and good design enhances agility. When we are working on iteration N then we are going to learn from iteration N+1. We work on the current iteration and will also think about the next iteration. We age learning by doing. If we do not learn from the current project we can not expect that our next project will be better than our current project. So, if we do not analyse the work of the first timebox then we can not use the experience in the next iteration. So, continuous attention needs to be there.
- Simplicity — use simple approaches to make changes easier. We are dividing the tasks into small parts. So that, we can concentrate any small part at a time and things become easy for us.
- The best architectures, requirements, and designs emerge from self-organizing teams (iterative development rather than defined plans). As there are no fixed rules in Agile development, so if the team members do not have self-organizing skills then they can not work in this process. Because there is no one to assign him any duty, he has to do it by his responsibility. So, if any teams member does not have any sense of responsibility, then he is not fit for the Agile development process.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly. We are working on the practice of the current iteration in the next iteration. We will set some milestones. Suppose, we set 3 milestones in a 6 months’ project. After every two months we will check the progress of our work, will check can we do the work even more effective way?. So, we will check these things after a certain time.
Agile VS. Plan-Driven Process
Agile Process —
- Small products and teams; scalability limited.
- Inappropriate for safety-critical products because of frequent changes.
- Good for dynamic, but expensive for stable environments.
- Require experienced Agile personnel throughout.
- Personnel succeed on freedom and chaos
Plan-Driven Process —
- Large products and teams; hard to scale down.
- Handles highly critical products.
- Good for stable, but expensive for dynamic environments.
- Require experienced personnel only at the start if stable environment.
- Personnel succeed on structure and order.
Human Factors In Agile Development
- Common focus
- Decision-making ability
- Fuzzy (vague) problem-solving ability
- Mutual trust and respect
Some Other Methodologies in Agile
- Extreme Programming (XP)
- Dynamic Systems Development Method (DSDM)
- Feature-Driven Development (FDD)
- Crystal Methods
- Lean Software Development
- Adaptive Software Development (ASD)
- Agile UP
AGILE CASE STUDY
You have been called upon to help out a struggling development team. The team is working on developing a mobile ticket app for a professional baseball franchise and has failed to deliver a working product on schedule. They think they are about two weeks behind schedule, but it’s hard to know because nothing is being tracked. They need help, and they need it fast! You have heard from other product managers that Agile practices have helped their projects in the past. You only want to implement practices that follow the Agile Manifesto. Which of the following practices would you implement?
(A) As tasks are started, they are displayed to the entire team in a table.
(B) The client cannot add new features after the initial planning is complete.
(C) The development plan is re-evaluated at regular time intervals.
(D) The software product manager acts as a messenger between the client and the development team.
What do you think is the correct answer?
(C) is the correct answer!
If you’re wanting to implement agile practices, having a development plan that is reevaluated at regular time intervals is a good place to start. This follows the agile value of adapting to change, therefore, answer C is the correct answer. A is not correct, since in agile, you want to track progress by working software or tasks completed, not tasks started. Answer B does not allow client collaboration or adapting to change. And D is incorrect since you want your development team and client to have constant open communication.
- R.S. Pressman & Associates, Inc. (2010). Software Engineering: A Practitioner’s Approach.
- Kelly, J. C., Sherif, J. S., & Hops, J. (1992). An analysis of defect densities found during software inspections. Journal of Systems and Software, 17(2), 111–117.
- Bhandari, I., Halliday, M. J., Chaar, J., Chillarege, R., Jones, K., Atkinson, J. S., & Yonezawa, M. (1994). In-process improvement through defect data interpretation. IBM Systems Journal, 33(1), 182–214.
- The Agile Unified Process (AUP) Home Page — Scott Ambler.” 2005. 21 Jun. 2016 http://www.ambysoft.com/unifiedprocess/agileUP.html
- “How to Manage the “7 Wastes” of Agile Software Development …” 2013. 21 Jun. 2016 https://www.scrumalliance.org/community/articles/2013/september/how-to-manage-the-7-wastes%E2%80%9D-of-agile-software-deve