Agile Is Dead, McKinsey Just Killed It

https://terem.tech/agile-is-dead/

by noptd • 5 years ago

60 103 5 years ago

terem.tech

jon-wood• 5 years ago

The website is dead, Hacker News just killed it.

archive.org mirror: https://web.archive.org/web/20210721043921/https://terem.tec...

dstick• 5 years ago

Thanks! It's a familiar read. These days I prefer the pragmatic approach.

- Test features, not units (the time spent vs time saved is meh). So when something breaks, you can take it from there. Start digging.

- Build features

- Fix bugs by first writing a test, and then getting green

- Never go over-fancy with inheritance and whatnot. Readable longer functions are preferred over smaller once that break up the logic. Keep the poor soul in mind that has to go through your code in 3 years time. That could be you yourself ;-)

- Comment the "why"

That's it really. For web applications. Seems to work perfectly well for a code base that's over 10 years old and has seen many a developer come and go. Yes there's a bunch of legacy, but not a single part of it that's hard to reverse engineer with some effort.

xorcist• 5 years ago

Closely related to tests are monitoring the production environment. Every time there was an incident and it wasn't visible at the source (whether it was found due to customers complaining or conversion rates dropping), no matter how unlikely it seems for it to happen again (we made a unit test so we should be safe now, right?), always monitor for it.

This might be my ops side speaking, but often undesired behavior aren't outright bugs (a value not being set is expected, but that empty value led to an empty template which led to the frontend framework not reading an event might not be), the same class of issues can be monitored for. This is a combination of logging and monitoring, of both events (where the application checks for unexpected results) and of state (where something external to the application reacts to for example things like active users without login sessions).

goalieca• 5 years ago

Test features, not units (the time spent vs time saved is meh).

Might I add that testing for security should be a priority. Some agile shops move so fast because they aren’t worried about small bugs. All security issues are bugs and often they are ones that aren’t along normal feature usage.

iso1210• 5 years ago

Keep the poor soul in mind that has to go through your code in 3 years time. That could be you yourself ;-)

Isn't that why people move company every few years :D

Complaining about crap legacy code is easier when it hasn't got your name at the top

scott_middleton7• 5 years ago

Well said, I'm a big fan of the pragmatic approach as well. But, for some reason we (people generally, including myself often) need to overcomplicate.

noptd2• 5 years ago

Never go over-fancy with inheritance and whatnot.

So much this.

Personally, I've grown to prefer object composition for bucketing and sharing reusable functionality across classes over the years. Testing with mocks becomes far easier, and it really seems to simplify the mental model.

Nowadays, I only use inheritance when working with generics and generalizable interfaces.

tremon• 5 years ago

Two decades later and the movement has succeeded. Agile’s underlying principles and values are now table stakes for any organisation. The degree to which an organisation is applying agile is now a matter of small increments of productivity rather than a revolutionary game-changer.

So it's not dead, it has become standard operating procedure.

hkt• 5 years ago

It does seem a bit self contradictory when a few paragraphs back the author has said how the term has been scrubbed of all meaning and things like self organising teams have been abandoned in favour of selling new wrapping on old ideas.

tempodox2• 5 years ago

Title is click bait, if McKinsey killed it then so did every other org that misuses “agile”.

And here's the revelation in the article:

Agile’s underlying principles and values are now table stakes for any organisation.

I leave it to everyone else to make up their own opinion about that.

rualca• 5 years ago

Title is click bait, if McKinsey killed it then so did every other org that misuses “agile”. (...) I leave it to everyone else to make up their own opinion about that.

Yeah the article is pretty bad. Indeed it all boils down to your run-of-the-mill regurgitated and recycled complain that organizations abuse trendy keywords without any intention to actually follow through.

All in all, a waste of a perfectly good click.

tempodox2• 5 years ago

All clicks are final. There is no reimbursement.

mattbrewsbytes2• 5 years ago

And here I was thinking to throw away everything I've been doing and just go back to waterfall.

Title could have been "Consulting company promotes themselves"

pjmlp2• 5 years ago

I have long returned back to waterfall, it just happens to take two weeks at a time.

Pure agile never worked on non-software industries, due to the way all parties expect to deal with requirements, demos, documentation, long term roadmaps, budget allocation for next year projects,...

throwaway_Aef84• 5 years ago

"Small Consulting company promotes themselves by attacking Large Consulting company by playing off allegiances to tech religions"

https://devbizops.medium.com/are-you-tech-religious-fb281b39...

PaulKeeble2• 5 years ago

Shocker that organisations that could never work out what agile was and no intention of adopting the principles of it are still redefining what it means. Nothing changed they have been doing that for 2 decades ever since it took off, most large organisations never want to empower their staff so they fail at step 0, they don't want what agile is selling. They are finding it awfully hard to find staff however if they don't list it!

