I’ve been an Agile practitioner and evangelist for over 20+ years. That’s pretty much 2/3 of my career as a person that builds software.
Over those years, I’ve seen mindsets change on Agile and what it should and shouldn’t be used for. In general, the ‘shouldn’t be used for’ list has gone down. A progression from ‘should not’ to ‘could’ to ‘should’ to ‘absolutely should’ is the right direction.
But over that same time-period, I’ve watched a number of organizations, populated with very smart, creative and passionate people, struggle with their own Agile journeys. Subsequently, I’ve spent a lot of time working with those organizations and introspecting on my own. How do we make the Agile transformational journey more efficient, fruitful and more enjoyable?
Ironically, the way most organization look to start or advance a stuck Agile journey is to seek out a formula or ‘best’ practices as input into their enterprise plan. Think about that for a moment – taking a plan-based approach to move away from a plan-based approach. That’s an anti-pattern and the antithesis of the Agile mindset.
So what should we do?
The best way to speed up your Agile journey is not by reading articles, books, blog postings or seek some kind of formula to put together a plan. While those things can educate and even inspire, they maintain the slower path – albeit one that generally ‘feels safer’ for some.
A far better prescription is to follow an approach to the Agile journey that is in itself – Agile.
Now in sort of a cruel twist, the further along your Agile journey, the more obvious and second nature this advice seems. The hardest moves to make in the Agile journey are indeed ‘starting’ the journey in earnest. To let go of the waterfall / plan-based handrails and push off into a new way of thinking.
It’s actually quite difficult to prescribe a formula or recommend specific practices to follow, without an honest assessment of where you are truly at in your own journey. This is why Retrospectives (as a ceremony specifically defined by Agile) are especially important at the start (or to get unstuck).
A Retrospective is not the same as an Assessment.
A Retrospective is far less ambitious and is thus far more responsive to discovery and learning that comes with taking incremental steps. Retrospectives are more – well – Agile.
Now – once you’ve had your first true retrospective:
- Pick a few changes that balance significant value to the organization with challenging but achievable results by the team.
- Make those results quantifiable and measurable.
- Start practicing those changes with weekly team retrospectives to gauge how things are going.
- As the discomfort and awkwardness starts to fade, take on another change to practice.
- If at any time things aren’t measuring up to your goals, you may need to adjust or totally pivot. Sometimes you may just need to keep plugging away; giving the current change more time to sink in and make it your own.
- Repeat often.
Sounds simple – right? Of course the devil is of course in the details. Along each step in the journey, there is an opportunity to wander down the wrong path, get stuck or even flail around for a bit. All of which are perfectly OK – you’re learning! You just have to gauge and balance it with your organizational tolerance for expediency. Certainly if you want to move faster, some truly experienced coaching or project by example approaches can help move things along.
So why all the disinformation?
So if it’s as simple and intuitive as taking an Agile approach to an Agile transformation, why do so many people promote a plan-based approach to Agile transformation? Why do so many vendors present a cookie cutter, formula based approach to the whole thing?
My guess is that some of it is due to inexperience. Quite a number consulting firms have jumped on the Agile band-wagon. Glad to have them finally aboard, but lots of these folks were dissing on Agile or hedging hybrid-Agile just a few years back. Some still are. If you’re still stuck in a plan-based mindset, then everything looks like a plan-based nail.
Ohers are simply trying to monetize the Agile wave. While there is nothing inherently wrong with ‘selling Agile’ (books, training, certifications, tools, etc..), always keep in mind that what you’re buying is the *ability* to be Agile – not actually *being* more Agile. I can read a bunch of books, train and get certified in speaking a foreign language. However, nothing will replace practicing it. Especially, practicing it in difficult, non-contrived situations.
Taking an Agile approach to make the Agile journey is what Perficient believes. It is the basis for how we approach Agile transformation with our most valued and strategic customers.
OK, sure…. but where are the ‘tips’?
Not knowing the specifics about your organization, your team members or where you are at in your own journey – there are some general things that seem to always bubble to the surface in the customer retrospectives I’ve been a part of through the years. Some basic rules-of-thumb that may or may not specifically apply to your particular situation:
Do you REALLY have Executive Sponsorship?
Be realistic about how much “executive sponsorship” you really have. True executive sponsorship means accepting that a large part of the Agile journey is going to be about change. Change and learning new things is hard, awkward and messy. Mistakes will be made and it’s going to cost more for a while. You can avoid some common pitfalls and speed things ups with proper coaching and training; If your leaders (business and IT) don’t accept that either less is going to get done and / or that things are going to cost more, then you actually don’t have executive sponsorship.
Start in the right place….
Companies often start their Agile transformation in the wrong place. They focus too much on the development teams. They train and certify developers and project managers; who in their first real Agile project, run into some pretty complex, real-world scenarios and challenges that they don’t have the skills and experiences yet to deal with*.
*side-note: getting ScrumMaster certified only gives you a Scrum 101 understanding – but calling ScrumMaster certification something like ‘ScrumAware’ – wouldn’t sell as well, so – there you go). To use the language metaphor again – it would be like taking two days of high school Spanish, and then dropping you into a remote village in Chile where nobody speaks English.
Product Owners make the Agile world go round…
A far better approach is to start with the business side, focusing on your business owners. Work with them to develop a strong Product Owner mindset (training, certification, coaching and practicing). Transform your current ‘requirements’ process into a Lean mindset (i.e. fine grained, value-based, quicker time to market, self-funding / perpetuating, measuring and adjusting – even pivoting).
Even if your development team continues to operate using waterfall, they will at least start to shorten development cycles naturally (Agile-Fall) – and when it’s time to train / certify / transform them – a massive road-black will be alleviated since the business will already be operating in an Agile way.
You’ll also avoid the emergence of things like Product Owner ‘proxies’, decomposition and reconstitution of stories from requirements (and necessary traceability matrixes) and rework waste due to gaps created with up-front, thud-factor requirements approaches.
Failing to start in the right place with your Agile journey is why most Agile transformations are so painful and often perpetually stall.
DevOps is a two-way street
The next place to tackle is deployment. Make sure you focus not only on a ‘push to deploy’ mentality, but just as importantly the ‘push to back-out’ mentality. Both need to be automated to a point where everyone has the utmost confidence that not only can something be deployed quickly, but if there are problems – then it can be safely backed out just as quickly. Agile / Lean organizations absolutely rely on both of these. Failure to get this in place will short-circuit your Agile journey with just one bad deployment. Or at the very least, make everyone hate each other.
An automated test is a predictable test
Next stop – QA / Testing. Quite simply you need to be at 70% test automation or more before you try shortening iterations to anything short enough to be called Agile. Otherwise, your iteration cadence will continue to creep outwards as you accumulate more and more manual regression debt. Then you might even do something really silly like starting to shave down your regression testing and accelerating full throttle to total mayhem and unpleasantness.
Ok…. NOW – you can start the transformation of the development team. Life will be good.
Distributed teams, multi-shore and Agile…
About ten years ago, my answer to a panel question on whether you could do Agile with a multi-shore team was,
“Not only CAN you use Agile with multi-shore teams, but in my opinion – Agile is the ONLY methodology you should use with multi-shore delivery” – me…. ten or so years ago…on this panel thingy…
I remember it being a pretty cool moment. A bunch of representatives from the large (especially offshore) consulting companies had just answered that same question along the spectrum of ‘it’s not recommended’ to ‘absolutely not’. I answered last and it felt like the perfect setup. It was awesome.
I still believe what I said and we have lots of proof that it works. In fact it works great. The sense of team connectedness, transparency to progress and ability to quickly course correct that Agile brings is the perfect antidote for what people most dislike about working with offshore teams.
And – here’s the kicker: If you empower your offshore teams with Agile, it takes them to a whole new level of value in the lifecycle. Being a part of our global delivery teams for the past 12+ years has been the most rewarding collection of experiences in my entire career.
But make no mistake. Distributed Agile is not easy. It’s not ‘ScrumAware 101’ type stuff. So here’s the caveat: If you really want to be successful in Agile with distributed teams (especially offshore), you need to first make sure that your onsite Agile is really ‘Agile’. If your onsite day-to-day isn’t in order, then trying to inject a distributed team dynamic into this (especially offshore) is going to induce the worst of both worlds (plan based and pseudo-Agile). Everyone will end up hating each other and you’ll (wrongly) draw the conclusion that Agile offshore doesn’t work. But just to remind you – It can. It does; And in fact Agile is the BEST way to get the most from your offshore team. <boom… mic drop>
Beware the ‘hybrid chatter’…
If at any point during your Agile journey, beware when someone starts using the word ‘hybrid’ (or is chomping a little too eagerly at the bit to introduce a scaling framework like like SAFe. Really, really take a step back and ask yourself if you need to overlay non-Agile / non-Lean practices. This is ESPECIALLY true if you start hearing things like, “Well, our business is unique and we need to ‘adjust’ Agile to make it work”.
I’m not saying it doesn’t happen – and I honestly can argue both sides of the hybrid coin – I’m just saying be skeptical and hypercritical of any ‘hybridization’ rationalizations.
I also want to make a distinction here: ‘Self-organizing’ and ‘adapting’ are meant to be applied at the team level. Be wary of ‘institutionalizing’ things a bit too aggressively. When you start ‘institutionalizing’ adaptions then you start locking down levers. Levers the team can pull (and un-pull) as things change along the Agile journey: accumulation of team member experiences, new business imperatives, distribution of the team (geographically, chronologically and even culturally) and aspects of the environment itself.
It’s simple – just perfectly balance pragmatism, open-mindedness and skepticism. Ok?
Some final caveats…
The above isn’t a complete list and each one just scratches the upper surface of each of the topic areas. I also reserve the right to change my mind on any of the above at any time.
They are also not the only way to get there. For example: Can you still make progress on your Agile journey without true executive sponsorship? Yep. How about without the ability to start with the Product Owner? You bet.
And they are most certainly not meant to be simply written down and collated into giant document / deck with other ‘best practices’ harvested from other sources, and force fed to the organization. Because… yeah…. that’s kind of the definition of ‘institutionalize’ – see above.
Rather – the intent here is for each of them to ignite hours of healthy exploration. Conversation that leads to concrete, incremental new things to practice, measure and adjust. All the while on your own Agile journey. A journey that will hopefully be a bit more fruitful and expedient. And please have some fun while you’re at it.
