We are living in a fast-paced world where Maggi cooks in 2 minutes, and pizza delivery happens at your doorstep within 30 minutes. So, why not make our learning fast-paced! Here, I bring you my secret recipe on Agile Methodology, which will give you all the ingredients, you need to get started on Agile. Additionally, we will trace it right from its origins to the most advanced topics. We got it all on the platter!

Let’s get started.

In this article, we are going to cover:-

• What is Agile Methodology?
• History of Agile
• Agile Manifesto
• Principles of Agile Methodology
• Agile Terminologies
• Advantages of Agile Methodology
• Agile Frameworks
  • Scrum
  • Lean
  • Kanban Software Development
  • Extreme Programming (XP)
  • Dynamic Systems Development Method (DSDM)
  • Feature Driven Development (FDD)
  • Crystal
• Comparative Analysis of Different Agile Methodologies

What is Agile Methodology?

According to the dictionary, it is an adjective that means to move quickly & easily. Its application is no different from when organizations use it.

Agile methodology is a set of values and principles that ought to be followed to become Agile.

It is an approach to software development where team interaction, customer collaboration, and responding to change are the key themes. In addition to that, Agile methodology provides us with a framework where continuous improvements happen at different stages of the software development life cycle.

Let's trace back the roots from where it popped up.

History of Agile Methodology

The legacy of Agile methodology sprung from the buzz word “continuous delivery”, which was only a dream in traditional models of software development like Waterfall, V- shape model, etc.

In the early 1990s, as computers began to enter in the organizations, software development faced a crisis named - "the application development crisis", or "application delivery lag". Which, in turn, meant that the time between a validated business need and an actual application in production was on an average of about three years. And it was HUGE. By the time project coding & implementation happened, following things surfaced:

• The requirements of the customer changed OR
• The value of the product diminished. Therefore, the entire process proved too costly.

The waterfall model could not cope up with the changing market needs and often led to costly failures for big sized projects.

Hence, the frustration of thought leaders and the dire need for something that was timelier and more responsive gave birth to a methodology based on Values & Principles – called – Agile Methodology.

As depicted in the picture above, the Waterfall model gives a lack of confidence in the team because it tends to pile. Which, in turn, leads to low morale among the team members. Therefore, the entire project appears to fall apart due to constant changes in the intrinsic and extrinsic forces.

Whereas in Agile Methodology, the entire project is finished in mini-projects so the team has better control over the deliverables and the team morale remains high. It, in turn, leads to high ROI.

Let’s look at the Agile Manifesto.

Agile Manifesto

In 2001, a small group of software gurus, tired of the traditional approach, got together and wrote a manifesto which became a guiding principle for Agile Software development.

The Agile Manifesto's core statement says: - "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

"In other words, it means that, while there is value in items on the right, we value the items on the left more"".

Let's translate the above core statement in a diagram that's easier to relate to: -

Comparison between Agile methodology & the traditional way of doing a project shows us that Agile methodology is an iterative method of doing a project which involves customer collaboration. In addition to this, it is highly flexible to change.

Whereas, the traditional way of doing a project involved following a predefined plan that was not adaptable to changes. Therefore, it leads to deteriorated business value to the client.

Principles of Agile Methodology

Following are the 12 main principles in Agile methodology: -

1. Customer satisfaction through early and continuous delivery of useful software - It means letting the customer know the progress by the distribution of values to the customers. Which, in turn, is achieved by fulfilling the highest priority requirements first.
2. Welcome changing requirements, even late in development - This implies flexible adaptation to the changing needs of the customer. In addition to this, providing them a competitive advantage to external changes.
3. Frequently Delivered Software (weeks rather than months)- This provides immediate value to the customer by delivering working features timely.*
4. Work together - i.e., Close and daily cooperation between Business people and Developers by keeping documentation and requirements lightweight.
5. Trust and Support - Projects are successful around motivated individuals who should be trusted.
6. Face to Face conversation - Oral communication is preferred to rule out any discrepancies and be on the same page.
7. Working Software - It is the primary measure of progress and should be delivered timely.
8. Sustainable development - Agile methodology maintains the work-life balance among the team members and promotes happiness by avoiding exhaustion.
9. Continuous Attention- Means consistent attention to technical excellence and good design enhances the agility of any team.
10. Simplicity - It is the art of maximizing the amount of work not done—is essential. It uses the Pareto principle or the 80/20 rule that says that typically 80% of your results may come from only 20% of your efforts.
11. Self-organizing teams - The scrum team has autonomy and responsibility to meet the goals of the sprint.
12. Reflect & Adjust - At regular intervals team reflects on how to become more productive and then adjusts accordingly. The retrospective meetings ensure the implementation of the lessons learned during the project into the next iteration.

Agile Terminologies

Unlike the waterfall model, in Agile methodology,  both development & testing activities go hand in hand.

Below are the Agile terminologies that are used to refer to the customer requirements, steps, and solution offered to the client: -

4

The above picture depicts the Strategy & Execution Model in an Agile project. Here-

