case study of agile model xp and scrum dsdm crystal

Popular Insights:

Best Project Management Software

Mind Mapping Software

XP, FDD, DSDM, and Crystal Methods of Agile Development

Share this Article:

Our content and product recommendations are editorially independent. We may make money when you click links to our partners. Learn more in our  Editorial & Advertising Policy .

Software development methods that support the values and principles stated in the Agile Manifesto have received more attention since the declaration in 2001; the most popular of which are Scrum and Kanban. But there are more methods of Agile development than the ones most frequently used that reflect these same values. Let’s get to know them.

Featured Partners

{{ POSITION }}. {{ TITLE }}

Methods of Agile Development

Methods of agile software development have evolved into the modern development processes we know today after several experiments in the quest to improve the traditional method.

Read more: Agile Software Development Methodology and Principles

Scrum, a methodology of managing software projects and developing products with prescribed roles and practices, is one of the most popular methodologies adopted at present. It focuses on short, timeboxed periods called sprints where self-organizing teams develop working features that are added in small iterations to the software or product.

Another method gaining popularity is Kanban, which also uses incremental improvements to continuously add parts or features until such time that the product is fit to be delivered. The process uses a visual card or signboard that displays to the development team, the customers and other stakeholders the different stages of development, the number of work items to do, being worked on, and completed, which aids the continuity of the work flow.

While these are the most popular and more frequently used methodologies, there are alternatives that are worth considering when it comes to agile software development.

Alternative Methods of Agile Software Development

Before the Agile Manifesto was published, there were already different development methods being experimented and practiced to find a solution to the failing traditional methods. The waterfall method that was previously being followed was deemed too rigid to take on the changing requirements brought on by an improving technology and a more demanding client. Some of these methods were Extreme Programming (XP), Feature Driven Development (FDD), Dynamic Systems Development Method (DSDM), and Crystal.

Extreme Programming (XP)

Extreme programming (XP) was introduced in 1996 by Kent Beck when he was working on a Chrysler payroll project. Although the term was new at that time, the methods used, such as pair programming, unit testing, and customer acceptance tests have existed before. What XP did differently was to take these best practices to “extreme levels.” It was created to take into account changes that were happening at that time in software development and technology, namely object oriented programming and the Internet. XP puts importance in co-location of customers and developers, as well as pair programming, which also coincides with the values of interaction in Agile. It also has short development cycles, focusing on the needs of today rather than those of the future, sometimes called the “You aren’t gonna need it!” or YAGNI approach. Kent Beck is one of the signatories of the Agile Manifesto.

Extreme programming’s goal is to deliver software that is needed when it is needed. XP is best used by a small team of programmers, between 2 and 12, working on projects with dynamic requirements or high risk. The XP development team works together with managers and customers. An example project that used XP was Encyclopedia Britannica available on CD and web subscription.

Feature-Driven Development (FDD)

Feature-driven development (FDD) was introduced in 1997 by Jeff De Luca when he was working on a software development project for a large Singapore bank. FDD was also built around software engineering best practices such as domain object modeling, developing by feature and code ownership. The blending of these practices that resulted in a cohesive whole is the best characteristic of FDD.

FDD consists of five basic activities: the development of an overall model, the building of a feature list, the planning by feature, the designing by feature, and the building by feature. Every project will have its own unique model, which will result in a feature list. The last three activities are short iterative processes, with a feature not taking longer than two weeks to build. If it will take more than two weeks, then it will have to be broken down into smaller features.

FDD’s main purpose is to deliver tangible, working software repeatedly in a timely manner. The advantage of using FDD is that it is scalable even to large teams due to the concept of “just enough design initially” or JEDI. It is a great solution to maintain control over agile, incremental and inherently complex projects because of its feature-centric process. It is used in enterprise projects as well as web projects such as the Mousebraker.com online gaming site.

Dynamic Systems Development Method (DSDM)

Dynamic systems development method (DSDM) was published in 1995 by the DSDM Consortium, an association formed by vendors and experts in software engineering to provide a structure for Rapid Application Development techniques brought on by object oriented programming. The Consortium jointly developed and promoted a tool—and technique—independent development framework from best practice experiences of people working in big companies such as British Airways, American Express, Oracle, and Logica. It has now evolved into a project delivery framework that is fully compatible with ISO 9000 and PRINCE2. In 2007, it was rebranded Atern after the bird Arctic Tern. However, since 2014, it has reverted back to its original name as DSDM Agile Project Framework. Also, in 2016, the DSDM Consortium rebranded as the Agile Business Consortium.

DSDM consists of eight principles that will direct the team and create a mindset to deliver on time and within budget. Principles include focusing on the business need, delivering on time by timeboxing work, and emphasizing collaboration with end users, team members, business representatives, and other stakeholders. As a framework and not just a software development method, it can also be used in non-IT projects. It is often used in government projects where it is paired with project management standards, such as PRINCE2.

Crystal Methods

Crystal methods are a family of software development methodologies developed by Alistair Cockburn from his study and interviews of teams. The methods are color-coded to signify the risk to human life. For example, projects that may involve risk to human life will use Crystal Sapphire, while projects that do not have such risks will use Crystal Clear.

Crystal focuses on six primary aspects: people, interaction, community, communication, skills, and talents. Process is considered secondary. There are also seven common properties in Crystal that indicate higher possibility of success, and they include frequent delivery, reflective improvement, osmotic communication, and easy access to expert users. The methods are very flexible and avoid rigid processes because of their human-powered or people-centric focus. Alistair Cockburn is also one of the original signatories of the Agile Manifesto.

Crystal Methods consider people as the most important, so processes should be modeled to meet the requirements of the team. It is adaptive, without a set of prescribed tools and techniques. It is also lightweight, without too much documentation, management or reporting. The weight of the methodology is determined by the project environment and team size. For example, Crystal Clear is for short-term projects by a team of 6 developers working out of a single workspace.

Many teams and organizations have realized benefits, advantages, and improvement by adopting agile methodologies. However, challenges continue to come because of unique requirements and transforming business landscapes, especially difficult in large enterprises. Thus, the problem of scaling agile delivery process continues to be difficult to solve, and is currently being addressed by solutions such as Scaled Agile Framework (SAFe) and Large Scale Scrum (LeSS). Therefore, the goal of all companies to find that repeatable, predictable process that will improve productivity and quality continues on.

Join our newsletter

Subscribe to Project Management Insider for best practices, reviews and resources.

{{ TITLE }}

You should also read.

Top-Down vs. Bottom-Up Approach in Project Management: Which Is Best?

Components of Risk Management: Everything You Need to Know

Top 6 Software Development Methodologies & When to Use Them

Get the Newsletter

You might also like.

Asana vs Jira: Which Is Best in 2024?

Essential Project Management Guidelines & Rules to Follow

5 Ethical Issues in Project Management & How to Handle Them

Agile Methodology

• What is Agile?
• Agile Manifesto - 4 Values and 12 Principles
• Why Agile Methodology?

What is Scrum?

• Scrum Values
• Scrum Product Owner
• Scrum Development Team
• Scrum Master
• What is Sprint?
• Sprint Planning
• Daily Scrum Meeting
• Sprint Review
• Sprint Retrospective
• Product Backlog
• Sprint Backlog
• Definition of Done
• Scrum Guide
• Kanban Guide
• Extreme Programming
• Lean Development
• Crystal Methodology
• Feature Driven Development (FDD)

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.

• Kanban Software Development

Extreme Programming (XP)

Dynamic systems development method (dsdm).

• Comparative Analysis of Different Agile Methodologies

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.

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 "".

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.

Following are the 12 main principles in Agile methodology: -

• 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.
• 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.
• Frequently Delivered Software ( weeks rather than months )- This provides immediate value to the customer by delivering working features timely.*
• Work together - i.e., Close and daily cooperation between Business people and Developers by keeping documentation and requirements lightweight.
• Trust and Support - Projects are successful around motivated individuals who should be trusted.
• Face to Face conversation - Oral communication is preferred to rule out any discrepancies and be on the same page.
• Working Software - It is the primary measure of progress and should be delivered timely.
• Sustainable development - Agile methodology maintains the work-life balance among the team members and promotes happiness by avoiding exhaustion.
• Continuous Attention- Means consistent attention to technical excellence and good design enhances the agility of any team.
• 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.
• Self-organizing teams - The scrum team has autonomy and responsibility to meet the goals of the sprint.
• 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.

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: -

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

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

• 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.
• 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.
• 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.
• 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.
• 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.
• 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:-

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.
• Day 3 - finalize the design, suggest modifications
• Day 5 - pass the map
• 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.

• 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.
• 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)
• 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.

• Partially Done Work
• Extra Features
• Task Switching

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.

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:-

• Visualizing what you do
• Cap the Work-In-Progress activities
• Enhance the flow by pulling the next most prior thing from the backlog
• 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:-

• Flexibility - Firstly, this means there are no prescribed phase durations, and priorities are reassessed continuously based on the most recent information.
• 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.
• 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.

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:-

• 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.
• On-Site Customer – The XP customer is highly engaged with the team & is available on-site to provide regular feedback.
• 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.
• Iterative Development – It is also known as incremental design which means doing work in small increments & building it up further.
• Refactoring – Its primary focus is to remove the duplication of various processes.
• Simple Design – Keeping the system design as simple as possible will ensure the smooth running of the process.
• Planning Game – The stories are used to describe end-user requirements & the planning process.
• Coding Standards – Establishing standardized rules of code for all of the team members.
• 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.
• 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.
• 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.
• 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 Game
• On-Site Customer
• Refactoring
• Simple Design
• Pair programming
• Collective code ownership
• Coding Standards
• Continuous integration
• 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:-

• Time-saving - Firstly, it allows the organizations to save time required for project execution because XP focuses on the timely delivery of final products.
• 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.
• Simplicity - Thirdly, the developers create a straightforward code that they can improve at any moment.
• 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:-

