Agile known unknowns - Do's and Don'ts

(Credit: https://www.reddit.com/r/ProgrammerHumor/comments/86l0s2/someone_figured_out_the_reality/)

One of the strangest but nicest things I've ever heard a client say was "We're interested in doing things in a more Agile way and you embody it".

Nice because everybody likes a compliment. Strange because I'd never considered how I work as "Agile" in the project methodology sense. But we were both thinking of the same thing - getting good results at pace.

Agile as a project methodology has been around for yonks and is now the approved way of delivering Salesforce and IT projects in general. But projects still fail (a lot) or are late or simply deliver product clients don't use. Large projects, particularly in the IT sector, often go bad says Gallup. And from experience I'd agree a lot of IT projects are needlessly painful.

There are 2 interesting points that the Gallup report surfaces: Process isn't necessarily key. But people are.

Let's look at process first. Most of these projects, as mentioned, will use Agile as their project methodology with associated processes.

But Agile doesn't scale well at the enterprise level with large, separate, networked teams building components in development sprints and trying to stitch them together in SIT. Great vid here from the man, the legend, Jez Humble on why.

Which is why one of the original brains behind the Agile Manifesto, Pragmatic Dave Thomas, says Agile is dead. His talk touches on what my client was thinking: How can we "be" more Agile as opposed to "doing" Agile?

Dave provides the following handy breakdown;

• Find out where you are
• Take a small step towards your goal
• Adjust your understanding based on what you learned
• Repeat

And: when faced with 2 alternatives that deliver the same value choose the one that makes changes easier.

His talk also highlights that Agile was sold as delivering results and teaching tools to people who wanted a way of delivering IT projects at scale. This particularly applies to the outsourced IT services sector who typically deliver big transformational projects with associated big budgets. Big budgets mean high risk with a high fear of failure and the need to comfort stakeholders - what better way to do that than to say "we'll do Agile!" which to be fair makes some sense as Agile teams are well documented at delivering quality at speed. However, only some Agile teams and only on some types of projects.

What the Gallup report astutely identifies as missing pieces in understanding project delivery is the parts that aren't measured on a gantt chart or powerpoint - level of team member engagement, talent, drive, tenacity etc. coupled with organisational culture and personal culture. These are known unknowns but you'll never see them tracked or mentioned in any project approach. The unspoken assumption is that everyone is a talented, engaged and apolitical individual committed first and foremost to getting the job done.

But people that work in organisations for any length of time sometimes aren't focused, as a priority, on problem solving or speed of execution etc. What they're often focused on is making a good impression to their seniors in meetings, email trails, workshops and consensus building whilst at the same time attempting to negotiate the inevitable bureaucratic red-tape that comes with any organisation. And of course there's playing the age-old game of office politics with associated egos and power plays. I've lost count of the number of "alignment calls" that have dragged on needlessly because everyone has to have their say or speak as long as the next person often just repeating the same point a different way.

There's obviously ways of dealing with this kind of hassle-factor. Elon Musk famously suggested "walking away" from unproductive meetings and Larry Page's early management style aimed to address typical red tape and streamline decisioning.

Whatever the way adopted to address business meetings ad social dynamics, the deciding factor with "doing Agile" - is people and how low drag they make the process (whether that process is Waterfall or Agile or something else) and ultimately on how well they can execute.

Providing I've got good information - I execute well by anticipating, solving and implementing improvements in quality and speed of delivery on-the-fly or at particular stages while shifting lenses between big picture and technical minutiae. But within the bounds of in-context deliverables and timeframes. It's an approach that gets results and ensures build quickly. It isn't a methodology per ce. More problem-solving based on shifting focus, actively thinking through design actions and outcomes and leveraging experience in the technology space to mitigate risk. And what my client was alluding to in terms of "embodying" Agile.

However, all that activeness takes effort and mental bandwidth and a shift in focus away from trying to manage social dynamics or office politics. It helps I'm bright and have an OK memory. But it comes out of my engagement and commitment to deliver, my love for the technology stack and my aspiration to professionally execute on what I'm tasked with. Above all it comes from a need for speed and an awareness that the clocks ticking. I'm never going to take up time with a waffley commentary on a suggestion if a simple "yes, great idea. let's move on" will suffice.

But where does that leave my client trying to manage her delivery organisation into being more agile?

In a difficult position but not an impossible one. Project methodologies aside;

Do

• Ramp up your talent pool slowly over the course of a few months before cracking the big projects - it'll show you how they work, it'll bond the team and you can make changes if possible.
• Take a pragmatic look at your team - are they everything you've been sold on? If not, adjust your plans.
• Take a similar look at the wider organisational culture. Everywhere has mission statements and HR departments and internal marketing teams pushing an idealised corporate vision but what's the reality?
• Adjust planning if necessary to suit your team's temperament and raw talent. This might be tricky to position but better to get some slow wins on simple implementations than fail repeatedly on complex, quick ones.
• Find ways of teasing out performance metrics around the both the hard numbers as well as the "softer" areas like team engagement, rapidity of problem solving etc. Use this data to make informed, on-the-fly decisions.
• Ensure good, timely information. No matter how good the team bad or late info will always set them up to fail.

Don't

• Depend on a single individual or "lead" to somehow provide on-the-job training on the technology as well as performance coaching for junior team members during high speed sprints to mitigate poor-fit talent.
• Stick with a plan if it doesn't get results. Adjust and then adjust some more to get the result.

Ultimately trying to get implementations right at scale is a tricky business. But if it wasn't hard it wouldn't be as much fun.