Hacker News Reader

> Many C-level executives want "true business agility" for their company: They want to be able to react quickly when circumstances change.

True, and this isn't a bad goal in and of itself, but what they don't realise is that these 'quick reactions' (aka fundamental low level changes in the product) may require orders of magnitude more work than said executives expect (and in fact, probably the work required is at least linear in the age of the company).

> (they do not have a war chest yet, so those that were not able to react quickly do not exist anymore)

I'd argue that having a 'war chest' is actually detrimental to agility (if you're thinking of agility as 'the ability to perform at our current level in a different field'). Small new companies can pivot extremely fast because even if it means throwing away their whole codebase, they've only lost a few months' work.

To be fair, many "low level" technical decisions also cost orders of magnitude more than was originally intended.

Not coincidentally, there is rarely strong strategic technical direction at the organization level. Rarely is there accountability (especially for middle management) in making sure that cobol is actually deprecated, those Windows XP boxes are actually powered down, and that gnarly business logic is cleaned up and well-tested.

It's worth noting that typically there's collusion from all levels to create one of those problems. That being said, there's not much an individual contributor can do about massive strategic mistakes other than move to another org. A magical org with great engineers and no major technical debt.

> I'd argue that having a 'war chest' is actually detrimental to agility [...]

I believe that's what the parent is saying as well. I read it as saying that larger companies with a 'war chest' are able to weather the problems caused by reacting more slowly, and so agility is not as highly prioritized, while smaller, newer companies have to react quickly or die.

"War chest" kind of implies liquid assets of some kind. Code is a highly illiquid asset and even a liability if you have to maintain its existing functionality.

Most of the small companies that are able to pivot easily do have reasonably large war chests in the form of VC funding. If they don't have that kind of funding they won't be able to pivot as easily because they need to worry about maintaining cash flow just to keep the lights on.

This matches my experience, although I was lucky that I stopped doing "Agile transitions" gigs early enough. My question is: how do you discuss this with a customer?

At one point I had a talk with a director of a smaller bank, and he was enthusiastic to bring me on board, even wanted to pay me just to spend my workday in the office doing nothing specifically. I declined, because it was a lost cause: their team was too fragmented, their processes were too convoluted, their estimate for a very minor change added up to several months...

Yet, I felt bad about it, because I wanted to help them, but in that environment, I was not able to do anything. How do you approach such situations?

Well, this is very hard. It is more frustrating with bigger companies.

In one occasion, where they officially brought me in as an agile coach, I tried to at least achieve some local optimum with the team, because some big improvements were plain impossible. I occasionally talked to managers about all the walls we were constantly hitting, but the answer was always "we can never change that in this company". This did not stop me from mentioning the problems, though.

Most company actually hire me as a technical coach or as a developer. There it is easier: When changing the way the team works is not officially my responsibility, I will still mention things that could be done better. But when the company does not listen to me, it is easier to let go: Then I'll just focus again on helping the team dealing with their legacy code monster (or whatever else I was hired to do).

So, in short, my strategy of dealing with it: Never give up mentioning problems and trying to establish a culture of continuous improvement with small experiments. But don't get too frustrated when they don't listen.

Also, often they do listen, and things get a little bit better ;)

How do you deal with those situations? Do you have a different strategy? What could I try to do differently?

> Never give up mentioning problems

I've tried this strategy, but it just comes off as whining. People's reactions tend to be "we all know that's a problem, but what's the fix? None of us have any power to apply any fixes."

The essential strategy to make a company more agile is to a) spend some time at the bottom, to understand how daily processes aren't agile and are broken up by the organization's silos, b) explain how the organization isn't agile to executives, until finally c) you and the executives talk to middle management together and start to take on the middle-management fiefdoms.

The very good reason why Agile requires C-level support is because it often involves reorganization or firings at the middle-management level. You're never going to get anywhere complaining to people on lower levels, or to middle management, which is typically against changes to organizational structure. If the executives aren't on board ("we can never change that in this company"), leave and find another company.

Thanks for your insightful reply!

b) works only when you are even allowed to talk to the exectuives ;) That's why I said it's more frustrating in larger companies...

I always talk to everybody. But then, I've only ever been an employee, not a consultant, and I picked my employers accordingly.

> I've tried this strategy, but it just comes off as whining.

It helps to deliver some good results first. People take you and your opinions more seriously after.

I used to work at a megacorp that pretended having stand up meeting seated was working agile.