• Scrum works on iterations which are 2-4 weeks long whereas XP iterations are 1-2 weeks long.
• 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.
• XP works on strictly high priority, unlike Scrum.
• XP prescribes engineering practices like refactoring, simple designs, pair programming, etc., unlike Scrum.
• Roles in XP are the customer, the developer, the tracker & the coach, unlike Scrum, where the primary roles are of SM, PO & Scrum team.

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:

• 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.
• Deliver on time – Frequent and timely releases help in the early detection of errors.
• Collaborate – Teamwork basis trust and honesty lead to effective production, which also helps in quicker resolution of various issues.
• Never compromise quality – Delivering a quality product is the main focus.
• 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.
• Develop iteratively – Acclimatization of the changes becomes easy using the Iterative model of development. It helps in reversing / updating already built products.
• Communicate continuously and clearly - Empowered teams that work co-operatively are more efficient, productive & communicate better with each other.
• 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-

• 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
• 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.
• 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
• 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.
• 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.
• 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 -

• 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.
• 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.
• 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.
• 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
• 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
• 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

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.

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:

• 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.*
• Moreover, DSDM involves diligent documentation, unlike Scrum.
• Daily Stand up meetings happen in Scrum, unlike DSDM, where information sharing happens through documents.
• 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.

• Develop an Overall Model -The client team and development team develop an overall model. Chief Architect guides this.
• 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.
• 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.
• 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.
• 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:-

• Risk Reduction - FDD helps in reducing risks using shorter iterations of designing, understanding of the requirements, and the system without any ambiguity.
• Regular Builds - Regular builds ensure there is always an up to date system. Which, in turn, the client can see.
• 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.
• 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.

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 –

• Discretionary Money
• Essential Money

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.

Similar Articles

• Selenium Training

Advisory boards aren’t only for executives. Join the LogRocket Content Advisory Board today →

• Product Management
• Solve User-Reported Issues
• Find Issues Faster
• Optimize Conversion and Adoption

DSDM: The dynamic systems development method

When approaching a product lifecycle, you need a strong foundation and governance to enable continuous release and feedback implementation. The good news is that agile provides different frameworks for managing such project lifecycle processes. A key agile methodology is the dynamic systems development method (DSDM), which provides an iterative and incremental approach to project development.

In this article, you’ll learn more about DSDM, its core principle, its comparison with other agile frameworks, and its roles and practices.

What is DSDM?

The dynamic system development method (DSDM) was first released in 1994 as a software development method to provide some discipline to the rapid application development (RAD) method. Over the years, DSDM has evolved from a software development method to a general project management and solution delivery method and can be used for non-technical projects.

DSDM is a recognized agile framework for project management and efficient delivery solutions. It can be used in a wide variety of applications, from small software developments to large-scale commercial processes. DSDM provides the structure, foundation, and guidance required to bring project/business needs to life by implementing its solutions for operational use. DSDM further encourages productive collaboration among all parties involved in project development, including stakeholders.

DSDM vs. other agile methodologies

To give you a better understanding of DSDM, let’s take a look at how it compares to other popular agile methodologies.

DSDM vs. scrum

DSDM and Scrum share numerous similarities as both employ iterative and incremental approaches for product development. Scrum is an agile framework for self-managing and self-organizing teams that solve problems, manage projects, and deliver customer value during a time-limited period known as a sprint. It’s simple to learn, but tough to master. DSDM is an agile framework that focuses on enabling project stakeholders to collaborate successfully in order to achieve business objectives.

DSDM vs. RAD

RAD (rapid application development), like DSDM, uses an iterative and incremental approach. However, these agile techniques differ. Rapid application development (RAD) is an agile methodology for software development. It’s ideal for working in a fast-paced setting.

Companies benefit from DSDM more than RAD since it provides defined, orderly stages for each part of a project. On the other hand, RAD values independence and innovative thinking. A well-structured DSDM can assist firms in reducing costs and increasing productivity.

DSDM vs. waterfall

Both DSDM and Waterfall enable organizations to plan and design initiatives before starting them. However, Waterfall allows companies to develop considerably more extensive project plans. While in DSDM, companies can modify the project’s goals while it is still in progress and also generate well-detailed designs at the early stage of the project.

Principles of the dynamic systems development method

Like any method, DSM leverages a group of core principles to help ensure its relevance and reliability throughout the product lifecycle.

Focus on the business need

In DSDM, delivering features and functionalities that align with the business needs and opportunities is of utmost priority. It involves collaborating with stakeholders to understand their requirements and ensure the project delivers value to the business.

Over 200k developers and product managers use LogRocket to create better digital experiences

Deliver on time

DSDM employs timeboxing techniques to allocate a specific time duration during the project development. This ensures the team delivers the most essential features within the specified time frame. There’s also a need for effective planning and monitoring to ensure that milestones are met as scheduled.

Collaborate

Stakeholders must be continually involved throughout the development process. This enables open communication and shared knowledge across teams, as well as effective decision-making.

Never compromise quality

In DSDM, rigorous testing and continuous validation of products must be carried out throughout the development process. This ensures that the product meets a high standard of excellence and reliability when delivered. Not prioritizing product quality can cause technical debt, increased maintenance costs, and stakeholder dissatisfaction.

Build incrementally from firm foundations

When building a product, it’s important to start with the key elements to create a firm foundation and technical base upon which other functionalities can be added gradually in successive iterations. Prioritizing this principle enables teams to manage complexity and maintain a solid foundation for future development.

Iterative development

This involves cycling through the stages of development repeatedly, testing and refining the product gradually. This allows teams to gather feedback early and often for continuous improvement of the project.

Continuous communication

In a working environment where information flows freely and transparently, everyone has access to important updates and decisions. By doing so, you encourage active engagement between teams and stakeholders throughout the project lifecycle where feedback is provided and issues can be addressed.

Demonstrate control

Mechanisms should be set for tracking and monitoring the progress of the project throughout the development lifecycle. This allows you to manage risks and establish clear objectives that align with business goals.

3 phases of DSDM

The phases of DSDM can be categorized into three phases:

1. The pre-project phase

The pre-project phase sets the groundwork for the project. It involves carrying out a feasibility study to evaluate the business viability, identifying stakeholders, and defining the project vision and success criteria.

2. The project lifecycle

This phase covers the main stages of the project execution which include feasibility study, business study, functional model iteration, design, build iteration, and implementation. Here, the project is developed iteratively and incrementally with collaboration and continuous feedback from stakeholders.

3. The post-project phase

In the final phase, a post-implementation review is carried out to evaluate the performance of the project and identify any areas for improvement. It ensures that the system operates efficiently and effectively. Documentation and knowledge sharing are done to gain insights from the project for future initiatives.

Roles in the dynamic systems development method

In DSDM, different roles are assigned to the project members before the project is commenced. Each role has its own unique responsibilities. These roles include:

• Project sponsor — The project sponsor is also known as the project champion. They are responsible for the business issues and financial decisions. The project sponsor is a crucial responsibility since they must be supportive, dedicated, and available throughout the project development to ensure the project’s long-term success and settle any conflicts that arise
• Project visionary — The project visionary is in charge of defining the project’s vision and communicating the business sponsor’s needs to the project team. They begin the project by ensuring that essential resources are available early on. Then, they ensure that the project’s progress is consistent with company objectives
• Project ambassador — The project ambassador is responsible for engaging with other users and involving them when needed. They bring the user community’s knowledge to the project and make sure the developers receive adequate user feedback during development
• Project manager — As the project progresses, it’s necessary to control the work environment. This is when the project manager steps in. This could be anyone on the business or IT team who manages the project and tracks its progress against the defined delivery plan
• Technical coordinator — The technical coordinator is responsible for ensuring that the project satisfies technical standards and that the technical roles are consistent. They create the system architecture and monitor the project’s technical performance
• Team leader — The team leader collaborates with the team to plan and coordinate all areas of product delivery on a comprehensive basis. They lead their team and ensure that they work well together
• Solution developer — The technical coordinator must give the solution developer authority to make daily decisions in their area of expertise. They also interpret the system requirements and models needed to design the project solution and prototypes
• Project advisor — The project advisor gives professional advice on the project’s day-to-day decisions. They could be anyone who represents an important position and contributes everyday knowledge to the project
• Solution tester — The solution tester develops the test scenarios and cases. They document the test results and provide them to the team leader and technical coordinator for quality assurance
• Facilitator — The facilitator oversees the workshop’s progress and serves as a guide for preparation and communication. Alongside this, they organize and moderates a session that enables participants to meet the workshop’s objectives

Real-world projects that use DSDM

Now that you have a sense of what DSDM is, let’s take a look at some successful examples of its implementation:

University of Saint Andrew

The University of Saint Andrews in Scotland, launched DSDM in 2014. It implemented DSDM to meet the changing needs of students, teachers, and staff while also providing high-quality software solutions to increase access, visibility, and administration of students’ curriculum data and time at the university.

LShift is a software development company that provides information technology consulting services. It conducted a case study on incorporating UX design into a DSDM project. LShift demonstrated the value of integrating UX design with agile development such as DSDM in delivering effective projects.

UK Government’s Highways Agency

The UK government integrated PRINCE2 (PRojects In Controlled Environments) , a project management methodology, with DSDM to respond fast to any project changes. This approach resulted in the project being completed on schedule and on budget, while also managing risks, involving stakeholders and customers on a regular basis, and ensuring that the result fulfilled business requirements.

Final thoughts

DSDM offers a well-structured and solid framework for organizations to properly manage projects. It can be used for general project management (technical and non-technical projects) and in an iterative approach to deliver solutions fast and on budget, as well as to receive feedback. Throughout the method, DSDM enables you to focus on business goals and collaboration among all project stakeholders.

The dynamic systems development method works best when stakeholders need to work together effectively, iteratively, and with flexibility. Good luck trying DSDM with your next product!