mongol• 5 years ago

How are people working within Red Hat? Are kernel patches and systemd features developed using agile concepts such as user stories, story points, retrospectives and sprint planning? Or is it more a group of hackers scratching itches?

stncls• 5 years ago

I'm really curious about this. I can imagine very "managed" methodologies being attractive for gigantic teams working on an enterprise client project where the complexity stems from the endless stream of feature requests.

I have trouble imagining how it helps a team working on, say, a kernel, a compiler, network infra, a browser, scientific code, or a HPC project (because it seems to me that complexity there comes more often from raw algorithmic difficulty). But maybe it does help.

Stories from anyone with such first-hand experience would be great!

rightbyte• 5 years ago

I had my hopes up that McKinsey had started to preach against agile. But this seems just like the agile micromanaging dystopia is about to defile other fields than programming.

elp• 5 years ago

"Agile ... emphasizes customer collaboration over contract negotiation, individuals over processes, responsiveness to change over following a plan and results over documents."

I think someone needs to tell this to my company's agile consultant. That actually sounds useful.

agumonkey• 5 years ago

seconded; thats a summary of everything I strive for

leoc• 5 years ago

It's from the original Snowbird manifesto: https://agilemanifesto.org/ https://www.theatlantic.com/technology/archive/2017/12/agile...

creshal• 5 years ago

The Agile Manifesto and what consultants peddle as "agile" have a surprisingly small overlap.

nickjj• 5 years ago

Did your agile consultant go over outcome over output?

It basically drives home that doing work for the sake of work isn't useful. It's only useful if it's something that produces a desired outcome where that outcome is usually a service or features that customers actually want, but it also bleeds into doing technical things that indirectly let you meet customer requirements faster like having good test coverage, a good release process, etc..

bigbizisverywyz• 5 years ago

The Agile Manifesto itself is actually a fantastic set of tenets. Unfortunately most people I've talked to who are trying to push 'agile' have neither read it, or have enough experience in software development or projects to understand why it's so insightful.

They do love to straw man waterfall though.

scott_middleton7• 5 years ago

This gave me a good chuckle :)

booleandilemma• 5 years ago

Does this mean I don’t have to go to standup today?

linker3000• 5 years ago

From a close outsider's perspective:

I am by no means a fan of agile as a 'religion' and in my role on the edge of the Dev world (Technical Delivery), I have seen many teams try to take the book of agile and implement it end-end, which focuses them more on the mechanisms than the 'doing'.

Agile has some good common sense strategies for (to use other phrases) common ways of working, problem triage, workload assessment, resourcing, progress tracking and measuring success but it's often deployed 'big bang' when (like ITIL), an *overseen* progressive change management exercise would be less of a shock to all concerned.

I stress 'overseen', because when you just dump the processes and tools on a team you often get situations where, for example, the sprint backlog just becomes a dumping ground for everything in progress and everything yet to be scheduled - with the icing on the cake (in one recent encounter) being that the backlog is exported into a spreadsheet for prioritisation and then collaborative updates to this are used to edit comments in the user stories!

I don't mind if agile is 'killed' because a lot of the common sense it conveys is either already being used (in perhaps a less-than-ideal joined up way) or can be used under a different brand name. Mind you, some organisations that have made their bread and butter from the concept might have something to say about this!

The overall aim should be for any team to work in a known and consistent way to meet their deliverables. Call it agile, call it foo; whatever!

stefanve6• 5 years ago

SAFe killed agile first :)

From my experience it depends on the company culture, leadership and the way agile is implemented and started with in a company.

Big companies with very old and complex architectures coupled with old school separation of business and IT and a bag of bureaucracy. Will properly need a PMO, or SAFe like implementation. Sometimes they are in luck and they are able to start with departments or a business units and move faster. But even if you have that the wider organisation will lag heavily. Most if not all can't become agile in an instance with implementing the perfect agile way of working. Even transforming to an agile organisation is best done in an agile way.

donquichotte• 5 years ago

Ah yes, Agile-Fall!

Of course, the agility here happens by accident, because in the first week of the program increment you realize that something is much harder than anticipated, and hundreds of person-hours of planning are thrown overboard.

stefanve6• 5 years ago

I don't like SAFe for many reasons but I have seen it used successfully as an agile steppingstone. Some of the more original ideas with in SAFe (there aren't many) can even be useful. Anyway I don't think the idea of an ATO is a bad idea or anti agile. Even within an agile environment projects can exists and can be done in an agile way.

