Agile Is Dead - How Can Something That Never Was Be Dead?

TLDR

This debate about agility is allegedly about getting more done, but its not. It’s about people being unhappy because the way we work can be disempowering, disrespectful and demeaning. It is horrible being on the end of a sustained drag of picking up individual tasks, doing them and picking up the next with no connection to the impact of that work or say in how or what should get done. This gets compounded when the relationship and communication is bad.

The problem I see is that organisational dysfunction predominantly effects the implementors and testers of the output of the dysfunction. I rarely see product owners, delivery people or designers on calls late at 2am when everything is going wrong. The effects of underinvesting in one place, and so getting this stuff wrong in many areas are not paid by those areas. It is engineers and technical creators that have death marches, not the people who build / invent / manage requirements.

When we see people arguing about agile they are clearly on the bad side of that spectrum at the moment.

• Agility depends upon a relationship with a customer, because that is the bottleneck. It is not about a methodology, framework or scrum - don’t let all those snake oil salesmen trick you into the cargo-cult.

these jobs require open creative brains - our neuro physiology shuts these parts of our brains down when we are stressed. Maintaining pace and relevance is critically dependant upon not having these people stressed.

That all needs to stop.

Agility is about software development. It is used much wider now as adoption allegedly spread out, but at the end of the day it is a manifesto for software development. Apply it elsewhere and you mileage will vary - but employ it in an org that does software and fail to make it apply to the software developers then I think its obvious that something perverse is happening.

It is about a way, a bias that leads to better outcomes - and so happiness.

What if work could be rewarding?

But, what if instead of all this agile nonsense, we just though about this as ‘its better to communicate and sense our way through problems than putting communication boundaries in place - also getting to know each other might be fun?’

I heard ‘Agile is Dead’ again today, and I wonder

‘How did we turn a bunch of people that essentially said ‘𝘏𝘦𝘺 𝘸𝘩𝘦𝘯 𝘺𝘰𝘶 𝘤𝘢𝘯 𝘸𝘰𝘳𝘬 𝘭𝘪𝘬𝘦 𝘵𝘩𝘪𝘴, 𝘪𝘵𝘴 𝘲𝘶𝘪𝘵𝘦 𝘦𝘯𝘫𝘰𝘺𝘢𝘣𝘭𝘦 𝘢𝘯𝘥 𝘸𝘦 𝘨𝘦𝘵 𝘢 𝘭𝘰𝘵 𝘰𝘧 𝘨𝘰𝘰𝘥 𝘴𝘵𝘶𝘧𝘧 𝘥𝘰𝘯𝘦’ Into some kind of moral imperative - a strong belief in how to act’?

So, I don’t care about agile, I care about communicating a healthy environment to work in. You might not need what I need, but if what I need makes your life better maybe we can collaborate?

𝗗𝗶𝘃𝗶𝘀𝗶𝗼𝗻 𝗼𝗳 𝗿𝗼𝗹𝗲 + 𝗿𝗲𝘀𝗽𝗼𝗻𝘀𝗶𝗯𝗶𝗹𝗶𝘁𝘆 + 𝘁𝗵𝗲𝗿𝗲𝗳𝗼𝗿 𝗯𝗲𝗵𝗮𝘃𝗶𝗼𝘂𝗿

Agile came from a time when engineering was much smaller in terms of defined distinct job roles. Engineers now have 10s of different names (data, vs software vs backend etc). We seem to think that product is not engineering, but engineers were product + research when the agile manifesto was written. Then you have massive specialisation within product, analysis, dev, test, ops etc. The responsibilities of these roles all existed then too! and were all represented by very few people wearing much larger hats.

We have taken overly simplistic views and made agile an all or nothing problem across whole orgs. To do this requires specific org and coms structures and specific kinds of problem - namely those problems that are well suited to fully cross-functional teams and connect directly to the customer. You probably don’t have one of those problems.