I just nodded, cashed the paycheck and still did great work. some battles I won, like moving a whole team to continuous integration or removing most of the manual busywork in testing, sometimes I just let bad stuff go because you can't always win and instead aimed for the second best option: dodge.

> establish a culture of continuous improvement

This is the thing in agile/technical coaching. Too many people focus on the process and dogma when what's really missing is an organizational habit around continuous improvement.

> their estimate for a very minor change added up to several months...

It sounds like they had an issue with technical debt (and that had led to a lack of trust from the rest of the company) and thought they could fix it with a process, correct? I don't think you can help someone that won't recognise the root cause.

The reason for technical debt is the process. If you have a very waterfall like process like at a lot of large companies, everything has to go through change control.

Every change has to have business case, and becomes very bureaucratic. As a result no one proposes any changes to fix technical debt.

You can do it under the radar by attaching it to existing tasks, but these companies tend to be so project manager driven that any slippage in your delivery dates means you will get pressure applied to you. So you just do the bare minimum.

Result: Technical debt never gets fixed. Refactoring and trying to write good code is career limiting. Company wonders why they are so shit software, blames developers.

The elephant in the room is that companies follow the fixed scope, fixed budget model which basically fails every time.

Add to that putting projects into 'maintenance' mode once they are 'delivered'. Ie no manpower to do any improvements, and even barely an bugfixes---even though lots of new downstream projects depend on it.

I really don't think the process is responsible for technical debt. If anything waterfall is better because you can do larger scale refactorings. But at the end of the day, time needs to be assigned to address that debt and no process will give you that time.

Well agile techniques recommend you don't fix scope, and budget at the same time. Allowing you to go back fix your code that has turned out to be wrong. You're allowed to learn and to adjust your plan as you go a long.

Waterfall people have to meet a deadline and a defined scope, so when being told that you have to refactor some code, the response is to ignore it to meet the deadline. In order to meet deadlines and a defined scope the plan MUST NOT change, otherwise the deadline or scope has to be changed as well.

That is until you reach the deadline and find it doesn't work the way the customer wanted anyway because you refused to change the plan.

For agile techniques the measure of progress is working software, not meeting set deadline and scope.

Don't be so sure. Layers of middle management, all with their own (often selfish) priorities between you and other teams working on systems you need to collaborate with will destroy any possibility of agility.

Agile coach here. You nailed it.

One way of looking at these companies is that they're organisms adapted to their environment. If there are weak selection pressures around agility and software delivery in their market "environment" then you can expect that they're well adapted to other pressures (i.e. credit risk, or buying labor at one price and selling it at another).

Often times these businesses might see reasons for agility, opportunities they could take advantage of, still they really aren't feeling selection pressures so there's no real need to change. How they deliver software with really bad agile is "good enough". Well it will be until it isn't and then it might be too late.

So you have all the structures and processes that make one organism good at being a bottom feeder and it's like pushing water up a hill to make them change when they REALLY DONT HAVE TOO.

Every once in a while I have a client where this stuff actually matters to them and we have a lot of fun and make amazing stuff.

Awesome explanation! I have to think about this organism / selection idea a bit more.

It's amazing how much I have learned and how many different perspectives people have told me since I first gave that talk...

Actually (and I do this for a living as a management consultant) we are pushing all of our clients to an Agile operating model. There are many reasons for this, but the primary one being that consumers now expect to interact with all companies like CPGs.

Agile lends itself very well to a top-down brands-and-products hierarchy. You build the core of the products in a shared engineering group (again, just like most CPGs) then apply localized branding and product focus as needed.

And here's the thing: adopting Agile in the corporate world is less about "reacting quickly" (though that is one of the benefits, at least in comparison to the legacy methods) but really more about cost control. Agile is simply cheaper because you're not building shit that nobody wants. If you can build an Agile culture of "if it's not in the backlog that was approved by product and reviewed every couple weeks, you don't build it" you cut down on a lot of pet projects, deprecated features and duplication of effort.

Is there still duplication? Sure; but often times companies will have 5 groups build the same thing and they just choose the one that gets the most internal traction. That's actually a viable strategy when you don't know the product you need to build, but you need it to work. It also tends to help find the right "home" within the organization politically (i.e. the people who really need said functionality will build it, use it, make it popular, and then get the money to maintain it while fringe users lose funding and migrate to the shared platform).

The key thing is that the engineers aren't in control. And with good reason; engineers are paid to build products, product managers are paid to design products and brand managers are paid to build portfolios of interrelated products. You cannot run a large company without this kind of P&L discipline.