• Each level represents a strategic goal that has to finish in different periods.
• Story Level Items (part of Strategy) include Tasks & Stories;*
• In addition to the above, Portfolio Items (part of Execution) includes Features, Initiative/Epic & Theme.
• A task may take hours or days to finish;
• Whereas a feature may require weeks to get completed.
• Moreover, the upside-down triangle on the right depicts this timeframe.

The main characters in a general Agile methodology are as below. A thorough understanding of these terminologies & definitions is necessary before proceeding further.

• Product backlog: a list of requirements provided by the customer in the form of Epic, Features, Stories, etc. generally captured in an excel sheet format.
• Epic: Large level requirements/ needs of the business.
• Features: Divisions of Epic, precisely defines the needs of the customer.
• Stories: It refers to the detailed definition of each requirement/ Feature.
• Tasks: Defines the solution of each Story. They are the actions taken on “Story”.

To explain Epic, Story & Tasks further, let's exemplify them in the below way, whereby:-

Consider that a customer wants to build an online shopping platform where users can buy clothes for all ages. The online shopping platform will develop in 2 Releases – The Core functionalities will go in Release 1, and Release 2 will feature the rest of the backlog items.

Epic is a big story that will help the end-user to resolve a business problem. e.g., As a registered user, I should be able to buy clothes using various payment options. If you carefully look, you will see that this talks about “registration”, “payment options”, and “buying”. Epics can span across Releases, so in current, e.g., we can have Credit Card payment in release 1, while PayPal or bank transfer can be in release 2.

Features define the characteristics of the product. A Feature needs to fit in a single release, though it can span across multiple Sprints. e.g., for the above Epic, the Features can be defined as “User Registration”, “Payment Via Credit Cards”. “Payment Via PayPal”, etc.

Stories are smaller pieces of functionality, and they directly map to an epic. The story needs to fit in a single sprint. e.g., for User registration Feature, we can have the following stories:

• Story 1: As a new customer, I should be able to Register on the website using my First Name, Last Name, Email ID, and Password
• 2nd Story: As a new customer, I should be able to register to the site using my social credentials (Facebook, Google, and Twitter)
• Story 3: As a new customer, I should be aware of any errors that need to be corrected while filling up the registration form

Tasks: Tasks define the actual work that needs to be done to complete a story. Usually, to complete a story, we may need the help of multiple members of a Scrum Team. Therefore, a Story is divided into tasks, and the assignment of each task to one member happens. Once all these tasks finish, we can mark the story as “Done” or “Completed”.

Story: As a new customer, I should be able to Register on the website using my First Name, Last Name, Email ID, and Password.

Development Tasks: - Some of the typical development tasks can be:

• Task 1: Create a UI Form that can accept First Name, Last Name, Email Id and Password fields
• Task 2: Create a Backend DB table, that can store customer information
• 3rd Task: Password Encryption
• Task 4: User Registration API

QA Tasks: - Some of the typical QA tasks can be:

• Task 6: Create test cases for the story
• Task 7: Create Automation Scripts for the story
• 8th Task: Execute functional test cases
• Task 9: Identify and Create test data required for the story

Advantages of Agile Methodology

There are several advantages of using Agile methodology. Let's have a look at them below: -

1. Enhanced Quality - Firstly, since the integration of testing happens during the cycle, there are regular checkups to see that the product is working during the development. Therefore, it enables the Product Owner to make changes as and when needed.
2. Better Customer Experience - Secondly, there is continuous interaction between stakeholders and the team during the entire Agile process. It enables the team to understand the client's vision and produce high-quality products. It, in turn, helps in gaining customer's trust and increased satisfaction.
3. Transparency - Thirdly, the entire project in Agile methodology involves regular client meetings, and all the other details are transparently available to all the team members.
4. Early & Predictable Delivery - In addition to the above, since sprints occur on a fixed schedule (1- 4 weeks), it's easy to predict the timing of project completion and can save on costs too. Therefore, the product owner can review the deliverable as early as within three weeks, and he can provide feedback if something has not gone according to his expectations.
5. Ease of doing transactions - Moreover, Scrum methodologies allow for flexible adaptation to the changing customer requirements. A continuous reprioritization happens by refining the Product Backlog and adapting to the new customer needs.
6. Continuous Engagement - Finally, the Iterative nature of Agile methodology implies that the features are delivered incrementally. It happens by continuously keeping the team and resources engaged in what they are best.

Agile Frameworks

Since we have now fully equipped ourselves with the basics and principles on which Agile teams work, let's have a look at different frameworks that follow principles of Agile methodology.

All Agile methodologies work on the above model that mainly depicts how sprints run one after another. They all follow a "plan-design-build-test-review" approach.

But from an implementation standpoint, every methodology has its own set of practices, terminologies, etc.

Eg. Think of your product as chicken curry, which has all sorts of different flavors in it.

The way it’s prepared will be different for each chef – these different ways are like different Agile methodologies. The result is the same, but the process and effectiveness will be different for each one of them.

We have summarized some of the primary Agile methodologies and will try to explain the below to you:-

1. Scrum
2. Lean
3. Kanban Software Development
4. Extreme Programming (XP)
5. Dynamic Systems Development Method (DSDM)
6. Feature Driven Development (FDD)
7. Crystal