If agility existed before - when roles were combined - does this mean that when we split up the roles the property of agility should extend to all of them? Probably not.

𝗣𝗿𝗼𝗯𝗹𝗲𝗺 𝘀𝗮𝘁 𝗼𝗯𝘃𝗶𝗼𝘂𝘀 𝘄𝗶𝘁𝗵𝗶𝗻 𝘁𝗵𝗲 𝗺𝗮𝗻𝗶𝗳𝗲𝘀𝘁𝗼

The most difficult to achieve statement in the agile manifesto is ‘𝘾𝙪𝙨𝙩𝙤𝙢𝙚𝙧 𝙘𝙤𝙡𝙡𝙖𝙗𝙤𝙧𝙖𝙩𝙞𝙤𝙣 𝘰𝘷𝘦𝘳 𝘤𝘰𝘯𝘵𝘳𝘢𝘤𝘵 𝘯𝘦𝘨𝘰𝘵𝘪𝘢𝘵𝘪𝘰𝘯’. The reason for this is that it is the only with statement an external dependency.

IE if you work in a large org, it is very unlikely you personally have access to a customer. Particularly if you are in public sector, banking ie at scale and your customers are businesses. There will be someone who’s job it is to manage that. If they are not in your team then you cannot achieve this lofty ambition, and so it is probably going to lead to misery - if you are the type of person who find agility to be a moral imperative. You will have to work in a standardised process over having a relationship, with comprehensive documentation before software because teams change, negotiate your contract with stake holders because there is no space for variation because you are one team of many following a plan - hoping it doesn’t change (yet again) and erase months of work whilst not shifting the deadline.

If you just want to do tickets then its great. But if you want to find meaning in your mode of being with a customer or finding innovation and improvements to delivery, then you are shit out of luck - you are not in the right place. If you find it unfair that you are doing overtime for weeks in a row because the requirements changed and you had no say in this - i’d agree. This is just normal for lots of engineers - run for the hills whilst you still have the mental capacity to.

𝗔𝗴𝗶𝗹𝗶𝘁𝘆 𝘀𝘁𝗮𝗿𝘁𝘀 𝗳𝗿𝗼𝗺 𝘁𝗵𝗲 𝗰𝘂𝘀𝘁𝗼𝗺𝗲𝗿

So agility has to come from that contact point and spread downwards from there. The problem is that most people cannot be involved in that contact point and moreover then most people will then get told what to do because decision happen externally to them.

I have caused many problems from starting at the team and spreading agility outwards - the business will not be structured to support this and when you hit a meaningful boundary it causes expensive havoc, and that expense is usually paid (ironically) by your own team.

The result of this is that I am of the opinion that if you want to work in an org in an agile way then you need to own that customer relationship - or coach the person who does. Engineers preaching agility are not in a role where they get to choose - sorry. It’s sad because the cost of getting this wrong largely falls on them. The needs of the person managing the customer and the needs of the people responsible for implementing that are very separate and this is where the problem comes from.

It is not a competition

If you go fastest in a multi-team synchronisation then you will often of moved onto new work with new promises by the time synchronisation occurs. Scope will of changed and your work will now be defective to the whole. Now you have a defect and a broken promise on current work. You also put pressure on the requirements and analysis processes and starve your own team causing you to work under risk. It is very sensible to move at the correct pace so as not to cause the bottleneck to do more work because of your selfishness / ignorance of the system.

It is possible to have agility in parts of an org, but it will always run into the hierarchical command and control contract approach because the agreement with customer has happened elsewhere and so, any changes to it have to also happen elsewhere, which means contract negotiation with stakeholders, synchronisation of teams etc. Anything you want to do that doesn’t involve a new decision with a customer though - that’s up for grabs.

Problem is that people arguing for more agility are not satisfied because that negotiation is likely making them miserable. They don’t think the people higher up are meeting their needs because they have different needs. They keep getting told what to do instead of being asked how to do it - or the people who are asked ‘how’ are a mall isolated subset (lets call them product). Remember how the roles got split out? The synthesis of decisions and the implementing of them is now in 2 different tribes. We broke it.

