This article is a quick FAQ of Agile. By reading this you will understand fundamentals of Agile and different ways of implementing Agile.
I have been writing and recording lot of architecture related videos on design patterns, UML , estimation and C# projects. You can see the sample videos at http://www.questpond.com.

If you read the XP life cycle one of the things after we implement the task is code refactoring. Refactoring the process of changing the software in such a way that it does not change the
behavior of the code but on the other hand improves the internal structure. No code can be perfect with architecture, coding conventions, high reusability at the first level itself. Normally it
improves over the time. It helps developers to implement the necessary solution today and improve / make the code better tomorrow. Refactoring is the process of changing the system to improve the
internal structure with out changing what the system does. Below are three major activities performed during refactoring.

Simplify complex code

XP is all about light-weight and simplicity. This holds true not only for a process but also for coding. When you see a code can be simplified, discuss the same with your pair developer and
implement the same. For instance below is code which was further simplified in to one equation:

Figure: - Simplify Code

Move similar operations in to reusable code.
If we are having similar operations move them to one reusable code. For instance in the below class we have various sort function which sorts by phone, code, name and date. We can combine the
same in to one function called as sort and make it simple.

Figure: - Reusable code

Remove duplications and redundancy

When a project has constrained time lines it’s very much possible that project can have lot of duplications. So when developers have executed the task they can review for these kinds of
duplications. For example the below figure ‘Remove duplication’ shows how the phone number duplication is removed from the customer table. The customer table had repetitive fields like mobile
number, land line and office number. In abstract terms these represent telephone numbers. So we split the customer table in to two tables one is the customer table and the other is customerphone
and built a relationship between them.

Figure: - Remove Duplication

Below is again one more scenario where we have an invoice class which has two methods (“GenerateInvNo” and “CreateInvNo”) and they do the same thing, generate unique
invoice numbers. We can refactor / improve the code by combining these two methods in to one.

Figure: - Code Duplication

No Code is perfect it has to be made perfect
What is a feature in Feature Driven Development?
Feature is a process which adds value to the end customer and it can be planned. In short it has two characteristics:

We can plan and schedule a feature.

It should be something that delivers value to the end user.

Figure: - Feature

In short it’s not necessary that a feature maps with use case or a user story. It should also be planned and manageable. Feature are delivered in a given time box (we will discuss this in detail
in the coming sections).

FDD is an iterative methodology to deliver projects. Rather than delivering projects in one go manner we deliver the features with in time limits. So let’s understand how the FDD cycle moves. We
will have two views one is the over all flow and one is the detail iteration flow.
Below figure ‘Structure of FDD project’ shows step by step approach for FDD project.

Identify the features: - In this phase we identify the features in the project. Keep one thing in mind features are not simple user point of view requirements; we should be
able to schedule a feature.

Prioritize the features: - Big bang theory thinking is bad. Many project managers think deliver everything at the first step itself, but that’s practically difficult. Rather
deliver first the most needed functionalities, then needed and then so called as over the top cream functionalities. To deliver in feature by feature manner we need to prioritize the feature
list from the user’s angle.

Define iterations and time boxes: - The first thing which must have clicked your mind is we should deliver in group of features, but that’s not the case in FDD. We deliver
according to the size of iteration. Iteration is based on “timeboxes” so that we know how long iteration is. Depending on the timeboxes the features can be delivered or not is decided.
The below points are looped for every iteration (below sections are covered in more detail in the coming up section).

Plan Iteration: - At the start of every iteration we need to plan it out, how we are going to execute the plan.

Create release: - We code, test and deliver according to the plan chalked out in “Plan Iteration” phase.
If everything is ok we move ahead if not we take the next iteration

Figure: - Structure of a FDD project

The above defined FDD cycle is an overall view. Let’s go deep in to how every iteration will be executed. Below figure ‘Steps in Iteration’ shows how an iteration execution happens in a detailed
manner.

Iteration Kick Start: - The length of iteration is already defined but just in case you want to validate it, then this is the phase.

Plan features for the iteration: - This is the phase where we prepare our WBS. We map the features to work packages in WBS. This plan has to be accepted by the end user.

Study requirements: - In this section we write detailed requirement document / user story or use cases.

Design Architecture: - This is the phase where we chalk out the overall architecture of the iteration and features.Once the design is done we review the architecture any issues we iterate to
close the review.

Write test plan: - Before we start coding we write test plans to validate the features of the iteration.

Execution: - We do the coding according to the design decided in the design phase of the iteration.

Testing: - Once the execution is done we run the test plans written in the ‘Write test plan’ phase. In case of any failures we move back to execution and fix the same. We also run the
acceptance test plans from the user angle at this phase.

Deploy: - Finally we are done and we deploy the same at the end customer premises.

Next Iteration: - In this phase we analyze what features we have delivered and if not we pass it on to the next iteration. If everything is fine we take up the next iteration.

Figure: - Steps in a Iteration

Testing is done at end of each iteration. This ensures frequent checks on each deliverable of every iteration.

Every iteration in FDD has to be limited to some kind of timelines. Deciding the length of timelines for every iteration is termed as time boxing. Same has been explained the previous question in
a detailed manner.

Iteration in XP is small i.e. between 1 to 4 weeks. This iteration sounds good for smaller projects, but when it comes to large projects, iteration go in months. That’s where FDD comes under
picture. Iterations in FDD can go in months and probably years.

SCRUM is a methodology which believes rapid changes of customer can not be solved by traditional approach. So it adopts an empirical approach where it believes problem can not be understood or
defined. Rather concentrate on the team’s ability to respond to the emerging requirements.