Featured image source: IconScout

LogRocket generates product insights that lead to meaningful action

Get your teams on the same page — try LogRocket today.

Share this:

• Click to share on Twitter (Opens in new window)
• Click to share on Reddit (Opens in new window)
• Click to share on LinkedIn (Opens in new window)
• Click to share on Facebook (Opens in new window)
• #agile and scrum
• #project management

Stop guessing about your digital experience with LogRocket

Recent posts:.

How to calculate variance (and why it’s important in business)

This article teaches you how to calculate variance, as well as the tools and software that you need, and common mistakes to avoid.

A day in the life of a product manager with schedule

As a PM yourself, you know how difficult and multifaceted the role can be. You need to talk with customers and work on design simultaneously.

Understanding zero-to-one product development

Zero-to-one is all about creating something new. Move beyond iterations and build groundbreaking products that lead to entirely new markets.

Understanding subscriber acquisition cost

Subscriber acquisition cost (SAC) refers to the total expense incurred by the business to acquire a new customer or subscriber.

Leave a Reply Cancel reply

SeaLights is now part of Tricentis, a global leader in continuous testing and quality engineering. Read the blog >>

• Cut Tests Cycle Time
• Cut Testing Costs
• End-to-End Tests Coverage Visibility
• Cut Failed Tests Troubleshooting Time
• Test Gap Analytics
• Quality Analytics
• White Papers and eBooks
• Case Studies
• Knowledge Hub
• What’s New
• About Sealights
• Book A Live Demo

Software Metrics .

The SeaLights Software Metrics Guide for Better and Faster CI/CD

The Agile Process: Scrum, Kanban and XP

This article covers basic principles of agile and lays out lifecycle stages of the three most popular agile methodologies – Scrum, Kanban and XP.

What is the Agile Methodology?

The agile methodology is a management paradigm used in software development environments. Agile has seen massive adoption over the past decade – 71% of organizations surveyed by the Project Management Institute reported they were using agile methodologies. Agile emphasizes work in short iterations and frequent releases of working software, with a fast feedback loop back to developers regarding the actual value of their work to customers.

10 Agile Principles

• Continuously deliver valuable software
• Deliver working software in a short timeframe
• Measure progress by working software delivered to customers
• Software requirements can and should change during the course of a project
• Changes to requirements should be accepted at the start of a work iteration but suppressed during an iteration
• Close cooperation between developers and product owners
• Transfer information face-to-face vs. electronically or via documentation
• Self-organized, empowered teams produce the best software and devise more efficient processes
• Technical excellence and an emphasis on quality boosts agility
• Simplicity boosts agility

5 Agile Benefits

• Predictable delivery – in agile environments it is well understood what will be delivered to customers and at what level of quality
• Predictable cost and schedule – release schedules and the scope of investment required for a release is known in advance, much more so than in previous methodologies
• Flexible prioritization and support for change – development projects can be dynamic and are no longer reliant on rigid specifications defined at the start of the project
• Focus on business value – development work is organized around one thing – how much value the team is providing to end-users
• Project success rate – agile projects are 3X more likely to succeed compared to waterfall, according to a Standish Group study

Agile Methodology Types

Agile is a broad and mature methodology with numerous variations, each of which has a different focus, process and benefits:

• Extreme Programming (XP)
• Adaptive Software Development
• Feature-Driven Development
• Pragmatic Programming
• Lean Development

In this article we’ll focus on Scrum , Lean and XP which are probably the most popular agile frameworks.

The Agile Process: Scrum

Scrum is a highly iterative agile framework that operates in sprints of 2-4 weeks. It defines features and objectives prior to each sprint, and is designed to reduce risk while providing value to customers as quickly as possible. In each sprint, a team commits to completing several user stories – brief descriptions of what a user needs to be able to achieve with the software.

The primary stages in the scrum process are:

• Creating a product backlog – a prioritized list of development tasks, defined as user stories. The work required for each user story is estimated using hours or story points.
• Sprint planning – creating a sprint backlog – a subset of the product backlog planned for a specific sprint, and estimated to fit into the fixed time scope of the sprint.
• Sprint work – developing working software within the sprint. The team carries out a daily stand-up meeting to share progress and resolve problems experienced by the team.
• Testing and product demonstration – towards the end of a sprint, the focus shifts to stabilizing and finalizing features, and conducting acceptance testing with product owners and customers.
• Retrospective – at the end of the sprint, sharing lessons learned from the previous sprint and using it to plan or adjust the backlog for the next sprint.

The Agile Process: Kanban

Kanban is an agile-based methodology which originated from lean manufacturing, pioneered by Toyota. It is a large to-do list, which helps manage work according to priority. A central principle of Kanban is that the tasks and their status are visualized as cards on a board, visible to all project staff. In Kanban, when a developer, tester, or other team member is ready for more work, they pull a task on the board by moving it to “Doing” or a specific work status like “Testing”.

Organizations implementing Kanban follow these stages:

• Visualize Work – define the process followed by the project team (for example, Not Started > Development > Dev Testing > Acceptance Testing > Done). Setup a board with a column for each process stage, and post the tasks on the board as sticky notes.
• Limit Work in Progress (WiP) – a key principle of lean manufacturing, Kanban enforces a limit of the number of tasks the team works on concurrently – usually no more than 2-3.
• Pull Don’t Push – each team member finishes their current task and then “pulls” an additional assignment from the board. This prevents bottlenecks when one part of the team has a higher throughput than another.
• Monitor and Improve – visualizations like the cumulative flow chart below help understand how work is progressing and identify bottlenecks in the process.

The Agile Process: Extreme Programming

Extreme Programming (XP) is a highly disciplined management method, which focuses on continually improving quality and speed of software delivery. The development team works closely with customers, continuously planning, testing and providing feedback to developers, to quickly deliver valuable software. Like Scrum, delivery is in iterations of 1-3 weeks.

The Extreme Programming method follows these lifecycle stages:

• Planning – setting goals for the entire project and specific iterative cycles. Planning is done together with the customer, who formulates a vision of the product and defines user stories. Developers estimate the stories and turn them into more granular tasks.
• Designing – developers are responsible for designing the main features in the next iteration. XP emphasizes simplicity, so design should be as simple as possible.
• Coding – throughout an iteration, developers constantly refactor the code to bring it down to the simplest, most elegant form possible. Pair programming is commonly used in XP projects to boost innovation and code quality.
• Testing – testing is done in tandem with writing the code, not afterwards as a separate development stage, typically using Test Driven Development (TDD).

Quality Intelligence in the Agile Process

Whatever agile methodology you practice, quality is key, because a low quality product does not provide sufficient value to end users. For agile teams to be effective, they must find a way to balance between the desire to push forward and deliver new functionality, while investing enough time in testing and validating that systems work as expected.

A new category of tools called Quality Intelligence Platforms can help with this part of the agile process, by providing data on which parts of the product are at risk of quality issues and are critical to test – and conversely, which parts are perfectly fine and do not require an investment in testing.

SeaLights is a Quality Intelligence Platform that helps agile development organizations focus testing efforts on what matters most – customer satisfaction. It analyzes test execution data, code changes and actual uses of features in production, and provides a clear visualization of “test gaps” – where teams need to invest in testing to achieve the highest business value.

Read our white paper on improving development velocity   to learn how Quality Intelligence can make a huge difference to your agile organization.

Agile Approaches: XP, SCRUM, and DSDM

Get an overview of Extreme Programming, Scrum, and DSDM methodologies in Agile.

Extreme programming

The approach with the most distracting name is Extreme Programming (more commonly known as XP). Extreme Programming is a fairly technically oriented Agile approach that emerged during that major project failure from Chrysler under the direction of Kent Beck and Martin Fowler, among others.

Get hands-on with 1200+ tech skills courses.

Agile Unpacked: Understanding the Strengths of Scrum, Kanban, Lean, and Beyond

Table of Contents

In the fast-paced world of software development, staying flexible and adaptable is crucial. That’s where Agile methodologies come in, a transformative approach that has reshaped the landscape of project management and software development.

But what exactly is Agile? At its core, Agile is more than just a methodology; it’s a mindset. Rooted in the Manifesto for Agile Software Development , it champions values such as individuals and interactions, working software, customer collaboration, and responding to change. The Agile approach promotes adaptive planning, evolutionary development, early delivery, and continual improvement, all with an eye on flexible responses to change.

However, as you delve into Agile, you’ll quickly realize it’s more than a one-size-fits-all solution. There are various Agile methodologies, each with its strengths, weaknesses, and ideal use cases. From Scrum’s iterative approach to Kanban’s focus on continuous delivery, from Lean’s drive for efficiency to Extreme Programming’s emphasis on quality—there’s a lot to unpack.

In this article, we’re doing just that—unpacking Agile. We’ll walk you through different Agile methodologies including Scrum, Kanban, Lean, Extreme Programming (XP), Feature-Driven Development (FDD), Crystal, and Dynamic Systems Development Method (DSDM). We’ll cover when and why to use each methodology and their strengths and potential drawbacks. In a previous post, we tackled another topic regarding Prioritizing Speed over Precision in Digital Transformation in Agile Software Development .

Whether you’re new to Agile or looking to optimize your current practices, this comprehensive guide will provide you with the insights you need to select the right Agile methodology for your software development projects. Let’s dive in!

Experience Expert IT Consultancy

Transformative Strategies for Your Technology Needs

Understanding Agile

Agile, as a term, was born out of a meeting of seventeen software developers in Snowbird, Utah, in 2001. They penned the Manifesto for Agile Software Development, which laid out four key values and twelve principles, setting the foundation of what we now know as Agile.

The key values of AGILE are:

• Individuals and interactions over processes and tools;
• Working software over comprehensive documentation;
• Customer collaboration over contract negotiation;
• Responding to change over following a plan.

