A Business Competitive Advantage with Agile

Create a Business Competitive Advantage with Agile. This post will discuss Value-Driven Delivery, which is core to agile development. If you want your business to survive in today’s competitive environment, you need to find a way to add value to your customers. You must figure out ways to create a competitive advantage in order to survive and stay relevant in your industry. In today’s market where information continues to grow exponentially and products are delivered faster, it is even more important to provide customer value. One thing a business should do early in their business lifecycle is to define a competitive advantage that differentiates them from the competition and gives an edge over all other competitors.

Agile development can facilitate a competitive advantage through value-driven delivery, which focusses on delivering the highest customer value early on in the project.  The Agile Manifesto tells us about 4 values and 12 principles for software development and some of them relate well with value creation. They include: “Working software over comprehensive documentation”, “Deliver working software frequently”, and “Working software is the primary measure of progress”.

Projects are generally undertaken to create business value, whether it be to improve an existing application or to develop an entirely new product. Sometimes a project is needed to address a regulation or there might be a security issue. All of these things have one thing in common – to provide business value, whether it be to generate a competitive advantage or to improve something. So if delivering value is the reason to take on a new project, then agile will work well for you.

Challenges With Traditional Waterfall Project Management

The waterfall methodology follows a plan-driven approach, which relies on up-front planning and requirements gathering before the project begins execution. Most requirements are based on assumptions and once approved by the stakeholders, they are “baselined.” Changing requirements after the project executes usually means a change request is needed. Many times the customer will not see working software until the end of the project, which can cause a huge risk. What happens if the results do not produce customer value and the solution missed the mark? Even if the project is under budget and on time, it still may not be valuable to end users.

Figure 1 below will illustrate the cone of uncertainty that shows how the level of uncertainty in a project decreases as time goes on:

Figure 1: The Cone Of Uncertainty for a typical waterfall project

The cone of uncertainty illustrates to us there is a certain degree of uncertainty at the beginning of any project, regardless of methodology whether it be agile or waterfall. As time progresses, that level of uncertainty decreases as execution begins and more is known about the solution. In a waterfall environment, there is heavy emphasis on upfront planning before the project begins execution. This is where scope, requirements, and design are all captured. An extensive, elaborate project plan is created, base-lined, and can only change through a cumbersome change request process. Here’s the problem: Requirements change! When the project moves to execution, it is more expensive to change a software system as time goes on.

Agile development tries to address the shortcomings of waterfall by planning the project in smaller increments, building and releasing smaller pieces of functionality in each iteration.  This allows for frequent customer feedback and the ability to change direction more easily as more is learned as the project unfolds. See figure 2 below:

Figure 2: The iterative process of Agile development

Let’s take a look at how the Cone of Uncertainty looks in an Agile project environment:

Figure 3: Cone Of Uncertainty for an Agile project

Here we can see how the project is planned, developed, tested, inspected and reviewed in increments or sprints. Each sprint is like a “mini-waterfall” and at the end of each sprint, there is a review and retrospective. The customer is able to see working software at the end of each sprint, which allows a frequent opportunity to change requirements if they do not satisfy the customer needs. This continues throughout the project lifecycle.

Let’s look at how Value-Driven Delivery fits into an iterative project using Scrum. Agile focusses on delivering the highest customer value early on in the project.  In this example, the Product Owner keeps the Product Backlog prioritized and updated with the highest value items ranked at the top of the backlog. As the first several sprints are executed, the Product Owner, knowing what is the highest priority and most valuable to the customer, will want the team to work on these items in the first few sprints as seen in the example below. The team will discuss these items during their recurring sprint planning sessions and execute the work on those highest value items first to get the most value delivered to customers as early as possible.

Prioritizing Value

Prioritization is a fundamental of Agile. The second Agile principle tells Agile teams to: “Welcome changing requirements even late in development.” As the team progresses through the project, it is expected requirements will changed and that provides value to the customer as we can make changes based on frequent feedback.

Customer-Valued Prioritization

Customer values prioritization is the process of working on those items that give the highest value to the customer first. Refer back to Figure 4 and take note those highest value items are in Sprint 1&2. The Product Owner must is responsible for keeping the items in the backlog prioritized based on business value.

MoSCoW

The MoSCoW is a prioritization schema that derives its name from the first letter of the name: Must have, Should have, Could have, Would like to have

Must have – These are features that are fundamental to the system. Without these features, the system will have no value. Must have’s are your Priority 1 items.

Should Have – These features are important and should be there. Without these features, the system will work, but may need some type of work around or may not work as efficiently.

Could Have – These are useful additions that add some type of tangible value.

Would like to have – These are nice to have features but will probably not be included in the system.

There are many other ways to drive value to your customers.

Summary

Agile can help you create a business competitive advantage. If you follow Agile principles and values, focus on your customers highest needs that drive value, focus on delivering those highest prioritized items early in the development process, get feedback from your customers, and make changes according to that feedback, you can gain an advantage. The team must be well-disciplined in following agile principles and values to really be successful.

If you would like to understand Value-Driven Delivery in more detail, or have any other questions, please contact us!

If you liked this post, please share it using the share buttons below.

Thank you!

Leave a Reply

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