Hacker News Reader

Comment by isoos | Hacker News Reader

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?

View on HN

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.

Reply on news.ycombinator.com