This doesn’t mean that the concepts on the right are unimportant, but rather that Agile practitioners value the concepts on the left more.

At its heart, Agile is about embracing change, as I covered in a recent Fobes article . It acknowledges that customer needs can shift and market conditions can fluctuate. Agile enables teams to be responsive and flexible, delivering value to customers quickly and frequently.

What sets Agile apart from traditional project management methodologies is its emphasis on delivering work in small, manageable increments – often called “iterations” or “sprints”. This allows teams to receive and implement feedback after each iteration, ensuring the final product is as closely aligned with customer needs as possible.

Streamlining Your Path to Effective Product Discovery

Make Your Ideas a Reality in Four Weeks with Our Results-Driven TechBoost Program

But the term “Agile” itself has become an umbrella term for a variety of methodologies that embody these principles, including Scrum , Kanban , Lean , Extreme Programming (XP) , Feature-Driven Development (FDD) , Crystal , and Dynamic Systems Development Method (DSDM) .

While these methodologies share the core principles of Agile, each one has its unique approach and focuses, and understanding these differences is key to implementing Agile successfully. In the following sections, we’ll delve into each of these methodologies, exploring their unique characteristics, strengths, and potential drawbacks.

This knowledge will empower you to select the Agile methodology that best suits your project needs, team capabilities, and overall business objectives. Let’s dive deeper.

One of the most popular Agile frameworks, Scrum, has been widely adopted by many software development teams due to its simplicity and flexibility. Named after a rugby formation, it emphasizes teamwork in overcoming complex challenges.

Small and cross-functional teams characterize Scrum. These teams are self-organizing, meaning they determine how to do their work rather than being directed by others outside the team.

The work in Scrum is structured in cycles of work called Sprints, typically lasting one to four weeks. The aim is to deliver a potentially shippable increment of “Done” product at the end of each Sprint.

Scrum introduces three key roles: the Product Owner , responsible for maximizing the value of the product; the Scrum Master , who guides and coaches the team to follow Scrum practices ; and the Development Team , who is responsible for delivering the product.

Moreover, Scrum employs several ceremonies such as Sprint Planning, Daily Scrum (or standup), Sprint Review, and Sprint Retrospective to ensure frequent communication and continuous progress.

When and why to use Scrum

Scrum is an excellent choice for projects with rapidly changing or highly emergent requirements. It is particularly well-suited when you have a motivated team who is receptive to customer feedback and values iterative progress toward a well-defined goal.

Strengths of Scrum

• Enables teams to deliver usable software early and continually throughout the project lifecycle.
• High transparency with regular updates and reviews.
• Emphasizes team collaboration and continuous improvement.

Potential Drawbacks of Scrum

• The effectiveness of Scrum is highly dependent on the commitment of the team and their willingness to adhere to Scrum principles.
• It requires experienced team members for smooth execution.
• The focus on delivering working software might sometimes overshadow technical quality if not careful.

Understanding these pros and cons can help you assess whether Scrum is the right Agile methodology for your software development project. Remember, adapting the methodology to your unique project needs and team dynamics is key to successful Agile implementation. Let’s continue our exploration with the next Agile methodology, Kanban.

Kanban originated from the Japanese manufacturing sector and is another popular Agile methodology. The word “Kanban” translates to “visual signal” or “card” in English, and as the name suggests, visualization of work is a key component of this methodology.

Kanban uses a physical or digital board to represent the workflow. A card on the board represents each task or work item, and its movement from one column to another represents its progress. Typical columns are “To Do,” “In Progress,” and “Done,” but these can be customized according to the nature of the project.

One distinguishing feature of Kanban is using Work in Progress (WIP) limits. These are set to limit the number of tasks in a particular phase. WIP limits help prevent team members’ overload and identify workflow bottlenecks.

When and why to use Kanban

Kanban is ideally suited for projects where priorities change frequently and there is continuous workflow, such as product support or maintenance. It allows for changes to be incorporated at any time, making it more flexible in handling project modifications.

Strengths of Kanban

• Provides a visual and clear overview of status, progress, and bottlenecks.
• Enables quick identification and resolution of any obstacles in the workflow.
• Promotes a continuous flow of work, reducing the time to market.

Digital Transformation for Competitive Advantage

Empowering Your Business with Tailored Digital Solutions

Potential Drawbacks of Kanban

• Without careful attention, tasks can accumulate in certain stages, leading to imbalances in workload.
• It doesn’t provide timeframes, making it harder to predict when a project or task will be completed.
• Less structured than Scrum can lead to issues for teams that require more guidance or are new to Agile methodologies.

Kanban offers significant flexibility and transparency, making it a strong contender for many software development environments. By understanding the nature of your project and your team’s strengths, you can determine if Kanban is the right fit for you. Let’s move on to the next Agile methodology, Lean Software Development.

Section 4: Lean Software Development

Inspired by Lean Manufacturing principles from Toyota, Lean Software Development is an Agile methodology that focuses on optimizing efficiency, reducing waste, and delivering value to the customer as fast as possible. The philosophy of Lean can be condensed into seven principles:

• Eliminate Waste: Anything that doesn’t add value to the customer is considered waste. This includes unnecessary code or functionality, waiting, context-switching, etc.
• Build Quality In: Spend time preventing defects rather than identifying them in the testing phase or letting the customer find them.
• Create Knowledge: Lean emphasizes learning and constant improvement. It’s not just about delivering software but about growing competencies.
• Defer Commitment: Delay decisions until thoroughly thought out or until the last possible moment.
• Deliver Fast: The sooner the product is delivered without major defects, the sooner feedback can be collected and incorporated into the next iteration.
• Respect People: People involved should be considered the most significant value in the software development process. They should be respected and motivated.
• Optimize the Whole: The focus should be on the entire value stream, not optimizing separate parts.

When and Why to Use Lean

Lean is best used in environments where the goal is to maximize customer value while minimizing waste. It’s a perfect fit for startups and businesses looking to create the most efficient processes.

Strengths of Lean Software Development

• Minimizes waste, leading to a more efficient and cost-effective development process.
• Focus on delivering customer value helps to ensure a market-fit product.
• Encourages continuous improvement, leading to better practices and higher quality over time.

Potential Drawbacks of Lean Software Development

• Requires a significant commitment to change and continuous improvement, which may be challenging for some teams.
• In its pursuit of efficiency, Lean may overlook some necessary tasks if they’re viewed as “waste”.
• It can be challenging to implement if the whole team is not committed to the principles of Lean.

With its focus on efficiency and value delivery, Lean offers a compelling approach for teams looking to optimize their workflows. But it also requires a strong commitment to change and continuous improvement. Next, let’s continue our Agile journey by exploring Extreme Programming (XP).

Extreme Programming (XP)

As the name suggests, Extreme Programming (XP) takes traditional software engineering practices and pushes them to ‘extreme’ levels to improve software quality and responsiveness to changing requirements. It encourages frequent “releases” in short development cycles, which enhances productivity and introduces checkpoints where new customer requirements can be adopted.

XP incorporates five key values: communication, simplicity, feedback, respect, and courage. It also introduces a set of practices such as pair programming, test-driven development, continuous integration, refactoring, and collective code ownership.

When and Why to Use Extreme Programming

XP is an excellent choice for projects with dynamic requirements, a high risk of frequent changes, and when the customer is readily available. It’s ideal for small to medium-sized teams.

Experience Our Skilled Development Teams

Elevate Your Projects with Skilled Software Development Professionals

Strengths of Extreme Programming

• Encourages strong team communication and collaboration.
• Emphasizes customer satisfaction and involvement.
• Promotes high-quality code and design simplicity.

Potential Drawbacks of Extreme Programming

• Its practices can be overly rigid and demanding, which might only suit some team environments.
• Requires high customer and developer involvement, which can be challenging to facilitate.
• Over-reliance on oral communication and code can lead to a lack of documentation.

XP is a powerful methodology when applied in the right context. The emphasis on coding and team communication can lead to high-quality outcomes and a highly collaborative environment. But remember, it requires high customer involvement and may not suit projects where formal documentation is essential. Let’s move on to another methodology, Feature-Driven Development (FDD).

Feature-Driven Development (FDD)

Feature-Driven Development (FDD) is an iterative and incremental software development methodology focusing on building features. A feature in FDD is not a product feature from a marketing standpoint but a small, client-valued function expressed as “action, result, object”.

FDD begins with high-level scope and design work, then broken down into a list of features. Unlike other Agile methodologies, FDD emphasizes design and documentation more but remains highly iterative.

When and Why to Use Feature-Driven Development

FDD is best suited for large-sized, complex projects, often with multiple teams. It is also a good fit for projects where the requirements are well-understood and less likely to change drastically.

Strengths of Feature-Driven Development

• FDD’s emphasis on individual features can lead to early and continuous delivery of high-value to clients.
• Strong emphasis on design and documentation, making it a good choice for complex projects.
• Allows for clear visibility into the progress and results of development efforts.

Potential Drawbacks of Feature-Driven Development

• Requires significant design and planning upfront, which may not suit projects with high uncertainty or volatility.
• Less flexibility to accommodate changes compared to other Agile methodologies.
• Requires more experienced and competent leadership to execute effectively.

FDD’s structured approach and feature emphasis can balance traditional and Agile methodologies well, especially for large projects. It’s essential to weigh these advantages against potential challenges to ensure it fits your project correctly. Let’s now move to the Crystal methodology.

Crystal is a family of Agile methodologies that focuses on people, interactions, community, skills, talents, and communications while being flexible about the processes and tools. The term Crystal comes from the idea that each project may require a slightly different set of policies, practices, and processes, forming a unique “gem” or “crystal”.

A key characteristic of Crystal methodologies is that they are adaptable. The processes and practices are tailored based on the team size, system criticality, and project priorities. Some well-known Crystal methodologies include Crystal Clear, Crystal Yellow, Crystal Orange, and Crystal Red, each suited for different team sizes and project criticality.

