Warning Signs Your Agile Programme has Jumped the Shark…

Some people have recently commented that HAAR comes across as ‘satirical’ and even ‘cynical’, well mostly by members of the evangelical Agile church who have a solid history in gaslighting those who choose not to blindly follow their doctrine (or at least their version of the official doctrine...).

So, with that in mind, we have taken a new approach and rather than pointedly note the follies of large organisations, we have chosen to post an educational piece to help people identify the key signs that your organisation has gone too far with Agile, and what the next steps should be.

If you self-identify with any of the points below, you might be jumping the proverbial shark:

1: The Agile Programme is led by a department attempting to drive organisational change using a delivery methodology they know nothing about:

• When Agile is implemented as part of an ‘organisational change programme’, you know someone has attended a Big 4 Consulting snake oil presentation where they were spruiked the virtues of ‘doing Agile’ without really understanding the finer points of what Agile actually is, the nuances of running different sorts of projects within their organisation, the true long term investment costs, or clearly understanding the general apathy to yet another change programme. They’re sold a belief that traditional project methodologies are somehow bad or flawed, and that by changing people’s mindset in conjunction with ‘doing agile’ they will magically transform an organisation to providing delivery better and / or meet their customer needs in more timely fashion.

• While there are absolutely some great benefits in adopting Agile principles, the reality is project delivery and outcomes are not something that can be simply templated, a software development ideology isn’t necessarily something that can be applied to all activities, and the total cost of Agile ownership (people, processes, tools, training, managerial overhead, change, organisational disruption and eventual apathy) may negate the perceived savings. One size fits all approach is always a recipe for disaster.

2: The organisation implements dictatorial governance structures with restrictive templates to drive reporting consistency (and other theoretical excuses):

• When the people won’t do what they’re told, then just make it mandatory for them to do so! After all none of them will ever have the nous, education, experience, or strategic thinking of the people making the decisions at the top, right?!?!

• When an organisation starts to aggressively dictate how people need to do their work and introduce controls such as performance measures and locked down templates, you know that the true intent of Agile has been compromised. Claiming to be Agile while controlling every aspect of how people operate and perform, isn’t really being Agile. In fact, it’s largely reverting to the perceived shortfalls of the structure project management the consultants originally said they’d take you away from!

3: The Agile Team act in isolation and don’t seek or act on feedback from the people actually doing the work:

• Often at the start of the Agile ‘Enlightenment’ phase, there is little knowledge within the organisation of what Agile is, how it should be implemented, and where it should be used, which is fertile fields for teams focused on change for change sake. At this point, engaging for wide reaching feedback is probably of questionable value given the inexperience (or care factor) of most people to be impacted by the pending changes. However, over time the people doing the work gain firsthand ‘insights’ and ‘experience’ with the new processes, and particularly what does and doesn’t work. As such, their feedback should be sought, understood, acknowledged, and truly considered if the Agile Team wishes to practice what they preach.

• Unfortunately, what tends to happen is organisations have Agile Programmes driven by secretive teams locked away in isolation, guided by ‘consultants’ supported by seconded workers indoctrinated to a prescribed song sheet, who hide behind layers of Compliance Officers Management and Comms Teams who protect them from direct interaction from the common people. They develop theoretical representations of how their version of Agile should be implemented, and then throw their models over the wall with an expectation that the people will simply comply. They rarely seek meaningful feedback with any information garnered either selectively used to provide justification for a ‘focus area’ they wish to push, or have it summarily dismissed because it contradicts their plans – be that legitimately or not.

4: Supporting Agile enterprise tools are too complex:

• When the implementation of tools to support Agile Sprint / Kanban processes, perform CI/CD, manage finances, control resources (aka ‘people’), facilitate reporting in a way that brings everything together to represent relevant information to the right people at the right time, takes this long to describe in one sentence, you know it’s never going to work out well…

• Unfortunately, these tools are often single purposed independent systems developed by vendors with different views on what a good interface looks like. They either relive the good old 1990’s ‘green screen’ days in a web form, or alternatively had the grad who ‘likes doing cool charts’ let loose on the GUI.

• What they usually have in common is that the cheap ‘out of the box’ templates provided are devoid of the fields or functionality required by the business, so mass customisation occurs that never really does anything particularly well and requires additional tools to bring everything together. Add the time of the users trying to understand, navigate and ultimately use the tools, and it’s no wonder people question the ultimate value of the effort required.