Due to badly run prince2/PMI projects people are allergic to anything remotely sounding like a project. So I get the autor when he thinks of ATO == PMO == PMI == waterfall == nightmare. But for larger organisation you will properly need something like a ATO to be successful. Like anything else a badly run, top down driven ATO will fail and make life difficult for anyone involved (this is also made clear in the original McKinsey article).

skohan• 5 years ago

I worked on a project heavily involved with McKinsey a few years ago. Maybe it was just that particular team, but, it was an ... interesting way of working.

samvher• 5 years ago

Care to share more?

FpUser• 5 years ago

"Agile is Dead..."

To me it's been never alive in a first place. I develop products, some I own, some are built for customers. From my lengthy experience the process is unique enough for every case. I could care less what every particular case called.

"Now almost every job applicant goes to great lengths to explain how agile they are"

I do not remember ever talking about agile with my customers.

apples_oranges• 5 years ago

Dear "Hackers", it doesn't matter what McKinsey does.

Consulting's business is inventing processes and then selling them. If they pitch something that is not agile, it only means they believe they can make more money with something else.

gitfan86• 5 years ago

Just look at what they sell as "blockchain" or "crypto". They literally will sell you an editable blockchain or a centralized blockchain. They don't care about technology. https://www.accenture.com/us-en/insight-editing-uneditable-b...

Agile is the same thing. They have no problem creating a waterfall process for you and slapping a "Agile Certified" sticker on it.

tharne• 5 years ago

Dear "Hackers", it doesn't matter what McKinsey does.

It absolutely matters what McKinsey does. Practically every business in America has a significant number of shallow-thinking MBA types who have next to zero understanding of the business they work in, and few practical skills. These folks survive and thrive by aggressively promoting whatever idiotic thing McKinsey and the fine folks at Harvard Business Review roll out next.

DeanW• 5 years ago

If there are buyers of anything, even useless and harmful, someone will sell it to them. McKinsey, and others, are reading the market appetite of buyers and figuring out how to choose and package information in a way that is pleasing and meets the immediate usefulness measure of individuals in their markets. It's basically the same as the narcotics trade. And as both are hugely profitable, no amount of reasonable criticism will gain any traction with the participants.

geodel• 5 years ago

Agree. It just means same snake oil is available in new improved packaging. No longer one has to keep using grubby old bottle.

Chris_Newton12• 5 years ago

In my experience, the term “Agile” itself has been so widely applied that it lost any useful meaning it might have had a long time ago. The ideas it prompted are the interesting part.

I’ve never fully agreed with the original Agile Manifesto anyway, mostly because I think it tries to separate concepts that aren’t independent in practice. For example, if you don’t have a comprehensive requirements spec, how can you possibly know whether you have working software?

I do think the early Agile advocacy served a useful purpose in highlighting how slow and heavy a lot of software development processes were at the time. I think a lot of good ideas have been popularised as a result of that awareness and the various alternative processes that have been tried as a result. I also think some not so good ideas have been popularised, and some ideas that work well in the right context but not universally.

IMHO, it is much more interesting to discuss those specific ideas. How can we build software more incrementally, so we can see real progress and identify any potential problems earlier when they might be easier to fix? Is there a risk of becoming too short-sighted, so we create an illusion of progress, yet overall it takes longer to build a product we can ship? How can we organise our code and our teams to be more adaptable as requirements evolve over time? How does our situation change depending on whether we’re building a line-of-business web application, a game for a next generation console, or the management system for an aircraft carrier? There are lots of interesting ideas and useful discussions to be had, but they can be had just as well without applying the loaded term “Agile” anywhere.

marcus_holmes3• 5 years ago

For example, if you don’t have a comprehensive requirements spec, how can you possibly know whether you have working software?

Short answer: iterative prototypes.

Long answer: I have yet to see a single project in all my decades of experience in this industry where the requirements didn't change during the project. A "comprehensive requirements spec" is and always was a myth. Agile wasn't even the first to say this bit out loud. Software is always developed by a series of iterative prototypes, only sometimes does the process acknowledge this.

Chris_Newton12• 5 years ago

Short answer: iterative prototypes.

OK, but then how do you know what each prototype is required to do?

It’s true that you might be lucky enough to work on a project where your employer/client/customer is willing to let you make some of the decisions. In that case, you are effectively defining some of the requirements yourself and hoping that your employer/client/customer will be happy with your decisions. That’s a risk you can mutually agree to take, and sometimes it will pay off royally, and sometimes it will end in disaster, and probably most of the time it will end somewhere in between.

However, in my experience, the more important the software you’re building is, the less likely it is that you will have that kind of flexibility for the developers. At the extreme end of the industry, if you’re building something like the control system for medical equipment that will kill the patient if it goes wrong or a billion dollar satellite that you get one shot at launching, you probably aren’t going to be doing it through informal discussions with a “product owner” and relying on TDD to make sure everything is working (where “working” in that case is really a euphemism for “whatever test conditions an individual developer felt might matter”).