Scrum:

What is Scrum?

Scrum is one of the most commonly used Agile methodologies. Scrums have gained popularity within the Agile software development community because they are simple and have a proven productivity rate.

Scrum focuses on Team. It is a method that concentrates specifically on how to manage tasks within a team-based development environment. Scrum believes in enabling & empowering the development team and suggests working in small teams (say- 7 to 9 members).

Principle of Scrum

The fundamental principle of Scrum is that by dividing time and projects, you can enhance an organization's effectiveness and productivity.

Scrum makes the process of development less complicated by making the information transparent. Which, in turn, helps the team to overcome the disadvantages of waterfall model like

• Under & overestimation of time
• Lack of progress report
• Inability to adapt to changes, etc.

Scrum Artifacts:

We will try to comprehend it with the help of an example. If you have to construct your house, what would be your strategy? First, we will make the list of all requirements as below-

• Buy a piece of land/ empty plot
• Hire an architect
• Get the map of the house passed
• Hire contractor
• Buying construction material
• Hire labor to construct
• Suggest customizations

This list of requirements is known as “Product Backlog”.

Now, the architect confirmed that they would come over for the discussion on Week2, Day 1 from today so you will start prioritizing your tasks from the above list and put some timeline around it. e.g. -

• Week 1 – Finish the purchase of the land, registry, considering legal formalities, etc.
• Week 2, Day 1 – Meet architect, list your design requirements.
  • Day 3 - finalize the design, suggest modifications
  • Day 5 - pass the map
• Week 3, Day 1 - hire contractor, share the house design
  • Day 3 - get estimated material needed from the contractor
  • Day 5- buy the material
• Week 4 - Construction starts

You may like to capture these activities along with timelines in a separate document. Which, in turn, will ensure the timely completion of all the activities. This document is known as "Sprint Backlog". Whereas, the process of defining objectives to achieve is known as "Sprint Goal" or "Increment" in Scrum. For example – for Week 2, Day 1, you kept an objective to meet the architect & finalize the design. It is Increment.

Roles and responsibilities in Scrum:

It consists of three positions, and their responsibilities are as follows:

Scrum Master:

The Scrum Master is responsible for making sure that the Scrum Team adheres to the values and principles of Agile methodology. Additionally, the scrum master ensures the adherence to the processes and practices that the team agreed they would use. The responsibilities of a Scrum Master include:

• Clearing obstacles
• Establishing an environment where the team can be effective
• Addressing team dynamics
• Ensuring a good relationship between the team and the Product Owner as well as others outside the team
• Protecting the team from outside interruptions and distractions.

Product owner:

The Product Owner in a product development team is responsible for managing the product backlog to achieve the desired result that a team seeks to accomplish. Key activities to accomplish this include:

• Clearly expressing Product Backlog items.
• Ordering the items in the Product Backlog to best achieve goals and missions.
• Optimizing the value of the work the Development Team performs.
• Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next.
• Ensuring the Development Team understands items in the Product Backlog to the level needed.

The creation of the Product Owner role as part of the Scrum framework happened to address the challenges that product development teams faced. For instance, multiple & conflicting directions or no direction at all concerning what to build.

Scrum Team:

Scrum Team is also known as the “Development team”. It usually consists of Developers. Testers, Designers, etc. They are the ones who work on Product Backlog items. According to the Scrum Guide, the scrum team should be between three to nine people and should have all the skills necessary to deliver the product. Below are some of the main characteristics of the Scrum Team:

• Scrum Teams are self-organizing. They decide how to turn the backlog into a potentially releasable functionality.
• Development teams are cross-functional, with all the skills necessary to create the product increment.
• Scrum Team doesn’t give any titles to the development team, regardless of the work they perform.
• Scrum team doesn’t recognize any sub-teams, regardless of cross-domain folks that are present (e.g., BA, tester, developer, etc.)

Process of Scrum:

By now have a fair bit of understanding about Artifacts of Agile methodology as well as various roles in the Scrum process. Therefore, let’s try to familiarize ourselves with Scrum Process Flow.

1. Product Backlog- Here, the Product owner meets the client and takes down all the requirements. A document referred to as Product Backlog captures these requirements.
2. Sprint Backlog – Now, the Product Owner shares this Product Backlog with the Sprint team (consists of Scrum Master, Developers, and testers) in a meeting referred to as the “Sprint Planning” meeting. In sprint planning, the entire team agrees to complete a sub-set of product backlog items. This agreement is called the Sprint Backlog & its basis the team’s velocity/ capacity & the length of the sprint. The vital point to note here is, once the team has finalized the Sprint backlog, they cannot change it within the Sprint. If any change is required, it either goes to the next sprint, or the cancellation of the current sprint happens.

For instance, the team may decide to release software in 3 iterations (each iteration is referred to as “Sprint” in the world of Scrum)

• First Iteration– Story 1 and 3 will be released (Sprint 1)
• Second Iteration - Release of Story 2, 4 and 6 will happen(Sprint 2)
• Third Iteration – Story 5 will be released (Sprint 3)
• Daily Scrum- The Scrum Master conducts a daily meeting of the duration of 15 minutes with the Sprint team to ensure progress is on track. This meeting is “Daily Scrum”. It broadly discusses the below pointers-
  • What did you accomplish since the last meeting?
  • What are you working on until the next meeting?
  • What's getting in your way?