5: There is a belief the Executive team will use the Tools with improved ‘data quality’:

• When the Agile Team blame ‘data quality’ as the reason the Exec team don’t use the tools they’ve built, you know they are haven’t found the balance between the tool being a decision ‘support’ system vs. the only place to get information, nor really understand the care factor of the people doing the work.

• What tends to happen is those responsible for developing tools lose sight that the people using them have varied care factors for fancy dashboards which drill down to the n’th degree, when it’s usually easier to just ask someone. Often, the people doing the work don’t have the luxury of time to update everything correctly all the time (be that because of tool usability, repeated data entry in multiple places, actual relevance to their daily activities, or their hatred of it because they only like Opensource stuff…), and those at the top usually find it easier to just ask the person responsible for a verbal update rather than waiting for a report to generate on a screen – then call someone anyhow... Additionally, a report developed for one person rarely is what another is looking for and trying to find a ‘happy medium’ means no one is every satisfied – so no one wins.

• The key issue with tools is they don’t provide context, and without that a report is just data that still needs to be explained. They are a great conversation starter and record keeper, however rarely useful in delivering actual outcomes.

6: Managers are forced to become Agile Compliance Officers, not advocates for delivery:

• When people repeatedly provide constructive feedback to their management teams, however, are either ignored or dismissed for not being in lock step with the official line, you know that the ideas of ‘continuous improvement’ and ‘allowing the team to decide’ are not truly important to them.

• A lack of responsiveness from management is usually due to KPI induced compliance paranoia and / or an overdose of drinking the corporate cool aid. Not genuinely understanding, considering and responding to people’s concerns show it’s easier to go along with than challenge the status quo. Often the managers agree in principle, however, are ultimately powerless to affect change.

• Until Managers are empowered to truly effect change with the Agile Team, they are just acting as compliance officers rather than effective managers supporting their people.

7: The Agile teams blame ‘detractors’ for not having the right ‘mindset’:

• When the Agile Team start labelling and blaming people for not blindly following the doctrine, you know that their focus isn’t really about improvement, however more about people working as a team, and doing things their way.

• The irony of this situation is that often the people who provide genuine criticism are those with a vested interest in truly improving end delivery and organisational culture. By genuinely critiquing what has been proposed, it is more likely that real improvements will be achieved, as opposed to feedback largely about propping up someone’s ego. Additionally, the concept of someone having the ‘wrong’ mindset seems totally incongruent with ensuring an organisation has a diverse ecosystem of ideas and approaches. Disagreement doesn’t mean divergence from a common goal...

• Please note HAAR only accepts positive feedback. We’re people with our own mindsets too you know.

8: Traditional Project Management roles are marginalised:

• When Project / Programme / Portfolio Managers etc. are marginalised by the Agile team it shows a lack of appreciation for the risk, financial, scheduling, vendor engagement, stakeholder management, contract management, executive reporting, and general magic these people do in the background.

• An experience PM with Scrum Master training brings a different proposition than someone who has merely completed a scrum master certificate online, knows how to move cards on a Sprint board, and ask someone if they agree with the points allocated to a card. Being able to have context and experience with end-to-end delivery activities is a major advantage when supporting a team, be that for a Scrum, waterfall, or back of a napkin thing.

9: Agile ‘Coaches’ are quietly removed because nobody believes they provide any value:

• Ah, the much-maligned Agile Coach fraternity, the veritable canaries in the coal mine! When you start asking if anyone knows where that person who used to sit at the back of the room and take notes, although didn’t actually do anything, has gone, you know the wheels are either falling off the Agile train.

• To be fair, not all Agile Coaches are alike - some do indeed buy cookies for their teams, however they’re often people with no more experience than they people they’re working with and often became ‘qualified to coach’ by watching a couple of videos online. Good ones do indeed exist, however often they are marginalised by lack of engagement by the people they’re their to support, or by their own Agile Teams command and control approach.

10: The Agile team thinks every project is a software development activity:

• When ‘Agile means Sprints’ becomes the unwritten (or in many places, the written…) rule you know the game is up. Despite the Agile team waxing lyrical that it is ‘up to the team to decide what is the best way to deliver’, you know the people passing down the directives really don’t understand how the real world operates, particularly when the work performed doesn’t gain any tangible benefit by converting delivery models.