Redefine Your Business with Custom Software Development

Tailored Software Solutions Designed for Your Growth

When and why to use Crystal

Crystal is best suited for projects where the development team is co-located and can communicate with one another frequently and informally. It’s an excellent choice when the team values interaction and individuals’ skills over processes and tools.

Strengths of Crystal

• Highly adaptable to different project needs and team sizes.
• Places a strong emphasis on communication and team interaction.
• Low administrative overhead and easy to implement.

Potential Drawbacks of Crystal

• A lack of specific guidelines can lead to clarity and consistent practices.
• Not suitable for distributed teams due to its emphasis on co-location and face-to-face communication.
• Requires high trust and communication among team members, which might be challenging in some environments.

In conclusion, even if Crystal’s adaptability and people-centric approach make it an appealing choice for local teams, there may be better options for globally distributed resources. Let’s continue with the last methodology in this article, the Dynamic Systems Development Method (DSDM).

Dynamic Systems Development Method (DSDM)

Dynamic Systems Development Method (DSDM) is an Agile framework that gives significant attention to the whole project lifecycle, unlike some other Agile methodologies. The project’s business value highly drives it and focuses on delivering maximum value early in the process.

DSDM relies on principles like active user involvement, frequent delivery, teams with the power to make decisions, integrated testing throughout the project life cycle, and a strong focus on collaboration and cooperation.

When and why to use DSDM

DSDM is particularly well suited to projects with tight schedules and budgets, where the project scope is clearly defined, but detailed requirements are likely to evolve. It is ideal for organizations that need a comprehensive framework covering the entire project lifecycle.

Strengths of DSDM

• Comprehensive and detailed guidance covering the full project lifecycle.
• Emphasizes delivery of tangible and business-valuable increments early in the project.
• Allows for clear decision-making processes with its built-in governance framework.

Potential Drawbacks of DSDM

• Can be complex and difficult to implement due to its comprehensive nature.
• Requires strong business involvement and collaboration, which can be challenging to achieve.
• Its emphasis on strict deadlines might sometimes lead to features being dropped to meet the time constraints.

By providing a detailed structure for project development, DSDM can provide clarity and control to businesses that require strict schedules and budgets. However, like any other methodology, it needs to be adapted and applied based on the specific needs of the project and the organization. Let’s wrap up our exploration with a brief conclusion.

Wrapping Up the Agile Journey: Choosing the Right Agile Methodology for Your Software Development Process

In the rapidly changing world of software development, Agile methodologies offer a path to delivering high-quality software that meets the evolving needs of users and businesses. But remember, Agile is not a one-size-fits-all approach. Each methodology we’ve explored — Scrum, Kanban, Lean, XP, FDD, Crystal, and DSDM — offers unique strengths and potential drawbacks.

The key to successful Agile adoption is to understand your team’s specific needs, the nature of the project, and the business environment. Agile is a mindset, not a strict set of rules. Don’t hesitate to experiment, adapt, and mix methodologies if it serves your project’s unique needs.

At HyperSense, we work with a diverse range of clients and projects. This diversity has given us experience in applying and adapting these methodologies based on the project’s requirements. Our goal is always to deliver software that adds real value to our clients, and Agile methodologies are a critical tool in achieving that goal.

Choosing the right Agile methodology can significantly affect your project’s success. If you’re looking for experienced software consultants to help guide your Agile journey, don’t hesitate to contact us at HyperSense . Our team is ready to help you navigate the Agile landscape and deliver software that truly meets your needs.

Remember, it’s not about being Agile for the sake of being Agile. It’s about creating an environment where software can thrive, teams can collaborate, and customers can truly benefit from your efforts. So, explore, learn, and choose the right Agile methodology to empower your software development process.

How useful was this post?

Click on a star to rate it!

Average rating 5 / 5. Vote count: 201

No votes so far! Be the first to rate this post.

Related Posts:

• WCAG 2.2 Explained: Everything You Need to Know about the Web Content…
• From Monoliths to Microservices: How AWS CDK is Leading the Charge in…
• Mastering Industry 4.0: A Comprehensive Guide to Software Development in…
• Top 5 Tech Trends to Watch in 2024: Spatial Computing, Personalized AI…
• Effective Strategies for Managing Technical Debt in Long-Term Software Projects
• Cloud Security Demystified: A Practical Guide for Business Owners

Andrei Neacsu

Andrei, CTO and co-founder of HyperSense Software Inc., has an extensive career spanning over 15 years in the tech industry. With hands-on experience in mobile and web development, cloud infrastructure, and DevOps, he has been instrumental in both startup launches and enterprise-level tech transformations. His approach intertwines deep technical knowledge with strategic business insights, aiding in everything from vision setting and market research to contract negotiations and investor relations. As a member of the Forbes Business Council, he consistently delivers valuable insights in the areas of technology and people management.

Building a Real Estate Platform Like Zillow: A Comprehensive Guide

Green hydrogen: role of software for production, storage, and distribution, related posts, optimizing software with performance testing, why code reviews are essential for software projects’..., understanding it support levels and their impact on..., key considerations for a successful frontend transition, ensuring software quality and stability through effective regression..., effective strategies for managing technical debt in long-term..., breaking free from analysis paralysis in software development, mastering project complexity in software development: strategies and..., finding a software partner that matches your business..., developer experience (devex): what is and how it....

• Digital Transformation
• Custom Software Development
• Product Discovery
• Web Development
• UI/UX Design
• Research and Development
• Mobile App Development
• IT Consultancy
• Development Teams
• Let’s work together to turn your technological aspirations into reality. Contact now
• Telecommunications
• Business & Productivity
• Finance & Fintech
• Event Management
• Beauty & Personal Care
• Retail & E-commerce
• Location & Tracking
• Gaming & Entertainment
• How We Work
• Management Team
• Worldwide presence
• Awards & Certifications
• Our culture
• AI & Machine Learning
• Company News
• Cybersecurity & Privacy
• Emerging Technologies
• Case Studies & Whitepapers
• Cross-Platform Development
• Design & User Experience
• Cloud & Serverless Computing

• Software Testing Course
• Software Engineering Tutorial
• Software Development Life Cycle
• Waterfall Model
• Software Requirements
• Software Measurement and Metrics
• Software Design Process
• System configuration management
• Software Maintenance
• Software Development Tutorial
• Software Testing Tutorial
• Product Management Tutorial
• Project Management Tutorial
• Agile Methodology
• Selenium Basics

Agile Development Models – Software Engineering

In earlier days, the Iterative Waterfall Model was very popular for completing a project. But nowadays, developers face various problems while using it to develop software. The main difficulties included handling customer change requests during project development and the high cost and time required to incorporate these changes. To overcome these drawbacks of the Waterfall Model, in the mid-1990s the Agile Software Development model was proposed.

Table of Content

What is Agile Model?

Agile sdlc models/methods, steps in the agile model, principles of the agile model, characteristics of the agile process, when to use the agile model, advantages of the agile model, disadvantages of the agile model, questions for practice, frequently asked questions on agile model – faqs.

The Agile Model was primarily designed to help a project adapt quickly to change requests. So, the main aim of the Agile model is to facilitate quick project completion. To accomplish this task, agility is required. Agility is achieved by fitting the process to the project and removing activities that may not be essential for a specific project. Also, anything that is a waste of time and effort is avoided. The Agile Model refers to a group of development processes. These processes share some basic characteristics but do have certain subtle differences among themselves.

Given below are some Agile SDLC Models:

• Crystal Agile methodology: The Crystal Agile Software Development Methodology places a strong emphasis on fostering effective communication and collaboration among team members, as well as taking into account the human elements that are crucial for a successful development process. This methodology is particularly beneficial for projects with a high degree of uncertainty, where requirements tend to change frequently.
• Dynamic Systems Development Method (DSDM ) : DSDSM methodology is tailored for projects with moderate to high uncertainty where requirements are prone to change frequently. Its clear-cut roles and responsibilities focus on delivering working software in short time frames. Governance practices set it apart and make it an effective approach for teams and projects.
• Feature-driven development (FDD): FDD approach is implemented by utilizing a series of techniques, like creating feature lists, conducting model evaluations, and implementing a design-by-feature method, to meet its goal. This methodology is particularly effective in ensuring that the end product is delivered on time and that it aligns with the requirements of the customer.
• Scrum: Scrum methodology serves as a framework for tackling complex projects and ensuring their successful completion. It is led by a Scrum Master, who oversees the process, and a Product Owner, who establishes the priorities. The Development Team, accountable for delivering the software, is another key player.
• Extreme Programming (XP):   Extreme Programming uses specific practices like pair programming, continuous integration, and test-driven development to achieve these goals. Extreme programming is ideal for projects that have high levels of uncertainty and require frequent changes, as it allows for quick adaptation to new requirements and feedback.
• Lean Development: Lean Development  is rooted in the principles of lean manufacturing and aims to streamline the process by identifying and removing unnecessary steps and activities. This is achieved through practices such as continuous improvement, visual management, and value stream mapping, which helps in identifying areas of improvement and implementing changes accordingly. 
• Unified Process: Unified Process is a methodology that can be tailored to the specific needs of any given project. It combines elements of both waterfall and Agile methodologies, allowing for an iterative and incremental approach to development. This means that the UP is characterized by a series of iterations, each of which results in a working product increment, allowing for continuous improvement and the delivery of value to the customer.

All Agile Software Development Methodology discussed above share the same core values and principles, but they may differ in their implementation and specific practices. Agile development requires a high degree of collaboration and communication among team members, as well as a willingness to adapt to changing requirements and feedback from customers.

In the Agile model, the requirements are decomposed into many small parts that can be incrementally developed. The Agile model adopts Iterative development. Each incremental part is developed over an iteration. Each iteration is intended to be small and easily manageable and can be completed within a couple of weeks only. At a time one iteration is planned, developed, and deployed to the customers. Long-term plans are not made. 