• Sprint Review- At the end of each phase or “Sprint” – Scrum Master organizes a meeting referred to as the “Sprint Review” meeting. In this meeting, the Product owner reviews the product and assess whether the product is as per client expectations or not. It is an informal meeting & is kept to less than 4 hours a week for a 4-week sprint.
• Sprint Retrospective meeting is conducted to discuss “What went well during the Sprint” and “What needs improvement”. This meeting takes place after the sprint review but before the next Sprint Planning Meeting. Its duration can be of a maximum of 3 hours for a 4-week sprint.

Applicability of Scrum:

In the complex situations where the outcome is unknown at the beginning, and the approach should be to adapt & evolve in the process. Scrum works on a time-boxed iterative approach. The main focus of this approach is working incrementally rather than all at once.

Lean Software Development -

What is Lean?

Lean is about developing a project smartly by focusing on what the customer wants and eliminating the non-value adding activities in the process. In other words, the lean methodology emphasizes on excluding the features that are not valuable to the customers and then prioritize & deliver them in small batches.

The value can be added by:-

• Eliminating waste
• Increased learning
• Delivering end product as soon as possible

History of Lean:

In the 20th century, a manufacturing giant called Toyota faced issues with its long production and manufacturing chains. Hence, a solution called the Toyota Production System was devised, which focused on eliminating waste activities from the manufacturing cycle. Later, it got renamed to Lean manufacturing.

In 2003, its implementation happened in the Software industry. Its leading proponents were Mary & Tom Poppendeick, who compiled the principles of Lean in a book called “Lean Software Development”.

Principles of Lean:

The main principle of Lean is to deliver high-quality products in minimum time with the least wastage of resources.

The division of Lean principles happens into two categories – Main Principles & Lean Software Development Principles, which are a derivation from the core principles of Lean.

Let’s discuss Lean Software Development Principles below

• Optimize the whole – To be effective, you have to look at the bigger picture and develop a system that focuses on individual parts of a project along with the smooth functioning of the entire system.
• Eliminate waste – Waste (as discussed later) can be understood in “Lean terms” as the non-value adding. Hence, the focus should be on intentionally reducing the non-value adding & unnecessary activities.
• Build Quality In – This means developing an automated and standardized system that foolproofs it from any human error.
• Deliver Fast – The faster we deliver to our customers, the quicker we will get the feedback and work upon it.
• Create Knowledge – This means all the learnings and findings learned during a project should be documented so that they can be shared with others as well.
• Respect People – This boils down to understanding that each entity is equally essential in the success of any project. One should treat customers, colleagues, employees with equal respect.
• Defer Commitment - This is a basis just in time philosophy, i.e., teams should responsibly wait and collect enough information before making any decision.

Lean Artifacts-

• Value-Add activities –are all the activities that physically improve a product or a service for customers. Which, in turn, means they are those activities that add value!
• Non-Value Add (NVA) activities – are activities that do not add value but undergo execution. The Customer has to bear the cost of NVA, and since it is not a value add, a customer doesn’t want to pay for it.
• Waste: Anything that doesn’t bring value to the table is referred to as waste & eliminating it is the core of Lean thinking.

Toyota Production System’s forefather Shigeo Shingo identified seven major wastes in the manufacturing process. Which, in turn, were later translated into 7 Wastes of Software Development, by Mary & Tom Poppendick.

They are:-

1. Partially Done Work
2. Extra Features
3. Relearning
4. Handoffs
5. Delays
6. Task Switching
7. Defects

Difference between Lean and Scrum:

• Lean is not a time-bound approach, unlike Scrum, where you have to finish an iteration in 2-4 weeks.
• Lean is a philosophy or a mindset, whereas Scrum is a framework.
• In Lean, you can select, plan & implement only one feature before you repeat this process for another feature, unlike scrum.
• Scrum uses a visual workflow called Scrum Board, unlike Lean.

Kanban

What is Kanban?

A Toyota engineer Taiichi Ohno invented the Kanban framework. The Japanese word "Kan" means "Visual" & "Ban" means "Cards". Hence, Kanban focuses on a visualized workflow where work is broken down into smaller tasks and displayed on the Kanban board. It helps in maintaining transparency in the team.

Principle of Kanban:

There are three main principles on which Kanban works:-

1. Visualizing what you do
2. Cap the Work-In-Progress activities
3. Enhance the flow by pulling the next most prior thing from the backlog
4. Continuous Improvement by inspecting blockers and adapting to the ever-changing conditions, resources & customer demands.

Process of Kanban:

Before we discuss the basic Kanban process, let’s first understand what a basic Kanban Board consists of:-

• Columns – Each column represents the progress status, e.g., “To-Do”, “Doing”, “Done”.
• Visual Cards – the Main feature of any Kanban board is Stickies, cards, etc.
• WIP limit – Maximum number of cards that are workable at any point in time.
• Commitment Point – The step where tasks are picked up from Stories/ backlog.
• Delivery Point – It is the point where the end customer gets the final product.