Before we understand the SCRUM cycle let’s get familiar with some terms regarding SCRUM.

Product Owner is the end customer or the user.

Product back log is a list of prioritized items to be developed for a software project.

Sprint is the task breakup of product catalog. It’s the detail task break down for a development team.

Below figure ‘Product Catalog and Sprint’ shows a typical product catalog broken in to sprint. In the left hand side of the figure we have shown two items in the product back log “Create
Customer” and “Create Supplier”. To complete “Create Customer” the developer need to the following sprint task “Code Business Logic”, “Design UI” and “Prepare Test Plans”.

SCRUM has some different terminologies when it comes to role names in SCRUM. Below is the list of roles with what actually they mean.
People with pig roles are those people who are committed to the project. If the project fails it affects these people. So of the pig roles are developer, customer, project
manager etc.Product owner means the end customer or user.Scrum master is the process driver. These are the people who drive the scrum process. They are consultants for Scrum process.
People with chicken roles work indirectly on the project. They do not really benefit from the project but their feedback is valuable to the project. They can not be held
responsible if the project is not successful.

DSDM has three basic phases Pre-project, Project life cycle and Post project phase.

Pre-project phase: - In this phase project is identified, project funds are allocated and commitment from all stake holder is ensured.

Project life cycle phase: - This is the most lengthy and detail phase in DSDM. This is where all actual project execution happens. This phase is explained in a more detail
manner in the coming section.

Post project phase: - In this phase system is operating smoothly. The main activity conducted in this phase is maintenance, enhancement and project defect fixes. Maintenance,
enhancement and defect fixing can be viewed as iterative and incremental nature of DSDM.

Feasibility Study: - During this stage the can the project be used for DSDM is examined. For that we need to answer questions like "Can this project fulfill business needs?",
"Is the project fit for DSDM?" and "What are the prime risks involved in the project?".

Business Study: - Once we have concluded that the project has passed the feasibility study in this phase we do a business study. Business study involves meeting with the end
customer/user to discuss about a proposed system. In one sentence it’s a requirement gathering phase. Requirements are then prioritized and time boxed. So the output of this phase is a
prioritized requirement list with time frames.

Functional Model Iteration: - In this phase we develop prototype which is reviewed by the end user.

Design and Build Iteration: - The prototype which was agreed by the user in the previous stage is designed and built in this stage and given to the end user for testing.

Implementation: - Once the end user has confirmed everything is alright its time to implement the same to the end user.

Lean software development has derived its principles from lean manufacturing.
Below figure ‘Principles of LSD’ shows all the principles.

Figure: - Principles of LSD

Let’s understand in brief about the principles.

Eliminate waste: - Only deliver what’s needed to the end user. Anything more than that is a waste. In short anything which does not add value is a waste. In short we can by pass
tasks and still deliver then it should be bypassed.

Decide as late as possible: - Software systems are complex. The more they are near to execution more is the clarity. So delay decisions so that they can be based in facts rather
than assumptions. For instance your team decides to use automation testing, but when you complete execution you come to know changes are delivered every day by the developer. After execution you
conclude manual testing is the best option. Bad part will be if you have already bought an automation tool, its waste of money.

Deliver as fast as possible: - faster a product is delivered, faster you will get user response and faster you can improve in the next iteration. The concept is not fast coding,
but try to deliver is small user identified chunks for better understanding.

Motivate team: - Team members are the most important aspect for success of any project. Motivate them, given them roles; keep your team spirit high and whatever you can do to
make them feel good in the project. A highly motivated team delivers project on time.

Integrity: - Software system should be delivered in loosely coupled components. Every component or module can function individually and when integrated with the project it works
perfectly well. It should be a plug and play from the end user point of view. This spirit is derived from how actual production system work. You can assemble a car with wheels from one
organization and seats from other organization.

ASD (Adaptive Software Development) accepts that change is a truth. It also accepts in principles that mistakes can happen and it’s important to learn from those mistakes in the future. Below
figure ‘ASD Cycle’ shows three important phases in ASD.

Figure: - ASD Cycle

Let’s understand all the three phases in a detail manner.

Speculate (nothing but planning):- This is the planning phase of ASD cycle. Below figure ‘Speculate’ shows in detail what happens in this phase.

Define Project Scope: - This is the first phase in the main speculate phase. In this we set the main goals and what’s the scope of the entire project.

Set Time for Scope: - Timelines are decided for the scope identified in the previous phase.

Decide the number of iterations: - Depending on the time lines and the scope we identify how many iterations will the project have.

Break Scope to tasks: - In this section we break the scope in to tasks. Tasks are nothing but development activity which a developer has to do to complete the scope.

Assign task to developers: - Assign those task to developer.
Now that we know who will do what task, its time for coding / execution.

Figure: - Speculate

Collaborate (coding / execution):-Execute as per the task and test it.

Learn (Review and give feedback to planning):- At the end of iteration see what lessons we have learnt and apply the same for the next iteration.

Note

From all the methodologies shown above, XP is the most used for Agile. One of the important points to be noted about all the XP methodologies described above is that every body believes in
accepting change. Principles of all the agile methodologies are more or less same. So do not get confused just understand what every methodology concentrates on. For instance FDD plans around
features, Scrum uses product owner and catalog for describing a project, DSDM gives importance to RAD. So understand the main theme of the methodologies but yes the common acceptance is every one
believes on ‘Accepting Changes’.