Agile Transformation, done right! (April Fools Edition)

Introducing, a new way... the right way

This post is a joke (kind of), and was published on April Fools Day!

We've all heard it over and over again. "Agile Transformation" is necessary for growth in commerce. Frankly, I couldn't agree more. It's important during the transformation to go in with a plan, which you have to be sure is done upfront and takes a lot of time to get it 'right'. There's no sense in starting with an idea and iteratively going about implementing... as my grandfather said about Agile Transformations, "if it's worth doing, it's worth doing slow and with a ton of process".

Below are surefire ways to ensure your Agile Transformation is a massive success.

Do the planning upfront!

As we move away from waterfall implementation, it's important we still take parts of it along in our move to Agile. Something I've seen other retailers do well is sit down at the beginning of the transformation and list out all the epics of work for about three to four quarters in advance and then pick and maintain OKRs consistently over that time. That way, you can have much more security in what the team is going to produce, and have a roadmap to hand management. If you have a key new capability that has to be delivered then make sure to write all the requirements upfront and then track delivery of those for months until it's completed.

Make sure to add a ton of oversight!

Who doesn't like oversight, right?! You hired great product management that you're starting to call Product Owners, and what better way to make them feel they 'own' the product than to set up numerous weekly checkpoints and 'ceremonies'? That way, you can critique and influence everything they're doing to reach the roadmap you set out (see above).

One idea is to set up something like an "Agile Office" or "Winning Office". Forget the idea of self-forming groups that have autonomy... this way you'll have some control over the teams. While it may seem like a good idea to put more of your time into explaining the need for change and focusing on change management instead, don't... you'll need all of that time to be in meetings discussing the transformation.

Stick with the toolsets you had at the beginning

What can slow down your transformation more than taking the time upfront to let the team select the toolsets they need to be successful? Worse, what if they need things in the middle of the first few months of sprints... there's likely not going to be enough time. That's why in my mind it's safer to just use the same tools you used when you were delivering projects in a waterfall way. Large software like JIRA for project-based work will be just as good for Agile... Atlassian wouldn't have made it this long if they weren't good enough to be the all-in package for agile/scrum delivery!

Don't reach out to end users until you are in 'beta'

I don't know about you, but I get nervous about showing anything but the near-final product to my stakeholders and customers. What if they don't like it or want different things, or worse, what if it's not what they thought they wanted at the beginning? The safer plan, and the right way to make sure you meet your timelines is to just get 'near done' and then show them for any final changes. You can always "put it in the next sprint" later.

Let the teams define the change for themselves

The adage remains true when changing OpModels... "Change only happens to specific people in the organization." Don't bother creating a holistic plan around change, heck, don't even bother writing one down... just focus only on the first set of folks in the transition. They're the ones the change is happening to, not everyone else, yet.

Report often and early on the success of the change

It wouldn't be a success unless you talk often and early about how well it's going. The critical miss I often see is that people spend way too much time upfront defining what 'success' looks like. It's more important to just get started, and then ensure your weekly updates to leadership have a few screenshots of the output of the sprints. Something tangible is always better. Who doesn't like to sit in meetings looking at screenshots of prototypes?

Closing thoughts

Look, Agile is good. If I can leave you with one last suggestion is that you should treat the transformation as an event that happens to the organization. Let everyone know when the event takes place and keep them informed just enough.

Good luck!