A Kanban board can be more detailed in terms of the information provided through columns. e.g., In the image below, "Assignee" & "Archive" columns are also added to further detail the process. It implies that depending upon the need, the enhancement of the complexity of any Kanban Board takes place by adding more columns into it.

Let's now try to understand the Kanban workflow with the help of an example from our testing world:-

• First, the user requirements are collated & collected in the form of a Product Backlog. After that, the curation of a Kanban Board happens, which has stickies on it – a visual representation of tasks.
• After that, say our story is to “test a product” then various tasks under it can be Design, Development, and Test case creation, Test Execution, etc.
• Finally, these tasks are pulled from the backlog/stories & moved to the “To-Do” column; it is the Commitment Point.
• As soon as, the team starts working on a particular task, it moves to "In-Progress".
• During the process, capping of the maximum number of tasks that can be carried out at any given time happens. It is known as the WIP limit.
• As soon as the tasks finish, they move to the next column, "Done". It is a Delivery Point.

Advantages of Kanban:

Following are the main advantages of Kanban:-

1. Flexibility - Firstly, this means there are no prescribed phase durations, and priorities are reassessed continuously based on the most recent information.
2. Continuous Delivery - The Second advantage is delivering small portions of a project continuously to the customer. Which, in turn, helps in synchronizing the future iterations with the updated business requirements.
3. Reduction of Waste - Thirdly, the Kanban system focuses on the reduction of waste in all its forms: over-production, unnecessary motion, defects, over-processing, and waiting. In terms of software development - Work that is not needed, incorrect work, etc.

Difference between Kanban & Scrum:

Even though Kanban and Scrum work on Agile methodology, there are places where they differ.

• The time-boxed sprints are optional in Kanban, unlike scrum where iterations are time-bound to 2-4 weeks.
• Work is pulled from the backlog, as a single unit, as and when needed, unlike Scrum where we pick up batches of work from the product.
• In addition to the above, the client can add new features during an ongoing iteration, unlike Scrum, where no addition of new features can happen once an iteration starts.
• Multiple teams share the Kanban board.
• Moreover, there are no defined roles in Kanban like Product Owner (PO), Scrum Master (SM) or Scrum team, etc.

Extreme Programming (XP)

What is XP?

Kent Beck developed this, and it has evolved as a highly disciplined method of continuously delivering high-quality software. XP methodology works on five core values as discussed below:-

• Simplicity – First is Simplicity. Which in simple words means avoiding the waste and only doing what’s needed & asked.
• Communication – Second is Communication, which means having face-to-face communication to clear any doubts. In other words, it means to be on the same page.
• Feedback – Third is Feedback, which means providing constructive feedback, which is workable for future improvements. One can achieve this by focusing on the changes needed & implementing them.
• Courage – Fourth is Courage, which means adapting to the changes & not making excuses for the failure. In addition to this, being truthful about the estimates & progress of the project.
• Respect- Fifth is Respect. This means everyone deserves respect as an individual team member.

Practices of XP:

The below image depicts the 12 practices on which XP works. These are mutually inclusive of each other meaning all these practices work in conjunction to deliver effective & efficient products.

Let’s discuss these practices further:-

1. Pair Programming – It implies two team members sit on the same computer & work together. The driver writes the code & the observer reviews each line of code when it's written. This, in turn, helps in quick identification of areas of improvisation.
2. On-Site Customer – The XP customer is highly engaged with the team & is available on-site to provide regular feedback.
3. Test-First – Implies testing the code first & then running it later after fixing the bugs. It helps in reduced effort & less number of errors during the production.
4. Iterative Development – It is also known as incremental design which means doing work in small increments & building it up further.
5. Refactoring – Its primary focus is to remove the duplication of various processes.
6. Simple Design – Keeping the system design as simple as possible will ensure the smooth running of the process.
7. Planning Game – The stories are used to describe end-user requirements & the planning process.
8. Coding Standards – Establishing standardized rules of code for all of the team members.
9. Continuous Integration – This means testing of small codes happens immediately before adding them to a more significant project. It ensures that error detection happens early on.
10. 40- Hour week – As the name suggests, every team member is required to work for 40 hours a week. Therefore, maintaining a work-life balance.
11. Collective code ownership - This means everyone owns the code in the team & that everyone is allowed to exert a "positive" duty to make the changes to the code as necessary. Hence, it reduces the dependency on any one developer.
12. Metaphor – This means a simple layman explanation of how the code works, i.e., the ability to explain the system to the new people without flooding them with technical terms.

Process of XP:

The process of XP is as below in the form a diagram:-

• Planning – The first stage of the process is to start collecting the requirements from the customers in the form of user stories. The value of each user story is then estimated, which should roughly help the team to understand how long it will take to implement a story. XP practices used here are:-
  • Planning Game
  • On-Site Customer
• Design – Second is Design. Having a simple design of a system ensures fewer dependencies & early deliveries. The addition of any extra functionalities can happen later as well. Additionally, if some stories need more research in terms of technicality, a short time-boxed period is assigned called Spike. XP practices used here are:-
  • Refactoring
  • Simple Design
