Home | Blog | Articles | Why Is Agile the Way to Go for Digital Transformation Projects?
Why Is Agile the Way to Go for Digital Transformation Projects?
If you are planning to start or are already launching a Digital Transformation project within your organization, there are ways to manage this venture that can make a big difference on its outcome.
The main variable to choosing the right project approach is the answer to this question: Do you know everything (100%) that can be done to make your organization more productive, efficient, customer oriented, etc?
The answer is no.
You don’t know everything, because no one can know everything that Digital Transformation can bring to an organization. The possibilities are simply too vast.
This simple question and its answer point us in one direction when it comes to managing such a project: Agile.
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:
Tweaks to the initial implementation can be done.
Prioritization of deliverables can change.
New items can be added to the scope.
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.
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.