Consider a Bell-Curve based Agile Delivery Model

Getting started in new and complex client environments, a Bell-Curve based Agile delivery model may help reduce risks and offer a better probability of success.

Guest Commentary, Guest Commentary

July 5, 2018

4 Min Read

One of the first principles of Agile states that our highest priority is to satisfy the customer through early and continuous delivery of valuable software. The assumption here is that by delivering high-value elements early, the team demonstrates an understanding of the stakeholders needs and shows that they recognize the most important aspects of the project. This also helps get the stakeholders on board, quickly creating an early cycle of support for the project.

Delivering the highest business value early in the project is a winning strategy and a perfect recipe for success wherever the delivery teams can make it happen. This article attempts to tailor this principle for a more realistic project environment.

Enter Tuckman

It is rare that an entire project team rolls over from one project to another. As theorized by Bruce Tuckman in his team formulation model, a new project team invariably goes through stages of Forming, Storming, Norming, and Performing on its way to peak performance.  

Forming and Storming are most critical periods from the human resources standpoint. This is the time of the project when little sparks fly; teams learn each other’s working style and ground rules are formed. Generally, this period does not represent a high level of trust or high throughput by the teams.

Enter environmental chaos

A new project is often broken-in similar to a new engine. Even with an optimized and reusable project delivery framework, a team struggles with environmental chaos during the initial stages of a project. New team members have to be on-boarded, granted multiple level of accesses by the client organization, resolve administrative issues like seating, travel, etc.  

Before a project team can work as a well-oiled machine, all the moving parts in the project need to break-in and find their rhythm.  This includes streamlining the build process, setting up version controls, navigating the release mechanisms at the new client organization, all of which require the team to complete a few end-to-end cycles to iron out the rough edges.

Challenges in delivering highest business value first

Let us revisit our original Agile principle of delivering the business value early. The highest business value also closely ties to technologically more complex and involved stories in the product backlog. For new teams, attempting to deliver the highest business value when they are navigating through the initial phases of the project can significantly reduce their chances of initial success. This additional pressure usually creates more friction and turns down the fun and excitement.

Start with small wins

It is said that “Nothing succeeds like success,” and early wins are important for the team’s morale and stakeholders’ confidence. In order to build early success and tide over the team formation and break-in hiccups, it is proposed to use a left-skewed Bell-Curve Agile delivery method.

Business value and technical complexity are often entwined. For some teams a story point may reflect efforts but not the technical complexity. For other teams, the complexities may already be weighed in while coming up with the story points. The Agile team and product owner can be the best judges to determine the numerical model to weigh complexity and efforts for the bell-curve model.

To follow the Bell-Curve based Agile delivery method, the Agile team and the scrum master will organize the product backlog into a theoretical Bell-Curve, during the backlog grooming ceremony. The sprint team then can pick items from the product backlog for each sprint – left to right – not necessarily in sequence. This will help the teams to establish a flow, deliver small increments of success quickly, and move to the next progressively complex iteration.

It is important to note that the recommendation here is not to pick up all low hanging fruit, rather to taste a few low hanging fruits before climbing the tree.

A similar situation happens during ramping down of the project, when resources are looking for new assignments, headcounts are dropping, and critical business components are already released and integrated into the CI/CD pipeline.

The Bell-Curve approach helps to defer non-critical features later into the project and execute the most critical business components during the period of peak performance.

Project planning is often idealism layered with more shades of pragmatism. In an idealistic world, we should attempt to deliver the highest business value earliest in the project for all the advantages it offers. For the rest of us navigating new and complex client environments, a Bell-Curve based Agile delivery model may help reduce risks and offer a better probability of success.

Santosh_balan.jpg

Santosh Balan is a technical project manager working for Fujitsu America. He has deep interest in technical infrastructure and cloud technologies, having provisioned complex, enterprise grade infrastructure for private data centers and cloud migration. He has an MBA in information technology in addition to other technical certifications and training.

About the Author

Guest Commentary

Guest Commentary

The InformationWeek community brings together IT practitioners and industry experts with IT advice, education, and opinions. We strive to highlight technology executives and subject matter experts and use their knowledge and experiences to help our audience of IT professionals in a meaningful way. We publish Guest Commentaries from IT practitioners, industry analysts, technology evangelists, and researchers in the field. We are focusing on four main topics: cloud computing; DevOps; data and analytics; and IT leadership and career development. We aim to offer objective, practical advice to our audience on those topics from people who have deep experience in these topics and know the ropes. Guest Commentaries must be vendor neutral. We don't publish articles that promote the writer's company or product.

Never Miss a Beat: Get a snapshot of the issues affecting the IT industry straight to your inbox.

You May Also Like


More Insights