• Coding – Third is coding. This is the core of any process. The actual coding of software starts here. In other words, the team sits together & starts working incrementally to deliver the end product. XP practices used here are:-
  • Pair programming
  • Collective code ownership
  • Coding Standards
• Testing – Towards the end, the code is tested first & run later, after fixing the bugs.  Following practice supports it
  • Continuous integration
  • Test first
  • Iterative development
• Release – Finally, the customer valued product is released & project velocity is computed to keep a tab on the progress. Measurement of Project velocity happens, which is a quantifying criterion of the amount of work accomplished in a project.

Advantages of XP:

Following are the main advantages of XP:-

1. Time-saving - Firstly, it allows the organizations to save time required for project execution because XP focuses on the timely delivery of final products.
2. Cost-Effective - Secondly, XP saves a lot of money because they don’t use too much documentation. They usually solve problems through discussions inside of the team.
3. Simplicity- Thirdly, the developers create a straightforward code that they can improve at any moment.
4. High Visibility - Finally, the whole process in XP is visible and accountable. Developers commit what they will accomplish and show progress.

Difference between XP & Scrum:

Following are the main differences between XP & Scrum:-

1. Scrum works on iterations which are 2-4 weeks long whereas XP iterations are 1-2 weeks long.
2. Scrum doesn't allow changes in the sprint once started. Unlike XP, which enables the introduction of new features. These features can replace a feature on which the work is yet to begin.
3. XP works on strictly high priority, unlike Scrum.
4. XP prescribes engineering practices like refactoring, simple designs, pair programming, etc., unlike Scrum.
5. Roles in XP are the customer, the developer, the tracker & the coach, unlike Scrum, where the primary roles are of SM, PO & Scrum team.

Dynamic Systems Development Method (DSDM)

What is DSDM?

The Dynamic Systems Development Method (DSDM) is a simple and straight-forward Agile framework that works best in case of fixed time and resources and varying functionalities. DSDM uses the 80-20 rule i.e., 80% of system deployment in 20% of the time.

Principle of DSDM:

There are nine principles in DSDM which are more like a way of working to deliver efficient end-products.

The eight Principles of DSDM are as follows:

1. Focus on the business need – Maintaining the focus on the business requirement is vital. It means ensuring the alignment of the projects with the business objective.
2. Deliver on time – Frequent and timely releases help in the early detection of errors.
3. Collaborate – Teamwork basis trust and honesty lead to effective production, which also helps in quicker resolution of various issues.
4. Never compromise quality – Delivering a quality product is the main focus.
5. Build incrementally from firm foundations – One can achieve this by breaking a more significant task into smaller tasks. The development of the most critical tasks happens first.
6. Develop iteratively – Acclimatization of the changes becomes easy using the Iterative model of development. It helps in reversing / updating already built products.
7. Communicate continuously and clearly - Empowered teams that work co-operatively are more efficient, productive & communicate better with each other.
8. Demonstrate control – DSDM aims at having small-sized teams with a high degree of communication between them and in turn, an efficiently integrated & controlled structure.

Process of DSDM:

As we already got a fair amount of understanding on various phases of DSDM process so let's deep dive into it and understand it in more detail as well as diagrammatically-

1. Pre-Project – This phase occurs before the actual project starts. Here, the conceptualization of the project happens, and the decision making happens whether to start up the project or not. Following are its main objectives:-

• Identify the problem
• Check the scope of the project
• Chalk out a plan

2. Feasibility Study –This means whether the project is workable & how is it possible. Following are its main objectives:-

• To analyze various estimates like costs involved, timelines, resources available, etc.
• Deciding whether the project is workable or not.
• To determine the approach of working
• Intentionally keeping it short helps because DSDM works best in short time frames.

3. Foundation/Business Study – Here, the team researches the business aspect of the project like which technology to use, what should be the workflow, etc. Following are its main objectives:-

• First, define a high-level requirement on a macro level
• Second, define the working solution of the project
• Third, considering the customer, management & solution perspective to deliver a robust end-product

4. Evolutionary Development Phase – Also known as Functional Model Iteration, here the construction of Functional Prototypes (FP) of the system happens. FP means a prototype of the different functions that the system will perform. Following are its main objectives:-

• First, to create a functional prototype of the actual product.
• Second, to provide a detailed requirement for the final product.

5. Deployment Phase – Also, known as implementation & incremental delivery stage. Here, the designing & development of the product happens incrementally and delivered after documenting whether the project has all the requirements as desired. Additionally, the training of end-users happens on how to use the system & after that, it gets approval. Following are its main objectives:-

• Provide required documentation
• Act as the primary review point
• Provide training to the users
• Assess whether the current product meets the project requirements or not.
• Expand the scope of the design prototype to suit the final requirement.

There are three sub-phases or sections within the Deployment, namely Assemble, Review, and Deploy.

• Assemble - Here, you would perform those activities required to put all the pieces together.
• Review - Here, you will make sure the things work and are approved to deploy the product. During this time you would also carry out a retrospective for the increment.
• Deploy - Here, you release the product or solution. It is when the work carried out in the iteration is made available for everyone to use.