• Organisations need to consider if the time spent squeezing waterfall (or other…) projects into sprints so the reporting tool will work is really an effective use of people’s time and the company’s money. Sometimes, the additional effort required to implement Agile doesn’t add up. Just check out the Exec dashboard, there’s sure to be a graph that shows that…

11: People become commoditised:

• When the idea that people can suddenly cross skill between disciplines (usually without funded training), and that resource allocation is simply a tool function, then it shows the people have become commodities to the Agile Team, and not a diverse eco system of varied thought and innovation.

• Interestingly, people are a diverse and strangely funny species where some work well together, some don’t, many are good at some things and not others, and a select few are intrinsically just jerks. Knowing this means that just because a person has certain skills, doesn’t mean they’ll fit the culture of a particular team or should change who they are because they don’t fit the Agile Teams mindset. Innovation is critical in any organisations ongoing growth and when you commoditise the people, you stymie this opportunity in its tracks.

12: ‘Following the process’ becomes more important than delivering outcomes:

• When the focus of the Agile Team appears to be more about people doing work using the exact same process, templates, taxonomy, and mindset they’ve developed, and not on people being able to do their job, then you know that it’s less about business improvement and more about people keeping themselves employed – because it’s all about that next extension…

• A truly Agile organisation is one that will allow people to pivot and change easily, however when the focus is more on someone following predefined bouncing ball, you know that they’re probably not going to be doing what’s best at the time.

13: The benefits are never backed by data, only anecdotal comments that seem to mirror an Agile Consultants sales brochure:

• When presentations claiming the benefits of Agile are repeating anecdotal claims oft made by the evangelist community, and ‘Halleluiah, Agile saved me!’ is yelled from select folks in meetings, it’s time to ask more pertinent questions like:

‘What is the total cost of implementation and ongoing maintenance, including management overhead, people, tools, consultants, compliance, internal marketing, training, etc for the full Agile Programme?’

‘What are the benchmarks recorded prior to the implementation of Agile that we are measuring meaningful success against, and how have we done?’

‘What is the improved time to market and sales figures directly relatable to the implementation of Agile?’

‘Why do I still have layers of people telling me what to do, when I was sold Agile as giving me more involvement and flexibility to contribute to the outcome for my customers?’

‘What really happened to the Agile Coaches, did they really exist?’

14. The People are clearly over it…

• This is the probably the most important sign! When people are clearly over the Agile Implementation activities, you know that the Fonz has landed, and nobody is cheering… Raised eyebrows, shrugging of shoulders, ignoring communications, rejecting meetings, and making comments like ‘why are they still bugging us?!?!’, ‘kill me now, not another Agile initiative’, are clear sign that the game is up and it’s time for something new…

• Perhaps the clearest sign that the halcyon days of the Agile Programme is over is when the people no longer show interest or care. Much like the Covid pandemic, at some point the people have moved on and the communications become white noise in a background of other things going on in people’s lives – usually them doing their actual jobs, not updating endless JIRA tickets they never look at again and going back to the PowerPoint pack the Exec really prefers…

So What next?

When you get more than a couple of the warning signs above, it’s time to stop, think and adapt at the Agile Programme level, and not just another retro by the people who like to cherry pick the things the think will justify their ongoing existence.

• Perform a genuine review of the Agile Programme.

Bring in an independent non-Agile evangelised team to ensure the actual intended benefits are being realised against the original benchmarks, or if there were no benchmarks whatever the expected outcomes were. Ensure that the review is run by people devoid of personal involvement in the existing Programme to ensure bias and self-interest is not at play.

• Meaningfully engage people impacted by the changes, not just an executive team.

Be truly agile and bring a selection of people, both advocates and detractors, together to review what works and what doesn’t. Ensure they are dedicated to the review process and that they play a leadership role in the outcomes determined, not just tokens in a broader Agile self-pleasure session.

• Rotate the Agile Leadership Team.

Assuming there is merit in continuing with some or all of the Agile programme (and there probably will be), it’s time to change the personal. At this stage, their ideas, concepts, and thinking will be locked into what they know. Continuing with the same mindset team won’t help you move forward to the next phase – what ever that may be...

• Don’t be afraid to say ‘Ayeeee, Agile is not the way’ (a Fonz quote to finish on!).

Time to look up Gated Chaos, we hear it’s the way of the future!

HAAR: Thought provoking critical thinking, without much thought.

* Caution, actual truth may be just as anecdotal as anything an Agile Evangelist proclaims.

#flowToAwesome / #gatedChaos