The agile model is a combination of iterative and incremental process models. The steps involve in agile SDLC models are: 

• Requirement gathering
• Design the Requirements
• Construction / Iteration
• Testing / Quality Assurance

Steps in Agile Model

• Requirement Gathering:- In this step, the development team must gather the requirements, by interaction with the customer. development team should plan the time and effort needed to build the project. Based on this information you can evaluate technical and economical feasibility.
• Design the Requirements:- In this step, the development team will use user-flow-diagram or high-level UML diagrams to show the working of the new features and show how they will apply to the existing software. Wireframing and designing user interfaces are done in this phase.
• Construction / Iteration:- In this step, development team members start working on their project, which aims to deploy a working product.
• Unit Testing:- Unit testing is the process of checking small pieces of code to ensure that the individual parts of a program work properly on their own. Unit testing is used to test individual blocks (units) of code.
• Integration Testing:- Integration testing is used to identify and resolve any issues that may arise when different units of the software are combined.
• System Testing:- Goal is to ensure that the software meets the requirements of the users and that it works correctly in all possible scenarios.
• Deployment:- In this step, the development team will deploy the working project to end users.
• Feedback:- This is the last step of the Agile Model. In this, the team receives feedback about the product and works on correcting bugs based on feedback provided by the customer.

The time required to complete an iteration is known as a Time Box. Time-box refers to the maximum amount of time needed to deliver an iteration to customers. So, the end date for an iteration does not change. However, the development team can decide to reduce the delivered functionality during a Time-box if necessary to deliver it on time. The Agile model’s central principle is delivering an increment to the customer after each Time-box. 

• To establish close contact with the customer during development and to gain a clear understanding of various requirements, each Agile project usually includes a customer representative on the team. At the end of each iteration stakeholders and the customer representative review, the progress made and re-evaluate the requirements.
• The agile model relies on working software deployment rather than comprehensive documentation.
• Frequent delivery of incremental versions of the software to the customer representative in intervals of a few weeks.
• Requirement change requests from the customer are encouraged and efficiently incorporated.
• It emphasizes having efficient team members and enhancing communications among them is given more importance. It is realized that improved communication among the development team members can be achieved through face-to-face communication rather than through the exchange of formal documents.
• It is recommended that the development team size should be kept small (5 to 9 people) to help the team members meaningfully engage in face-to-face communication and have a collaborative work environment.
• The agile development process usually deploys Pair Programming . In Pair programming, two programmers work together at one workstation. One does coding while the other reviews the code as it is typed in. The two programmers switch their roles every hour or so.
• Agile processes must be adaptable to technical and environmental changes. That means if any technological changes occur, then the agile process must accommodate them.
• The development of agile processes must be incremental. That means, in each development, the increment should contain some functionality that can be tested and verified by the customer.
• The customer feedback must be used to create the next increment of the process.
• The software increment must be delivered in a short span of time.
• It must be iterative so that each increment can be evaluated regularly.
• When frequent modifications need to be made, this method is implemented.
• When a highly qualified and experienced team is available.
• When a customer is ready to have a meeting with the team all the time.
• when the project needs to be delivered quickly.
• Projects with few regulatory requirements or not certain requirements.
• projects utilizing a less-than-strict current methodology
• Those undertakings where the product proprietor is easily reachable
• Flexible project schedules and budgets.
• Working through Pair programming produces well-written compact programs which have fewer errors as compared to programmers working alone.
• It reduces the total development time of the whole project.
• Agile development emphasizes face-to-face communication among team members, leading to better collaboration and understanding of project goals.
• Customer representatives get the idea of updated software products after each iteration. So, it is easy for him to change any requirement if needed.
• Agile development puts the customer at the center of the development process, ensuring that the end product meets their needs.
• The lack of formal documents creates confusion and important decisions taken during different phases can be misinterpreted at any time by different team members.
• It is not suitable for handling complex dependencies.
• The agile model depends highly on customer interactions so if the customer is not clear, then the development team can be driven in the wrong direction.
• Agile development models often involve working in short sprints, which can make it difficult to plan and forecast project timelines and deliverables. This can lead to delays in the project and can make it difficult to accurately estimate the costs and resources needed for the project.
• Agile development models require a high degree of expertise from team members, as they need to be able to adapt to changing requirements and work in an iterative environment. This can be challenging for teams that are not experienced in agile development practices and can lead to delays and difficulties in the project.
• Due to the absence of proper documentation, when the project completes and the developers are assigned to another project, maintenance of the developed project can become a problem.

1. Which of the following is not a key issue stressed by an agile philosophy of software engineering? [ UGC NET CS 2017 ]

(A) The importance of self-organizing teams as well as communication and collaboration between team members and customers

(B) Recognition that change represents an opportunity

(C) Emphasis on rapid delivery of software that satisfies the customer

(D) Having a separate testing phase after a build phase

Solution: Correct Answer is (D).

2. ​Which of the following is not one of the principles of the agile software development method? [ UGC NET CS 2018 ]

(A)  Following the plan

(B)  Embrace change

(C)  Customer involvement

(D)  Incremental delivery

Solution: Correct Answer is (A).

Agile development models prioritize flexibility, collaboration, and customer satisfaction. They focus on delivering working software in short iterations, allowing for quick adaptation to changing requirements. While Agile offers advantages like faster delivery and customer involvement, it may face challenges with complex dependencies and lack of formal documentation. Overall, Agile is best suited for projects requiring rapid development, continuous feedback, and a highly skilled team.

1. What is Product Backlog in Agile?

Product Backlog simply refers to the list of features, and tasks that are to be developed in Software Product. These things are continuously monitored and managed by the Product Owner.

2. Is it possible to use Agile Model for large and complex Projects?

Yes, it is possible to use for Large and Complex Projects, but we need to change some adaptations for using it like we have to add some frameworks like SAFE ( Scaled Agile Framework ) and LeSS (Large-Scale Scrum) to use large and complex projects.

3. What is Sprint Review in Agile Model?

Sprint Review is simply a type of meeting that is held at the end of each sprint in the Agile Model. In this meeting, the development team details the work done to the stakeholder and Product Owner.

Related Posts:

• Agile Software Development Methodology | Framework, Principles, and Benefits

Please Login to comment...

Similar reads.

• Software Engineering
• How to Underline in Discord
• How to Block Someone on Discord
• How to Report Someone on Discord
• How to add Bots to Discord Servers
• 15 Most Important Aptitude Topics For Placements [2024]

Improve your Coding Skills with Practice

What kind of Experience do you want to share?

Roger Swannell

UX design in agile: a DSDM case study

Roger on 07/04/2024

Integrating User Experience (UX) design with agile development continues to be the subject of academic studies and practitioner discussions. Most of the existing literature focuses on SCRUM and XP, but in this paper we investigate a technical company who use DSDM. Unlike other agile methods, DSDM provides a configurable framework and a set of roles that covers the whole software development process. While elements of the UX design integration experience were similar to those reported with other agile methods, working practices to mitigate the challenges were identified using DSDM’s standard elements. Specifically, communication challenges were mitigated by extending two of DSDM’s standard roles. In addition, a change of focus between a design-led phase and a development-led phase of the project changed the communication challenges. Agile teams need to be aware that this change of focus can happen and the implications that it has for their work.

https://oro.open.ac.uk/40418/1/XP2014CameraReady.pdf

• Category: Notes

It sits beside the crossroads of humanity and technology, and past and future, and watches it all go by.

No thanks, I’m not interested

• [email protected]
• +971 507 888 742

Australasian Journal of Computer Science

• Vol 2 (1), 2015

Review Article

An examination and evaluation of agile methodologies for systems development.

Received: June 04, 2015;   Accepted: July 11, 2015;   Published: October 29, 2015

How to cite this article

Introduction.

