Most organisations take an agile approach towards digital transformation. Sounds familiar? Read on to discover what you need to know to succeed (or survive) in the agile era.
There are a lot of agile frameworks out there that give guidance towards working agile. Scrum, SAFe, LeSS, to name a few. But don't worry, this article is not about those frameworks. Want to get some practical guidance in shaping your agile mindset? Here are the 7 things you should master.
You won't be very effective if you don't master this one. It's about all those dependencies that are keeping teams from moving faster. I'm not only talking about splitting work into small pieces, reorganising the order and thinking about alternative solutions. More importantly, I am talking about rethinking internal processes around: governance, compliance, management reporting, architecture, release management, HR, recruitment, etc. A lot of old habits need to be challenged. This is really why an agile transformation must be actively promoted by top leadership. If it's not? Stop right here.
2. Less is more
Also called "the art of -not- doing stuff". It's about all those acronyms out there that force you to think about what's really important, eg. MVP (Minimum Viable/Valuable Product), KISS (Keep It Simple Stupid), YAGNI (You Ain't Gonna Need It), etc. Beware this is not just about prioritising requirements. Look at some Fintech challengers (like Bunq and N26) where opening a bank account is just a matter of installing an app and taking a photo of your identity card. Think disruptive simplification here!
3. Be fact driven
"A picture or it didn't happen", is how we challenge our friends to prove their (questionable) claims. This principle is the equivalent: if it's not in production and proven to be valued by your customers, it is not relevant. So this is about going to production fast and frequently with features that add value to the customer. For each feature: challenge the why, set goals for success, build and test it, bring it live a.s.a.p., measure its success, improve it. And... have the guts to stop supporting a feature when proven not to be successful.
4. Later is better
There were times when big upfront design was the common practice. This principle is basically the opposite of that. It's about the art of delaying decisions until "the last responsible moment". One of the earliest uses of this phrase was in Poppendieck’s "Lean Software Development: An Agile Toolkit" (2003). The idea is that: the later we make decisions the better informed we are, so the better decisions we make. We all know examples of decisions that are outdated by the time they get applied. So the morale of this principle is: don't press, or feel pressed, to make decisions when there is no real need yet.
5. Failure is -the- option
One way to look at the maturity of an agile team is to look at its ability to deliver according to its promise. However, if a team has become very predictable it might have become too risk aversive. In "Everything We Do Will Become Experimental By Nature" I wrote about the need to experiment a lot. So putting it differently: if you are too predictable, you're just not experimenting enough. Don't be afraid to come back on a decision if things don't work out the way you expect. It's o.k. to fail and fail often, but fail fast and learn from it.
6. Mind the team
High performing agile teams are driven to continuously improve themselves by organizing what's needed to reach their next maturity level. Typically members of those teams have a T-shaped profile, eg. sharing a lot of common knowledge while having deep knowledge on certain specific topics. The Agile Manifesto states that: the best architectures, requirements, and designs emerge from self-organizing teams. I couldn't agree more. So make sure the "voice of the team" is equally heard as the "voice of the customer".
7. Look ahead, but not too far
Sometimes it looks as if agile is only about short term thinking. However, that doesn't mean we don't need a crystal clear vision of where to go to. Just as we need inspiring leaders to tell us where the organisation is heading towards, we need this on the level of the products we build and the enabling IT. I am talking about creating product and technology roadmaps here. Put them on the walls and discuss frequently. But honestly, don't look too far ahead or make it too big. It's more about the story. Things will change anyway.
That's it. I hope these resonate in your daily practice. As always, happy to hear your thoughts in the comments below.
This is the second in a series of blogs about different aspects of digital transformation. This blog reflects my personal view. What I write doesn’t necessarily reflect directions or views of the companies I work or have worked for.
This article was first published on LinkedIn. Cover image: iStock.com/RichVintage