6. Post-Project – This is the maintenance phase where regular checkups take place for the smooth running of software. Following are its main objectives:-

• Assess the deployed solution
• Provide feedback if there are any performance gaps.

I want to share an interesting fact - the approach which I took to set up my website is pretty close to the DSDM process. Let me take you back in flashback days of mine -

1. Pre-Project Phase - During my initial days of career when I was doing a well-paid job as a software tester. There is always this heated discussion in our QA forums that most of the websites related to software testing don't provide in-depth and an easy to understand content. It was a light-bulb moment for me. I realized, there is a problem which is strongly felt by colleagues, so why not make an attempt to solve it? This problem statement leads to the idea generation of our website. In DSDM terminology, it is the "Pre-Project" phase.
2. Feasibility Study - I made a rough estimate of time, cost, etc. which is required to set up this website. With the job, it was quite a daunting task to take out time. However, I liked this idea. Therefore, these things didn't act as a roadblock for me, and I moved ahead with the next step.
3. Foundation / Business Study - Next, I created a high-level plan, in terms of what all are the required skillsets for developing this website (Designer, Developer, Content Writer, etc.). I also explored various plugins, hosting service providers which I may like to use for developing my website.
4. Evolutionary Development Stage - After I gathered all the required information which is required to set up my website, I created a more detailed plan (LLP). I listed all action items in a time-bound / phase-wise approach

• Phase 1 (Jan to March) -
  • Jan 1-10 - Purchase domain from leading domain name provider, take hosting service provider
  • January 11-25 - Hire freelancer for content writing
  • Jan 26-31 - Install free plugins for my website
  • Feb 1-28 - Develop the first version of the site which has blogs related to Software Testing
  • March 1 - Launch first iteration of my website
• Phase 2 (April to June) -
  • April 1-10 - Purchase paid plugins
  • April 11-30 - Hire full-time content writer, hire a freelancer for designing, etc.
  • May 1-30 - Incorporate functionality to deliver online training, write more blogs
  • June 1 - Launch the second iteration of my website
• Phase 3.
• Phase 4.

5. Deployment Phase - Now, I have a complete list of what needs to accomplish, when & how. Next, an action-packed stage, I started building the first version of my website. After one month, when I was pretty satisfied that the website has shaped up as per my expectations from phase 1, I published it for public viewing.

6. Post-Project phase - I kept a check on the analytics of my website regularly. Additionally, I ensured all plugins work properly, and there are no compatibility issues. I took regular feedbacks from my colleagues - if there were any issues, I made a note of it so that I can take it up in my next iteration.

Difference between DSDM & Scrum:

1. DSDM works on fixed time & variable functionality unlike traditional methods of software development which worked on varying time & resources with the expectation to deliver fixed functionalities. 2.* In addition to the above, the end-user actively participates with the team in DSDM, unlike Scrum where end-users interact only with the Product Owner.*
2. Moreover, DSDM involves diligent documentation, unlike Scrum.
3. Daily Stand up meetings happen in Scrum, unlike DSDM, where information sharing happens through documents.
4. Additionally, DSDM advocates producing 80% of the solution in 20% of the time, unlike Scrum, where each iteration gets 2-4 weeks.

Feature Driven Development

What is FDD?

FDD is a design-oriented Agile process developed by Jeff De Luca & Peter Coad.

As the name "Feature Driven Development" suggests, it is the features that are nothing but small-sized projects which are in a complete state. Features in FDD are just like User stories in Agile methodology.

Principle of FDD:

FDD also works on the principles of the Agile Manifesto. It focuses on delivering client-valued features in the <action>``<result>``<object> format. e.g., register (action) the account (result) of a user (object) is a form of a feature that the FDD method uses.

Roles in FDD:

Following are the leading roles in the FDD process - Project Manager, Chief Architect, Development Manager, Chief Programmer, Class Owner, and Domain Expert.

Process of FDD:

There are mainly five steps that this process uses. The below diagram depicts the procedure followed in the FDD methodology.

1. Develop an Overall Model -The client team and development team develop an overall model. Chief Architect guides this.
2. Build a Feature List - Shortlist the features for the implementation, from the client requirements given in the first step. Each feature should complete within two weeks.
3. Plan By Feature - This means planning the features which require implementation and deciding which team will be responsible for doing it. Teams are selected & given different feature sets.
4. Design By Feature - The chief programmer designs the feature by drawing sequence diagrams. Sequence Diagram is the vertical diagrammatic representation of the sequence of different activities carried out at different times. Its objective is to track the progress.
5. Build By Feature - The Chief programmer writes the code, tests it, and checks. After that, if it's ok, it gets the approval.

Advantages of FDD:

Following are the main advantages of using FDD:-

1. Risk Reduction - FDD helps in reducing risks using shorter iterations of designing, understanding of the requirements, and the system without any ambiguity.
2. Regular Builds- Regular builds ensure there is always an up to date system. Which, in turn, the client can see.
3. Visibility of progress and results- By frequent, appropriate, and accurate progress reporting at all levels of the project, visibility is high, which in turn leads to better project control.
4. Costing the project by feature leads to greater accuracy.