• Agile Manifesto, 2001. Agile manifesto and principles: Manifesto for agile software development. http://agilemanifesto.org.
• Abrahamsson, P., O. Salo, J. Ronkainen and J. Warsta, 2002. Agile Software Development Methods, Review and Analysis Report. VTT Publications, Finland, Pages: 478.
• Abrahamsson, P., J. Wasta, M. Siponen and J. Ronkainen, 2003. New direction on Agile methods: A comparative analysis. Proceedings of the 25th International Conference on Software Engineering, May 3-10, 2003, May 3-10, 2003, IEEE Computer Society, Portland Oregon.
• Advance Development Methods, 1996. The origins of SCRUM, control chaos. Advanced Development Methods, Inc.
• Beck, K., 2000. Extreme Programming Explained: Embrace Change. Addison-Wesley, Reading, MA.
• Berger, H., 2007. Agile development in a bureaucratic arena-A case study experience. Int. J. Inform. Manage., 27: 386-396. CrossRef Direct Link
• Boehm, B., 2002. Get ready for agile methods, with Care. IEEE Comput. Soc., 35: 64-69. CrossRef Direct Link
• Cao, L., K. Mohan, P. Xu and B. Ramesh, 2004. How extreme does extreme programming have to be? Adapting XP practices to large-scale projects Proceedings of the 37th Hawaii International Conference on System Sciences, January 5-8, 2004, IEEE Computer Society,. CrossRef Direct Link
• Chow, T. and D.B. Cao, 2008. A survey study of critical success factors in agile software projects. J. Syst. Software, 81: 961-971. CrossRef Direct Link
• Cockburn, A., 1999. A methodology per project. http://alistair.cockburn.us/Methodology+per+project.
• Cockburn, A., 2001. Agile Software Development. Addison-Wesley, UK.
• Cohen, D., M. Lindvall and P. Costa, 2004. An Introduction to Agile Methods. Elsevier Inc., UK.
• Cohn, M. and D. Ford, 2003. Introducing an Agile process to an organization. IEEE Comput. Soc., 36: 74-78. CrossRef Direct Link
• Conchango, 2008. British car auction: How agile methodologies helped BCA delivery its smoothest ever project. British Car Auction, Conchango, UK.
• Dyba, T. and T. Dingsoyr, 2008. Empirical studies of agile software development: A systematic review. Inform. Software Technol., 50: 833-859. CrossRef Direct Link
• Effective Soft, 2008. Agile case study. Software Development Company, USA. http://www.effectivesoft.com.
• Fowler, M., 2005. The new methodology. December 13, 2005. http://www.martinfowler.com/articles/newMethodology.html.
• Griffiths, M., 2004. Using Agile alongside the PMBOK. Proceedings of th PIM Global Congress, (PMI'04), Anaheim, California.
• Hansson, C., Y. Dittrich, B. Gustafsson and S. Zarnak, 2006. How Agile are industrial software development practices? J. Syst. Software, 79: 1295-1311. CrossRef Direct Link
• Highsmith, J., 1998. Adaptive Software Development: An Evolution Approach to Managing Complex Systems. Dorset House Publishing, USA.
• Highsmith, J., 2004. Extreme programming. E-Business Application Delivery Newsletter, Cutter Consortium.
• Highsmith, J., 2002. Agile Software Development Ecosystems. Pearson Education, USA.
• Jacobson, I., 2002. A resounding "yes" to agile processes-but also more. Cutter IT J., 15: 18-24. Direct Link
• Lippert, M., P. Becker-Pechau, H. Breitling, J. Koch and A. Conrstadt et al ., 2003. Developing complex projects using XP with extensions. IEEE Comput. Soc., 2003: 67-73. Direct Link
• Martin, R., 2003. Agile Software Development: Principle, Patterns and Practices. Person Education Inc., New Jersey.
• Maurer, F. and S. Martel, 2002. Extreme programming: Rapid development for web-based applications. IEEE Internet Comput., 6: 86-90. CrossRef
• Pfleeger, S. and A. Joanne, 2006. Software Engineering: Theory and Practice. 3rd Edn., Pearson Prentice Hill, New Jersy.
• Pressman, R.S., 2005. Software Engineering: A Practitioners Approach. 6th Edn., McGraw Hill, New York.
• Qumer, A. and B. Henderson-Sellers, 2007. An Evaluation of the Degree of Agility in Six Agile Methods and its Applicability for Method Engineering, Elsevier B.V., USA.
• Riehle, D., 2000. A comparison of the value systems of adaptive software development and extreme programming: How methodologies may learn from each other. Proceedings of the 1st International Conference on Extreme Programming and Flexible Processes in Software Engineering, Addison-Wesley, USA.
• Jeffries, R., 2001. What is extreme programming. November 8, 2001. http://ronjeffries.com/xprog/book/whatisxp/.
• Rumpe, B. and A. Schroder, 2002. Quantitative survey on extreme programming project. Proceedings of the XP2002, (XP'02), July 2, 2002, Sardinia.
• Schwaber, K. and M. Beedle, 2001. Agile Software Development with Scrum. 1st Edn., Prentice Hall, New Jersey.
• Shine Technology, 2002. Agile methodology: Survey results. Shine Technologies Pty. Ltd.

Leave a Comment

Your email address will not be published. Required fields are marked *

Agile Framework Comparison: Scrum vs Kanban vs Lean vs XP

If you are new to Agile, it may hard to wrap your head around the concept. That is because Agile is just a set of abstract principles that are void of any particularities on how to turn them to life. Hence, there are all sorts of practice-oriented frameworks, the most popular among which are Scrum, Kanban, Lean, and XP.

While this is a comparison post, analyzing these frameworks is still a bit like contrasting apples with oranges, because some of these methods piggy-back on or complement one another (especially when they apply to different parts of the development lifecycle).

Scrum could be called the framework for Agile software development. Once, I met with colleagues from a previous job and told them that we were “doing Agile” at my new job. The first thing I got asked was, “Oh, so are you doing Daily Scrum and stuff?” In many people’s view, Scrum is synonymous with Agile.

Scrum is, first and foremost, a managerial framework . It’s about things developers do when they’re not writing code. Scrum explicitly prescribes a model, according to which developers plan their work, update their plans, and analyze how things went in retrospect. The framework introduces the role of Scrum Master, a dedicated person whose task is to facilitate the process and make sure it’s being followed.

The main Scrum “artifacts” (information disseminators) are:

• User Story . A small piece of functionality that the team is going to work on during a time-boxed period known as Sprint. The usual format is: As a [user role], I want [the system to do this and that], so that [such and such business value is delivered] . It must have a “Definition of Done” that will be used to determine if the story has been implemented properly.
• Task . It can be related or unrelated to a User Story. For example, setting up a new development environment or investigating a CPU memory issue are tasks that are unrelated to User Stories.
• Backlog . A list of User Stories and Tasks for future Sprints.
• Sprint backlog . A list of User Stories and Tasks (aka “work items”) picked from Backlog for the current Sprint.
• Product increment . A potentially shippable piece of functionality delivered at the end of the Sprint.
• Extensions . Reports like Burndown Chart, Velocity, etc. used to keep track of the team’s progress.

• Development Team . It includes developers, QA engineers, UI/UX designers, business analysts, and anyone else you need to deliver the new functionality. Scrum teams normally have three to nine members. When nine people is not enough, the team is split into two.
• Scrum Master. They host Daily Scrum meetings, planning/grooming/retrospective meetings, and help team members solve communication issues. Scrum Master is not a team member, so they can work with several teams at once.
• Product Owner . A stakeholders’ representative who communicates the vision (which serves as a basis for User Stories) to the Scrum team, prioritizes User Stories, and accepts/rejects them at the end of each Sprint.
• Commitment (to goals in the sprint)
• Courage (to do what you think is right)
• Focus (on the work items in the current sprint)
• Openness (about any challenges you face)
• Respect (trust that everyone is doing their best)

The Kanban framework was invented by a Toyota engineer Taiichi Ohno. In the late 1940’s, Toyota representatives observed how supermarkets restock their good based on what’s been picked off the shelves. This lead Toyota to create a supply system where production plans would be driven by actual consumption.

One of the key ideas of Kanban is to refrain from producing surplus . Kanban achieves this by using Kanban cards and a Kanban board to visualize how resources move through the production cycle. This gives everyone involved maximum insight into the process and helps managers address surplus/shortage in real time.

The Kanban system also introduces the notion of “pull” over “push,” meaning that workers pull in work according to their capacity, as opposed to work being fed to them on a conveyor belt or in the form of a to-do list.

In software engineering, Kanban means there’s a limit on the amount of work one can have in progress at a time. In other words, there could be a cap on the number of cards the team can have inside the “In Progress” column on the Kanban Board. This is done to increase focus and decrease context switching.

Another aspect of Kanban development is that activities are always tied to customer needs and that there is ongoing communication with the customer. Nothing is produced unless it economically benefits the customer.

• Focus – reduce multitasking
• Decrease waste
• Customer needs come first (i.e. their business needs – ROI)

• Visualization
• Limiting work in progress
• Flow management (can be done either by managing queues or by limiting work in progress)
• Making policies explicit
• Using feedback loops
• Experimental evolution

The key difference between Kanban and Scrum is that Kanban is continuous, while Scrum is iterative. Kanban is better suited for teams that have a lot of unplanned work coming up (support issues, emergency fixes, urgent feature requests) during the Sprint. This way, instead of waiting until the end of the Sprint, the team can start working on items as they appear and re-prioritize tasks on the fly.

Lean software development

To help you understand the essence of this approach, it’s best to tell you the story of its author Mary Poppendieck. In the 80’s, Mary found herself in a predicament. She was an IT manager at a large videotape plant where scheduling was done using the then-popular MRP software. The plant was in a precarious economic situation because their competitors from Japan were making higher-quality video cassettes faster and cheaper.

This had gotten Mary Poppendieck to consider adopting the “just-in-time” approach used by their competitor. Armed with a poorly-translated copy of the book written by a Toyota manager, Mary got down to work. As a result, almost immediately upon making the changes, the plant went from producing 60% of planned weekly pack-out to producing 95% of it .

The tremendous success Mary Poppendieck experienced with the plant and in her further career lead her to write Lean Software Development (co-authored with her husband, Tom Poppendieck). Because Lean borrows heavily from Kanban, you’ll see many similarities between the two approaches.

Just like Kanban, Lean strives to reduce waste and maximize value to the customer. Waste could be building the wrong feature, waiting/multitasking/switching, wasting time doing something that will never be used, or starting anew. There’s also the “pull” concept that comes from Kanban, as well as the idea that you should trust that your workers are making their best effort (i.e. have respect).

As for the differences, unlike Kanban, Lean has some prescriptions regarding engineering practices (TDD, for example). At the same time, Lean is less prescriptive on delivery time-boxes, with the team potentially being ready to deploy at any time.

Some other concepts frequently associated with Lean are the Minimal Viable Product, which is the version you release as soon as you can – often even ahead of writing any documentation – failing fast, and making binding commitments (such as main architectural decisions) as late as possible.

XP – Extreme Programming

Extreme programming started as an experiment by Kent Beck, who was working for Chrysler at the time. The idea was to take cherry-picked programming practices to the extreme and see what happens. For instance, instead of code reviews, you do pair programming, technically reviewing code non-stop. Later, as more companies began adopting this approach, certain rigid rules started to be omitted – such as daily integration tests.

Nowadays, one can see XP practices used by teams that utilize Scrum, Kanban, and other organizational Agile methodologies to squeeze the most out of the developers’ potential.

Contrary to conventional belief, XP does not simply equal pair programming. While pair programming is one the twelve practices used in XP (scroll down for the full list), it’s not the only one there is. XP offers an algorithm for process management, too.

Another thing to note is that ideally, all XP practices should be used together, or else they won’t work – because of this, critics have compared XP to “ a ring of poisonous snakes ” and “a house of cards,” where extracting one element renders the entire process ineffective.

The managerial aspects of XP have received some criticism from project managers. For instance, the customer being constantly present is considered a source of stress. Besides, having no requirements and designing the system on the fly may be very ineffective.

XP values very much correlate to those in Scrum. See the table:

Just like Kanban and Lean, XP also sees to it that no waste is produced, focusing on writing the code you need today instead of thinking about tomorrow, next month, etc. This is called the YAGNI (You Aren’t Gonna Need It) approach. There’s also the planning game that is done together with the customer.

• Planning game
• Test-driven development (“write unit tests first”)
• Pair programming
• Whole team (customer / actual user of the program is available for feedback)
• Continuous integration
• Refactoring of design improvements
• Small releases
• Coding standards
• Collective code ownership
• Simple design
• System metaphor (naming things something programmers, customers, and everyone else understands)
• Sustainable pace (no overtime)

In conclusion

In this post, I tried to clarify the differences between the four popular Agile methods: Scrum, Kanban, Lean, and XP. Like I wrote in the beginning, it’s not always possible to pin a particular practice to just one framework, and teams often use hybrid methodologies to organize an Agile development process.

Do you use any of these frameworks in your company? How is it working out for you? We invite you to share your experience in the comments!

Related Blogs

5 Success Stories That Will Make You Believe in Scaled Agile

Real benefits of adjoining DevOps culture to your Agile processes (supported by hard numbers)

with ObjectStyle

Alesia Krush

• 14 Nov 2017
• Agile ${context.post.category.name} -->

UX Design in Agile: A DSDM Case Study

• Conference paper
• Cite this conference paper

• Laura Plonka 8 ,
• Helen Sharp 8 ,
• Peggy Gregory 9 &
• Katie Taylor 9  

Part of the book series: Lecture Notes in Business Information Processing ((LNBIP,volume 179))

Included in the following conference series:

• International Conference on Agile Software Development

3672 Accesses

11 Citations

1 Altmetric

Integrating User Experience (UX) design with agile development continues to be the subject of academic studies and practitioner discussions. Most of the existing literature focuses on SCRUM and XP, but in this paper we investigate a technical company who use DSDM. Unlike other agile methods, DSDM provides a configurable framework and a set of roles that covers the whole software development process. While elements of the UX design integration experience were similar to those reported with other agile methods, working practices to mitigate the challenges were identified using DSDM’s standard elements. Specifically, communication challenges were mitigated by extending two of DSDM’s standard roles. In addition, a change of focus between a design-led phase and a development-led phase of the project changed the communication challenges. Agile teams need to be aware that this change of focus can happen and the implications that it has for their work.

This is a preview of subscription content, log in via an institution to check access.

Access this chapter

Subscribe and save.

• Get 10 units per month
• Download Article/Chapter or eBook
• 1 Unit = 1 Article or 1 Chapter
• Cancel anytime
• Available as PDF
• Read on any device
• Instant download
• Own it forever
• Compact, lightweight edition
• Dispatched in 3 to 5 business days
• Free shipping worldwide - see info

Tax calculation will be finalised at checkout

Purchases are for personal use only

Institutional subscriptions

Unable to display preview.  Download preview PDF.

Similar content being viewed by others

Understanding the UX Designer’s Role within Agile Teams

The Gap Between UX Literacy and UX Practices in Agile-UX Settings: A Case Study

A Systematic Mapping on Agile UCD Across the Major Agile and HCI Conferences

Abelein, U., Sharp, H., Paech, B.: Does Involving Users in Software Development Really Influence System Success? IEEE Software 30(6), 17–23 (2013)

Article   Google Scholar  

Constantine, L.L.: Process agility and software usability: Toward lightweight usage-centered design. Information Age 8(8), 1–10 (2002)

Google Scholar  

Sharp, H., Robinson, H.M., Segal, J.: eXtreme Programming and User-Centred Design: friend or foe?. In: Proceedings of HCI 2004, 2nd vol. (September 2004)

Chamberlain, S., Sharp, H., Maiden, N.A.M.: Towards a Framework for Integrating Agile Development and User-Centred Design. In: Abrahamsson, P., Marchesi, M., Succi, G. (eds.) XP 2006. LNCS, vol. 4044, pp. 143–153. Springer, Heidelberg (2006)

Chapter   Google Scholar  

Garrett, J.J.: The Elements of User Experience: User-Centered Design for the Web. New Riders Publishers, Indianapolis (2002)

Dingsoyr, T., Dyba, T., Abrahamsson, P.: A preliminary roadmap for empirical research on agile software development. In: Proceedings of AGILE 2008, pp. 83–94. IEEE (2008)

Abrahamsson, P., Warsta, J., Siponen, M.T., Ronkainen, J.: New directions on agile methods: A comparative analysis. In: Proceedings of ICSE 2003, Portland, Oregon, USA (May 2003)

Fowler, M., Highsmith, J.: The agile manifesto. Software Development 9(8), 28–35 (2001)

DSDM Consortium (2013), http://www.dsdm.org/dig-deeper

Ferreira, J., Sharp, H., Robinson, H.M.: User Experience Design and Agile Development: Managing cooperation through articulation work. Software Practice and Experience 41(9), 963–974 (2011)

Ferreira, J., Sharp, H., Robinson, H.M.: Agile Development and User Experience Design Integration as an Ongoing Achievement in Practice. In: Agile Conference (AGILE 2012), pp. 11–20 (2012)

Haikara, J.: Usability in agile software development: Extending the interaction design process with personas approach. In: Concas, G., Damiani, E., Scotto, M., Succi, G. (eds.) XP 2007. LNCS, vol. 4536, pp. 153–156. Springer, Heidelberg (2007)

Broschinsky, D., Baker, L.: Using Persona with XP at LANDesk Software, an Avocent Company. In: Proceedings AGILE 2008, pp. 543–548 (2008)

Kane, D.: Finding a place for discount usability engineering in agile development: throwing down the gauntlet. In: Proceedings of ADC, pp. 40–46 (2003)

Cho, L.: Adopting an agile culture. In: AGILE 2009, pp. 19–25. IEEE Computer Society, Los Alamitos (2009)

Kollmann, J., Sharp, H., Blandford, A.: The importance of identity and vision to user experience designers on agile projects. In: Proceedings of the 2009 AGILE Conference, Chicago, IL, USA, pp. 11–18. IEEE Computer Society (August 2009)

Sy, D.: Adapting usability investigations for agile user-centered design. Journal of Usability Studies 2(3) (2007)

Sy, D., Miller, L.: Optimizing Agile user-centered design. In: Proceedings of CHI 2008 Extended Abstracts on Human Factors in Computing, pp. 3897–3900. ACM, New York (2008)

Patton, J.: (2013), http://agileproductdesign.com/blog/emerging_best_agile_ux_practice.html (accessed September 6, 2013 )

Nielsen and Norman group report (2013), http://www.nngroup.com/reports/agile-development-user-experience/

Gregory, P., Plonka, L., Sharp, H., Taylor, K.: Bridging the Gap Between Research and Practice: The Agile Research Network. In: Proceedings of European Conference on Research Methodology for Business and Management Studies (June 2014)

Avison, D.E., Lau, F., Myers, D., Nielsen, P.A.: Action research. Commun. ACM 42(1), 94–97 (1999)

The Agile Research Network in conjunction with LShift Ltd: Integrating UX design into a DSDM project: challenges, working practices and lessons learned (2013), http://agileresearchnetwork.org/ux-white-paper/

Isomursu, M., Sirotkin, A., Voltti, P., Halonen, M.: User Experience Design Goes Agile in Lean Transformation – A Case Study. In: AGILE 2012, pp. 1–10 (2012)

Budwig, M., Jeong, S., Kelkar, K.: When user experience met agile: A case study. In: Proceedings of CHI 2009 Extended Abstracts on Human Factors in Computing, pp. 3075–3084. ACM, New York (2009)

Gothelf, J.: Lean UX Applying Lean Principles to Improve User Experience. O’Reilly Media (February 2013)

Ungar, J., White, J.: Agile user centered design: Enter the design studio - a case study. In: CHI 2008 Extended Abstracts on Human Factors in Computing Systems, pp. 2167–2178. ACM, New York (2008)

Download references

Author information

Authors and affiliations.

The Open University, Walton Hall, Milton Keynes, MK7 6AA, UK

Laura Plonka & Helen Sharp

University of Central Lancashire, Preston, PR1 2HE, UK

Peggy Gregory & Katie Taylor

You can also search for this author in PubMed   Google Scholar

Editor information

Editors and affiliations.

Department of Computer Science, Systems and Production, University of Rome "Tor Vergata", Rome, Italy

Giovanni Cantone

Department of Electrical and Electronic Engineering, University of Cagliari, Cagliari, Italy

Michele Marchesi

Rights and permissions

Reprints and permissions

Copyright information

© 2014 Springer International Publishing Switzerland

About this paper

Cite this paper.

Plonka, L., Sharp, H., Gregory, P., Taylor, K. (2014). UX Design in Agile: A DSDM Case Study. In: Cantone, G., Marchesi, M. (eds) Agile Processes in Software Engineering and Extreme Programming. XP 2014. Lecture Notes in Business Information Processing, vol 179. Springer, Cham. https://doi.org/10.1007/978-3-319-06862-6_1

Download citation

DOI : https://doi.org/10.1007/978-3-319-06862-6_1

Publisher Name : Springer, Cham

Print ISBN : 978-3-319-06861-9

Online ISBN : 978-3-319-06862-6

eBook Packages : Computer Science Computer Science (R0)

Share this paper

Anyone you share the following link with will be able to read this content:

Sorry, a shareable link is not currently available for this article.

Provided by the Springer Nature SharedIt content-sharing initiative

• Publish with us

Policies and ethics

• Find a journal
• Track your research