𝗪𝗲 𝗰𝗮𝗻’𝘁 𝗮𝗹𝗹 𝗯𝗲 𝗮𝗴𝗶𝗹𝗲, 𝟮 𝗱𝗶𝗺𝗲𝗻𝘀𝗶𝗼𝗻s 𝗼𝗳 𝗯𝗲𝗶𝗻𝗴 𝘄𝗿𝗼𝗻𝗴

1. Different layers of an org have very different interactions + so processes should be different at these levels

2. Different parts are doing different jobs, with different information, different people and different kinds of complexity and so should work differently

So,

• Is it always possible to be agile? Of course not.
• Is it always best to be agile? Of Course not.

We (not me!) tend to look for simple to understand answers, but trying to fit single answers to large complex problems is just lazy, incorrect and frustrating for people that want to provide good answers that make peoples lives better, maybe not waste as much and maybe get stuff done well.

The answer to the question of how should we work needs to be answered differently with different work, in different places and with different people. But really its a mindset and a set of values that would mean the above is just obvious.

𝗘𝗻𝗴𝗶𝗻𝗲𝗲𝗿𝗶𝗻𝗴 𝘄𝗶𝘁𝗵 𝘀𝗲𝗽𝗲𝗿𝗮𝘁𝗲 𝗽𝗿𝗼𝗱𝘂𝗰𝘁 𝘁𝗲𝗮𝗺𝘀 𝗰𝗮𝗻𝗻𝗼𝘁 𝗯𝗲 𝗮𝗴𝗶𝗹𝗲

When we move design and product out of engineering we are breaking the connection of customer to engineer and so breaking agility for the engineer. This is one reason why we use cross functional teams. All those consultancies deploying their own product owners for their teams … they, by design have broken agility. The customer is supposed to be in those meetings.

Defining the what to do cannot be separated from the how - and the process of doing this is the collaborative part of engineering. When we move that out of the engineering team we have removed a core part of agility - and so a core part of the information that connects work to meaningful value and happiness.

Agility is hard and demands a specific kind of mindset - its a behaviour

It is very hard to be agile, the conditions under which it can be achieved are demanding. It is possible in a lot of orgs, but people are looking in the wrong places and think a methodology is the answer - when it isn’t.

But also, this was just a group of people over a weekend having a brainstorm. Do you really think that that is really a full and complete reduction of all their views on the day after?

It’s all a massive cargo cult.

Agility is only possible when a team connects with a customer

IE it is a small scale thing.

In other situations you can try to apply the values - but its not agile from the agile manifesto. Its a different beast because its a different kind of organisation. It won’t be happy for engineers and the agile part will be somewhere other than the software developers.

In larger organisations accountability matters and in these organisations they have to emphasise the right side over the left.

Making this work at scale and retaining agility requires very mature teams - this is why rubbish like scaled agile framework exists. Its just waterfall by another name to enable a process that might be able to work be sold into organisations who want to be agile but are completely inappropriate for the idea. Its like the lambo SUV.

𝗦𝗰𝗿𝘂𝗺 𝗰𝗮𝗻𝗻𝗼𝘁 𝗯𝗲 𝗮𝗴𝗶𝗹𝗲

Scrum or any other delivery methodology cannot be agile. It is not possible to put anything into a framework that would make it agile. XP is also not agile, not is lean. Nor is any process I can invent.

What is required for agility is a relationship, not a methodology or a framework.

The reason why agility doesn’t exist in many orgs is because the nature of the engagement at a contractual level - which is constrained by legal frameworks - to an extent - is not about collaboration.

When you are saying Agile is Dead - it is because you are not looking in the right place. All those posts about scrum, zp or whatever are essentially shitposts trolling everyone trying to sell something that is not that relationship.