I have yet to see a single project in all my decades of experience in this industry where the requirements didn't change during the project.

Of course, but every time the requirements change, you still need to identify what the change is so you can change your implementation accordingly. There are many ways you can address that problem, some of which involve one big requirements spec document and some of which don’t, but if you don’t end up with some clear and well-maintained spec each time, you don’t know what you’re trying to build and you have no meaningful definition of “working software”.

gilbetron2• 5 years ago

The waterfall method (which is what is being invoked when "comprehensive requirements spec" is stated) was, and is, always a fictional story told by people both during and after the project. The entire difficulty of a software project lies in figuring out what needs to be done. Well that and fighting with the tools and modules ;)

DrJokepu• 5 years ago

Also, you know, specs can and have bugs. You can have the most comprehensive requirements and specification and a 100% correct implementation of the spec and still end up with software that just doesn’t work, because the spec and the requirements had incorrect assumptions, or worse, had internal contradictions baked into them. Happens all the time. Best to just accept it as inevitable and design the process so that it can cope with it.

stefanve6• 5 years ago

"Working software over comprehensive documentation"

"That is, while there is value in the items on the right, we value the items on the left more"

I have had many discussions with both agilest and let's say traditionalist about these statements. funnily enough people from both "sides" sometimes mis interpet (or at least that is my view) the statement as; agile means no documentation. To me it is about just enough documentation. You should know what needs to be build, what you expect from it etc.

But in the end it is better to have working software than to have piles of documentation. So there is value is having documentation but the end goal is working software.

If you are old enough you remember months and sometimes years spend at documentation, scribbling over details, etc. At the end of the documentation phase they started building, than a building phase that could take months or years. After the building phase they found out the things that seemed handy at the time where not working in real life or where obsoleet. So a analyst should create a RFC which again would take lots of time before it would finally be made

The idea of having working software over comprehensive documentation is that it is better to start building the most important feature(s) and release it as soon as possible. This makes sure you add value as soon as possible. Documentation by it self doesn't add value, but working software does. This doesn't mean that the important feature should not be documented, but it should be documented enough to add value as quickly as possible. That way you get feedback from the users and change what is needed instead of talking for days about what something should do and what problems might arise from some theoretically edge case. Also it makes prioritisation much easier. Maybe an edge case can be tackled by a change of process in state of a difficult software solution. thus having time to work on a feature that adds more value

Chris_Newton12• 5 years ago

I would be the first to agree that a lot of documentation of little or no value has traditionally been created during software development. I saw an interesting report once about some research on where software developers actually look for information while doing their work. Sure enough, it turns out that some types of documentation are very useful and some are mostly useless, and which is which is very much as you probably expect if you’ve been developing for a while.

Still, when it comes to things like defining the requirements and acceptance criteria for software, “just enough documentation” and “comprehensive documentation” are often the same. Otherwise, you literally don’t know what you’re trying to build. That is not to say that you have to have one big requirements spec that never changes (or one big set of requirements specs including numerous cross-references, if it’s that kind of project) or that every change must go through an extensive change management process involving 27 people and a month-long delay to fix a spelling mistake in the original spec. But you need something that clearly defines what the software is supposed to be.

As I noted in another comment, if you are making software without that, you don’t really have a useful definition of “working software” to prefer. Obviously you can still go ahead and make something. It’s just that both sides are then taking on the risk that the development team’s assumed requirements when they fill in the gaps will be satisfactory to whoever is paying the bill. That could end anywhere from spectacularly successful to a dismal failure, which doesn’t seem like an ideal basis for a software development process to me. Perhaps a more common scenario, particularly for software developed in-house or outsourced on a T&M charging basis, is that when differences arise you go back and correct them afterwards, so you still get what the end customer needs but it takes longer and costs more than was really necessary to get there. This is a more insidious danger, because if things do work out in the end, you might not have any quantifiable way to assess what you lost or maybe any awareness that you lost out at all. But you still lost out all the same.

Sometimes. It depends entirely on your situation. Shipping a line-of-business application with 75% of the desired functionality that you can then incrementally develop further in production might offer a lot more than 75% of the value. Shipping 50% of the software that controls the mechanics of a modern car might offer 0% of the value, and if shipping that 50% early means the 100% point when the car is actually useable is delayed then doing so actually has negative value, and the only early feedback you’re going to get is that no-one has bought the car yet.

PaulKeeble2• 5 years ago

"Individuals and interactions over processes and tools"

