Why Is Agile the Way to Go for Digital Transformation Projects?

Why Agile? Because You Learn as You Implement

Digital Transformation can affect almost every aspect of an organization’s operation:

• Any information gathering and storing process.
• Any information or documentation creation process.
• Any information sharing process across teams, departments or systems.
• Any part of the customer, partner or employee experience.
• Etc. Etc. Etc.

The realm of possibilities being so great, it is almost impossible to plan everything ahead of time and get the optimal outcome. Invariably, as your organization works on its Digital Transformation, new things will be learned and new ideas will come up that may very well be better than the initial set of ideas that was planned:

• “Instead of focusing on process A, we should really focus on process B; the impact will be much greater.”
• “Wait, you can do that?! Oh, we need this right now for process C.”
• “You can integrate this with that?! Wow! We waste hours and hours on this and that every week. We need this integration.”
• Etc. Etc. Etc.

Using Agile methodology, instead of Waterfall, your project will be shaped by:

• Communication throughout the project.
• Requirements gathering in logical, continuous sequence.
• User tests at regular stages of the project.
• And using all of the above, your will learn and increase your knowledge of the possibilities, thereby improving your decision making at every step.

This process will enable you, your teams, and your organization to:

• Implement new ideas quickly.
• Learn as quickly from each implementation.
• Do user acceptance testing throughout the project, thereby validating every sprint or milestone, and reducing project risk.

From what is learned along the way:

1. Tweaks to the initial implementation can be done.
2. Prioritization of deliverables can change.
3. New items can be added to the scope.
4. Etc. Etc. Etc.

Avoid Waterfall… It Simply Won’t Go as Planned

By contrast, if a project’s scope and details are set in stone from the very beginning— the moment in time where your knowledge of the possibilities is the smallest— your project will be shaped by:

• Communication mostly at the beginning of the project as stakeholders try to foresee everything when they know the least.
• Requirements gathering that is front-loaded, with decisions made with very limited purview.
• User tests done in bulk at the end when it is too late to correct course.
• And because of all of the above, a large part of the learning and knowledge increase comes at the end with the user tests. Unfortunately, all that knowledge cannot be put to good use, because all the important decisions were already made.

Because of this, you may very well miss the mark on:

• Achieving goals that are smaller than what Agile would’ve yielded.
• Achieving goals that are no longer your organization’s goals (considering the speed at which businesses move).
• Missing the initial goals, as the knowledge used to set scope and details was incomplete and lacked understanding or vision.

These are all very likely when using Waterfall methodology in Digital Transformation.

Maximize the Information You Have at Each Point of Decision

Using Agile enables you to make increasingly enlightened decisions as you incrementally implement your Digital Transformation.

Start with the most obvious, easiest to implement, easiest to modify and less risky elements of your project. By doing so, you will learn more about future possibilities at each step of the process. This will enable you to readjust, tweak, re-prioritize, and improve the remaining elements of your project.

The graph below shows Agile and Waterfall compared, as it pertains to the increase of knowledge during implementation work.

Agile is characterized by short cycles of implementations and user tests, which enable fast-paced learning and improvement to decision-making. In contrast, Waterfall’s blinders-on approach increases the risk of getting stuck with the wrong outcome.

Even in Agile, De-risk the Structural Aspects of the Project

Using Agile doesn’t mean improvising. Structural aspects of your Digital Transformation, like selecting a platform, or architecture, may require a commitment beyond Agile. But for the rest of your project, Agile is the way.

Considering how fast the business world is changing — and the speed at which the digital space evolves to provide more possibilities to businesses — you can assume that the most “agile” (scalable, flexible, polyvalent) platform or architecture is likely to be the best fit for the future of your organization.

Sprint Length?

Any conversation about Agile  irrevocably leads to discussions about sprint length and other Agile technicalities. In the case of a Digital Transformation project, there is no set of stringent or perfect guidelines that everyone should follow. Why? Because these projects vary considerably.

For example, if we take a project involving the Salesforce CRM, you could have wildly different project scopes:

• Scenario 1: If you are simply creating custom fields in standard objects, or even simple custom objects, they could be ready to play with within a day or a few days. You don’t need to wait 2 weeks to start doing user acceptance testing.
• Scenario 2: If you are building a connector between Salesforce and a 3rd party application, you may use traditional sprints of 2 to 4 weeks and require several sprints before the connector is ready for user acceptance testing.

The Common Sense Approach

In some circles, Agile can be experienced like a religion, with strict rules and high priests who preach these rules with zealot-like fervor. You don’t need to go that far.

In Digital Transformation projects, Agile is better used as a common sense approach where:

• Structural elements should be de-risked early on.
• Low-risk elements that can be implemented quickly should be prioritized to help you visualize the change, play with the change, and learn from that change as soon as possible.
• The remaining project decisions and elements that are implemented afterwards will all benefit from what was learned earlier on in the project.
• Along the way, adjustments and changes in priorities can be made from what was learned.

It’s common-sense, enabled by Agile methodology.