Difference between FDD & Scrum:

• Unlike Scrum, each iteration has to complete within two weeks. If it is not possible, then it further breaks into smaller pieces until it meets the limit of two weeks.
• FDD chooses the best of the different methodologies in the Agile Scrum, XP, etc. & applies them.
• A feature team consists of a project manager, chief architect, development manager, domain expert, class owner, and chief programmer, unlike Scrum, which has only three roles. Namely, Product Owner, Scrum Master & Scrum Team.

Crystal

What is Crystal?

Alistair Cockburn defined Crystal as, “Crystal is a family of human-powered, adaptive, ultra-light, ‘stretch-to-fit’ software development methodologies”.

The Crystal agile framework focuses on individuals & their interactions within a system over process & tools; which is also one of the agile manifesto statements.

Crystal works on two core assumptions:-

• The team should undergo self-organization.
• Every project is unique & has its own set of conditions under which it works. Hence, only its team should decide the course/flow of the project.

History of Crystal:

Alistair Cockburn developed the “light-weight” methodology called Crystal for IBM in 1991.

Cockburn interviewed & researched numerous people who did not follow the traditional/ formal approach but still delivered practical, successful projects. Therefore, he realized that different team size & dynamics lead to varying procedures to carry on the projects.

Characteristics of Crystal:

As stated earlier, Cockburn defined Crystal as a family of human-powered, adaptive, ultra-light, ‘stretch-to-fit’ software development methodologies

• Human Powered – Means the people involved in the project are the most crucial entity & that the entire project process flow should adapt around them.
• Adaptive / Stretch-to-fit - This means crystal has no fixed process or tools. Instead, they are stretched to fit the ever-changing needs of a project & adapt to different business requirements.
• Ultra-light – It is a lightweight methodology that focuses on transparency & open communication. It does not go heavy on documentation.

Crystal Method Family Members

Cockburn discovered that the properties of a project depend on the number of people involved in the project.

The way smaller teams work inside a project can be different than the way bigger teams work on a large-scale project. In other words, the criticality & the complexity of the procedure to carry on the project is directly proportional to the size of the team.

Therefore, there is no one single Crystal method. In other words, there are different Crystal methodologies for different types of projects which depends upon the following factors:-

• Team Size ( Crystal Family as discussed below)
• Criticality ( four levels of criticality as discussed below)
• The priority of the project

Generally, different colors represent different team sizes. Which, collectively, in turn, is the Crystal Family. They are:-

• First is Crystal Clear – up to 6 people
• Second is Crystal Yellow – up to 20 people
• Then, Crystal Orange – up to 40 people
• Crystal Red – up to 80 people
• Crystal Maroon – up to 200 people

Apart from these, Crystal Diamond & Crystal Sapphire apply when there is a large amount of risk posed to human life.

Four Levels of Criticality refers to the possible amount of risk posed by a system if it does not perform as expected. They are –

• Comfort
• Discretionary Money
• Essential Money
• Life

The above diagram depicts that the larger the project gets (in ascending order of complexity) the darker the color becomes. In other words, it is illustrating the criticality of the project. For example, the L40 project refers to a project having 40 team members developing a Life-Critical project.

The Crystal methodology can be related to the different facets of a gemstone crystal. Which, in turn, means different faces of a crystal refer to the different underlying core principles & values in a crystal methodology. These facets are a representation of techniques, tools, policies & roles; which differ in different project conditions.

Cockburn differentiated the techniques, tools, etc. as below-

• Methodology – refers to the set of practices, tools, etc.
• Techniques – Refers to the skill areas, e.g., developing test cases
• Policies – Refers to the standards which any organization must-have.

Applicability of Crystal:

To conclude, Crystal methodology applies to various project/team sizes. For instance, if there is a team of six developers, then Crystal Clear is more appropriate. On the other hand, if there is a bigger team of say more than 20 people, then Crystal Orange is suitable. Similarly, Crystal Sapphire or Crystal Diamond methods apply in large projects that involve potential risk to human life. To sum up, the determination of the magnitude of the Crystal methodology happens by the project environment and the team size.

Difference between Crystal and Scrum:

Following are the main differences between Crystal & Scrum methodology:-

• Firstly, face-to-face personalized meetings happen in Crystal. Whereas in Scrum,  informal daily standup meetings take place.
• Secondly, the crystal process can be altered to accommodate any team size & criticality. On the other hand, Scrum works on a set of pre-defined processes & tools.
• Finally, there are numerous roles in Crystal-like Project Sponsor, Senior Designer/Programmer, Software Documenters and Unit Testers, etc. Unlike Scrum, where there are three leading roles, namely Scrum Master, Product Owner & Scrum Team.

Comparative Analysis of Different Agile Methodologies :

To conclude, I hope that, by now, you have a good understanding of Agile methodology along with its different frameworks. In addition to this, you can clearly articulate which Agile methodology should fit a particular development environment. The purpose of this article was to give you all the information in one place. However, we will be creating detailed articles on each of the Agile methodology. So if you need deep-dive into any one of them, feel free to do so.