The issue I have always had here is that in order to go fast and have short cycle times you need quite a bit of automation and the more you rely on automation and make it work the easier it is to maintain iterative agile development. That requires processes and tools maintained and the more you rely on individual personal preferences and nuances the longer those cycle times will be.

Once you get down to continuous delivery you don't have much choice but to have automated tests written for everything, the basis of which might have been a fantastic interaction with a stackholder with a good back and forth on the right tests, but its far too reductive to just always value people over process when solid engineering is critical to low cycle time for software agility.

It seems the manifesto was written from a contract interaction perspective for consultants. With the product mindset however these types of scenarios are a lot less common but the engineering doesn't go away. Its just one aspect that has annoyed me where Xtreme programming got more into defining what a good project actually ought to be able to do and the sort of processes that were necessary to make it work even if some of it was flawed it hung together better than a set of values.

scott_middleton7• 5 years ago

IMHO, it is much more interesting to discuss those specific ideas.

Yes, agree here.

I do think the early Agile advocacy served a useful purpose..

Agree.

bm3719• 5 years ago

It'd be nice if there were some way to filter out job listings where some heavyweight development methodology was in effect. Some make it obvious in the description text, dropping SCRUM/Agile-related buzzwords. Others sounded awesome, promising an enlightened developer-centric focus and autonomy. Then I've shown up to find I'll be a mechanistic story point generator, wasting everyone's time.

This is an area I've had to exercise acceptance on. Even if SCRUM dies, the selling points for it (control, measurement, and interchangeability) are too powerful such that something else won't come in and replace it. However, I would like to know a team thinks that way, so we can steer clear of each other.

kthejoker2• 5 years ago

My problem with all methodologies are the lack of coherent stakeholders on the business side. Product owners are a poor proxy at best but at least they're a definitive throat to choke when things go awry.

Being told for the 20th engagement in a row that the right people for a conversation about a feature can't spare the time to be in the the room to workshop it or provide meaningful feedback (so why are you paying $300/hr for my time?) is de-motivating.

As a rule I find most human beings exceptionally poor at thinking structurally and critically about why they do anything at all, and strategies or behaviors which would improve those things either by outcome or experience.

They just go on raging their fists in the dark and at the same time running away from any daylight that might make them change.

scott_middleton7• 5 years ago

The last line gave me a chuckle.

noptd2• 5 years ago

After a certain point in their careers, it really does feel like a large percentage of people stop asking "why?" when faced with new requirements, standards, etc.

Maybe it's just a natural part of getting older, as habits and perspectives become more ingrained over the course of time.

reaperducer• 5 years ago

I'm not sure it's about getting older, but it does seem somehow related to age.

In my experience, the people who won't ask "why" aren't simply "older." They're the in-between. Young people ask "why." But also older people, maybe 50+.

My experience has been that it's the project managers and their overlords in the 25-49 range that seem to think they know everything and everyone else is unclued.

The young ask "why" because they're curious and want to learn. The old as "why" because they want to understand what's behind decisions. And managers hate explaining themselves.

dragonwriter3• 5 years ago

My problem with all methodologies are the lack of coherent stakeholders on the business side.

For internal or contracted apps, there is usually a well-defined customer. There may be other stakeholders, too, but that first one is the key.

If the problem is getting them (or their representative, and not a dev side proxy, engaged, well, that's the problem you need to fix.)

“Agile” methodologies that try to sidestep this, e.g., by designating a IT org proxy are broken in the same way as “Marxist” methodologies that try to sidestep the requirement for mature capitalist development and proletarian class consciousness, e.g., via an privileged revolutionary vanguard.

Product owners are a poor proxy at best but at least they're a definitive throat to choke when things go awry.

That's pretty much exactly what is not needed.

Being told for the 20th engagement in a row that the right people for a conversation about a feature can't spare the time to be in the the room to workshop it or provide meaningful feedback (so why are you paying $300/hr for my time?) is de-motivating.

Sure, and if that is happening often then prioritization isn't fitting business priorities, even if it is fitting what business says are their priorities.

throwaway2016a5• 5 years ago

I haven't practiced structured agile (in my case Scrum) in years. Mostly because every single sprint becomes so derailed by "urgent" outside requirements that any sort of cohesion and planning goes out the window.

Good luck telling the client that their P0 ticket will need to wait until next sprint. Or more accurately: tell the product owner or account manager to tell the client. Which in my experience often results in them caving to the client demands.

Then you have clients who won't pay for the planning and retrospective time.

I think my record is 4 consecutive Sprints before things went completely off process. I just gave up.

dspillett• 5 years ago

Good luck telling the client that their P0 ticket will need to wait until next sprint

A key cause of that being a problem is stacking the entire team with a full sprint of vital work. Leave some time for issues. If no issues come up, pick up some nice-to-have tickets in the now spare time at the end of the sprint, or get started on work for next sprint.

If you absolutely must give everyone a full sprint of work every time, make sure some of it is from the nice-to-have pile so it can be put off when the surprise P0s come in (and in the absence of surprises, you get to clear off some of what are now nice-to-have bits of work but later might otherwise get surrounded by code/infrastructure that assumes they'll never happen so morph into nasty technical debt and/or their very own surprise P0). But if you try this, good luck explaining upwards why nice-to-have tickets are on the board while there are more important ones in the pile…

throwaway2016a5• 5 years ago

Even if you do have room in the Sprint, the formal Scrum methodology says adding a ticket requires tossing the Sprint. I suppose if you are removing an equal number of story points you can get away with it if you look the other way.

But then you have another issue, the sprint gets oversubscribed or behind and instead of stuff moving to next Sprint the team works overtime. Now all the sudden the velocity calculations look like you have one velocity but really it's because you added extra capacity that sprint.

Won't take long until "extra capacity" because "the normal way."

snarf21• 5 years ago

This is always the issue, no institutional buy-in.

One thing I learned a long time ago is that a "bad" process that is followed universally by everyone (dev, pjm, pm) will always out perform a "great" process with only token buy-in and constant exceptions.

endofreach• 5 years ago

This is the most important productivity hack, a lot of people just don‘t understand.

spiralx• 5 years ago

Consistency allows even the worst process to become familiar enough to be improved on and reduces the overload of having to context switch unexpectedly, and it's amazing how much time can be wasted by people not knowing what process to use and having to either waste someone else's time to find out or do whatever their best guess is, probably wasting time much later on.

If you've ever seen someone operating a terrible piece of old data entry software they've been using for decades it's amazing how fast someone can be even at jumping through pointless hoops to get the job done - often a problem when introducing a newer process that might seem more efficient from the outside!

scott_middleton7• 5 years ago

It's easier to take the path of least resistance and usually you won't get shot for it. Trying to fix things often makes you look like a trouble maker, especially if something doesn't work as well as it could (which often happens when iterating through change).

dragonwriter3• 5 years ago

structured agile

If it is following a structure specified outside the working organization, it is not Agile, but instead the exact thing that Agile was explicitly a reaction against.

Mostly because every single sprint becomes so derailed by "urgent" outside requirements that any sort of cohesion and planning goes out the window.

An approach that puts following a plan over responding to change is...not Agile.

Then you have clients who won't pay for the planning and retrospective time.

Why does your contract not define what is a billable hour and charge an appropriate rate for the time?

I think my record is 4 consecutive Sprints before things went completely off process.

If you aren't adapting your process continuously (or, rather evaluating it continuously and adapting as needed), you are giving process a priority over the concrete team (in the broad sense, including the customer) and set of challenges faced that is exactly what the first value statement in the Agile Manifesto is about not doing.

brightball• 5 years ago

They certainly didn’t kill it, they just added to the long list of people who say they are agile but continue to operate in a command and control world because top leadership can’t accept reality.

Even with something that gets it so close to correct like Scaled Agile, they’ll tell you it only works if senior leadership is on board. Otherwise everyone will be paddling upstream. I’ve seen it work beautifully and I’ve seen it completely screwed up.

At one company within a few hours from me, about 2/3 of the company were actively campaigning for it after knowledge spread through the group. CEO couldn’t be bothered to show up for an overview presentation.

Eventually, the board removed the CEO and everybody is doing much better.

darepublic• 5 years ago

Agile needs a small team, high trust and cooperation, and shared common motivation. You won't find that in the sprawling politics ridden corporation, plastered with slogans promoting team work, communication, keeping it real, but sorely lacking these virtues in reality

motohagiography• 5 years ago

The agile envirionments I've worked in have been preferable, and I'm for whatever gets things done. The manifesto and resulting method showed a clear understanding of the problem they were solving, what I don't think they understood is why waterfall "worked" and what "worked" meant.

Not sure if they have a word for it now, but I call it The Fold, above which, the organization is not agile, and still operates on a dynamic narrative of representations, impressions, commitments and dates without anything concrete, and to people above it, that is a feature.

The concreteness of agile becomes a set of forcing functions on people whose job is to sustain options ("optionality") and not be subject to be forcing functions, but rather, to issue them.

I'm all for the agile anti-governance to make things, but what an enterprise business really is is a governance layer extacting value from capital in an as-abstracted and generic way as possible, where products, people, infrastructure, are interchangeable black boxes in balancing that capital management equation. Making "things" doesn't matter in an enterprise, as the whole business is just a narrative over abstractions of those things.

The flow of the factors and the yield on that capital is directed by the attention and narrative at the executive level between organizations - not by making stuff. What agile practitioners miss is that sometimes, a general sends a platoon on a (career) suicide mission because that's just what's necessary to sustain this yielding narrative that steers the organization. Agile was designed to preclude those missions, which are a key tool in an executive playbook.

That's just in enterprise. I have stumped a couple of agile coach friends with the startup puzzle, "for the company to survive, we need to get another round of investment. To get that, we need prestige customer X in our pipeline because the investors say they are in if this customer is. Customer X wants this feature because their contract with our competitor is coming up, and we have this short window to close this and replace them. It means we need an un-agile date commitment with some tech debt to demonstrate we can execute, or we run out of money. Agile me this."

Most of the answers are counterfactual, where it's "well, you shouldn't have got into that situation." I even agree, where personally, I wouldn't have got into that disadvantaged relationship with just one customer in the first place because I know how that works, but I have watched a few execs die on that hill, and this is a common pattern that happens when sales gets ahead of PMF - you're going to get snookered in front of a date. I'd argue that any method that depends on its own purity is really just a model or an ideology, and not a solution.

What McKinsey will need to do is create the connecting glue between agile production and the narrative business atmosphere, so I'd say agile is not dead, it's being integrated.

taylodl• 5 years ago

Agile is an idea, over the past ten to fifteen years it has been turned into a process complete with certifications. That difference captures the essence of the difference between working in a corporate environment and working in a startup environment - and I've worked in both environments. The "suits" like processes, methodologies, and certifications. Startups, especially self-funded startups, have to get results otherwise they can't make money. As negative as Corporate Agile may sound, it's a far cry better than what they were doing before.

Bottom line? "McKinsey Agile" isn't intended for startups and small organizations or large organizations whose product is tech.

scott_middleton7• 5 years ago

As negative as Corporate Agile may sound, it's a far cry better than what they were doing before. Bottom line? "McKinsey Agile" isn't intended for startups and small organizations or large organizations whose product is tech.

Well said.

mdip• 5 years ago

In the history of my career, I've watched the evolution of agile as either a direct or indirect participant. My first experience with it was at a large telecom where I worked on a team that operated using agile development practices, but didn't realize it while simultaneously watching two separate development teams implement it[0], including purchasing/adjusting things to include any agile hyphenated idea[1].

Mine was a team of six, responsible for about 11 critical, internal, applications. We didn't consciously decide on an agile approach, nor did we ever use that term[2]. It was simply the only way we could operate and manage to get anything done. As we were serving internal teams with fully in-house developed applications we didn't have contract negotiations or someone on the other side of it concerned with anything other than "when can we have it"[3]

We were a geographically distributed team and did stand-ups virtually via chat-rooms, but outside of that, the "Agile Values" were all practiced, accidentally, nearly perfectly.

Shortly after that job, I joined software development shop that was undergoing a large transformation. They'd been a two-developer operation that was started in order to help land customers for the larger consulting business -- now when the product we were helping organizations deploy had some limitation, we had a team of folks who could write something to fill the gap. And because of the product, every customer had a gap. We quickly grew to seven and brought someone in to help manage the chaos with "agile". It worked about as well as I expect it can; this time we more closely followed a scrum process, daily stand-ups, sprints, retrospectives, etc.

I moved on to another shop a couple of years later. They were a larger organization doing bleeding-edge development -- my role involved writing software for large products that a third-party wanted to create but didn't have the in-house talent to do so. At this job, however, agile worked a lot like I had been hearing from other developers -- it didn't.

Here's the thing -- if you look at the three jobs, the one I would have expected to be the most successful here would have been at the last shop. They're mature, reasonably sized, not over-or-under managed and the kind of work we do has a high degree of "unknowns" to it, making a "complete project plan" impossible until very near the late stages. I would have expected the first to be a complete failure given the size of the organization (15,000 employees, three official "company languages", very globally distributed, very difficult to hire high-quality candidates[4]).

All that to say, my current crop of co-workers and management are excellent -- the best I've worked with -- but it doesn't work at all here!. There are probably a million little "we don't do this exactly right or that exactly right", but the biggest -- and in hindsight, most obvious -- difference isn't us, it's the customers.

At the first company, the only concern was "I need this as soon as possible, I can't pay for more people, and have very little for licenses or hardware." In recognition that they were often giving us so little to work with, and a history of delivering, they left us alone[5]. If we took too long, an explanation was enough -- it didn't cost the company more than the salaries they were paying us already.

At the second company, we were developing software related to a third party (OCS/Lync/Skype for Business) which had all of about four organizations, globally, that specialized in that. We charged more than double what my hourly rate is billed at where I'm at, now, and our customers waited months for project starts. That we didn't give them a firm "here's what it's going to cost, out the door" and required them to work with us, the way we work, wasn't negotiable. We turned down work if they couldn't accept the terms.

At the third company, though we are doing innovative work, there is enough competition that our customers generally focus heavily on the price tag. Since our market tends to be non-tech companies, the idea of not having some form of firm estimate in place is a non-starter. Estimates require plans, plans require more knowns than unknowns. The problem is that when you have a commitment that you're going to complete something for a certain price, that becomes the driving factor behind everything else. Change is allowed ... provided a change agreement is negotiated ... so adjusting to changing requirements means "we don't do it", "we eat the cost" or "we send them a new estimate, which is usually much larger than the customer is expecting". For the software we're building, there's always someone else out there that will do that for them. We don't have the money to eat the cost, and change orders can often be relationship-souring experiences.

I've thought about this problem a lot as I'm making a transition to another company (one that is already operating in an accidentally-agile manner). There's room to implement some of the things I liked about agile, here, and I'm inclined to believe that the nature of the work/customers will lend itself well to this approach. It's making me believe that a lot of the talk about agile being "broken" or "poorly implemented" has a lot more to do with the details. Maybe software development ala "the third company" simply can't be done any better. If you can't find a customer who will accept -- up front -- ambiguity in "final cost", you can't really implement agile in that context.

[0] Well, Agile/Scrum if memory serves.

[1] Agile Workspaces, which went over like a lead balloon when the developers with large offices were told they were moving out to tiny, identical, unassigned desks.

[2] As I'm writing this, I recall the term "RAD", "Rapid Application Development". I know it was a thing but nobody on the team could tell you what it was. It was used entirely because management liked how it sounded.

[3] This is similar, but not exactly the same as, "How long is it going to take?" which is often hiding a financial question: "How many of the hours that I'm paying you to build it is it going to take you to build?"

[4] Nobody wanted to work for us. We were both a "boring telecom" and a company that tended to want to hire developers at their big HQ, located in a region of the country with 1% unemployment for that job category (during its worst times). And, of course, they struggled during the 2000s dot-bomb, "Surprise Fired" half the IT/dev staff one day on a Friday (replaced with over-seas contractors) which gave them a terrible reputation among candidates.

[5] My team was the only development team reporting up through the Infrastructure/Support organization. They tried to move us under development every time someone up the reporting chain (anywhere in IT) noticed the out-of-place department, nearly every year (this was the second most common org-related meeting, the other was "why do we write this in house at all?"). We loved these meetings; it was fun to get a large room of people to agree to something they thought was a "terrible idea" when they walked through the door.

kwang87• 5 years ago

Agile wont work especially if middle management aren't behind it 100% And they won't because if Agile done right will eliminate the need of middle managers. Think Traditional big bank vs Credit Unions. Where as big banks they are in control while Credit Unions are the account holders are in control. I been a scrum master for 2 years and the biggest fight I had was stopping and preventing sabotage. Ultimately it wears on you and you give up.

silicon2401• 5 years ago

In my career so far, I've most enjoyed working on kanban-esque teams. Just a bunch of tickets, maybe sorted by priority, for anybody to jump on. A wireframe to reference and quick slack updates once a day. Ironically, this was my least favorite job, but the working style has turned out to be my favorite.

Since then I've worked on agile teams and found it to be less useful. I'm sure there are reasons for why, but strictly from a personal point of view, it's much more fun and relaxing to just do kanban.

midrus2• 5 years ago

Exact same experience. A kanban board with clear priorities was my best experience so far in my near 25 years of career in this field. This was thanks to the big bosses which were pretty chill in regard to when things would be ready, as long as it was "as soon as possible" they were happy.

All the Agile an scrum bullshit get introduced the moment the higher ups want to have exact estimates and deadlines and just shipping features is the only prioirity. Despite all the stupid effort to predict task sizes and times in the end they're always wrong, things take more time (or less) and we wasted a ton of time and mental energy on the shared taboo lie that we're estimating stuff.

midrus2• 5 years ago

I don't know about Agile but I'm doing SCRUM by the book at my new job and I want to kill myself every other second.

Zigurd• 5 years ago

This line from the article is applicable to a wide range of Agile add-ons and recipes: "An unnecessary rebrand of an existing concept... that goes against the fundamental principles behind agile."

SAFe might be the pinnacle of Agile practitioners rebranding everything as part of their particular extensions of Agile.

Scaling up Agile in big enterprises is important. But rebranding things senior management already does and knows how to do is counterproductive and cult-like. Not every part of a business benefits from Agile.

Agile Is Dead, McKinsey Just Killed It

Related Stories