11 ms·

Agile Is Dead, McKinsey Just Killed It

60 points by noptd 5y ago

jon-wood 5y ago
The website is dead, Hacker News just killed it. archive.org mirror: https://web.archive.org/web/20210721043921/https://terem.tech/agile-is-dead/ https://web.archive.org/web/20210721043921/https://terem.tec...
- dstick 5y 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.
  - deleted 5y ago
    [deleted]
  - xorcist 5y 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 5y 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 5y 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_middleton 5y 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.
  - noptd 5y 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 5y 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 5y 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.
tempodox 5y 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 5y 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.
  - tempodox 5y ago
    All clicks are final. There is no reimbursement.
- matt_s 5y 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"
  - pjmlp 5y 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,...
    - matt_s 5y ago
      Totally agree that non-software benefits from traditional project planning. In a project management class it was taught that the project framework should be adapted to the project. It sounds really formal but planning how you plan the project is key for some things. For example, I would guess building a nuclear power plant isn't an iterative type of project. Lots of risks and lots of sequential activities. A team could probably spend weeks to months just planning the plan.
mongol 5y 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 5y 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 5y 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 5y 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 5y ago
  seconded; thats a summary of everything I strive for
  - leoc 5y ago
    It's from the original Snowbird manifesto: https://agilemanifesto.org/ https://agilemanifesto.org/ https://www.theatlantic.com/technology/archive/2017/12/agile-manifesto-a-history/547715/ https://www.theatlantic.com/technology/archive/2017/12/agile...
- creshal 5y ago
  The Agile Manifesto and what consultants peddle as "agile" have a surprisingly small overlap.
- nickjj 5y 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 5y 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.
- 5y ago
booleandilemma 5y ago
Does this mean I don’t have to go to standup today?
linker3000 5y 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!
stefanve 5y 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 5y 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.
  - ykevinator3 5y ago
    It's so true
  - stefanve 5y 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).
    - scott_middleton 5y ago
skohan 5y 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 5y ago
  Care to share more?
FpUser 5y 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 5y 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 5y 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-blockchain 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.
- geodel 5y ago
  Agree. It just means same snake oil is available in new improved packaging. No longer one has to keep using grubby old bottle.
- tharne 5y 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 5y 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.
Chris_Newton 5y 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_holmes 5y 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_Newton 5y 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”.
bm3719 5y 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 5y 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_middleton 5y ago
  The last line gave me a chuckle.
- noptd 5y 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 5y 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.
- dragonwriter 5y 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.
throwaway2016a 5y 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 5y 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…
  - throwaway2016a 5y 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."
brightball 5y 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 5y 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 5y 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 5y 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_middleton 5y 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 5y 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 5y 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 5y 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.
- midrus 5y 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.
midrus 5y 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 5y 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.

60 points by noptd 5y ago

The website is dead, Hacker News just killed it. archive.org mirror: https://web.archive.org/web/20210721043921/https://terem.tech/agile-is-dead/ https://web.archive.org/web/20210721043921/https://terem.tec...

dstick 5y 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.
- deleted 5y ago
  [deleted]
- xorcist 5y 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 5y 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 5y 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_middleton 5y 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.
- noptd 5y 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 5y 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 5y 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.

tempodox 5y 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 5y 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.
- tempodox 5y ago
  All clicks are final. There is no reimbursement.
matt_s 5y 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"
- pjmlp 5y 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,...
  - matt_s 5y ago
    Totally agree that non-software benefits from traditional project planning. In a project management class it was taught that the project framework should be adapted to the project. It sounds really formal but planning how you plan the project is key for some things. For example, I would guess building a nuclear power plant isn't an iterative type of project. Lots of risks and lots of sequential activities. A team could probably spend weeks to months just planning the plan.

mongol 5y 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 5y 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 5y 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 5y 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 5y ago
seconded; thats a summary of everything I strive for
- leoc 5y ago
  It's from the original Snowbird manifesto: https://agilemanifesto.org/ https://agilemanifesto.org/ https://www.theatlantic.com/technology/archive/2017/12/agile-manifesto-a-history/547715/ https://www.theatlantic.com/technology/archive/2017/12/agile...
creshal 5y ago
The Agile Manifesto and what consultants peddle as "agile" have a surprisingly small overlap.
nickjj 5y 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 5y 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.
5y ago

booleandilemma 5y ago

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

linker3000 5y 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!

stefanve 5y 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 5y 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.
- ykevinator3 5y ago
  It's so true
- stefanve 5y 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).
  - scott_middleton 5y ago

skohan 5y 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 5y ago
Care to share more?

FpUser 5y 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 5y 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 5y 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-blockchain 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.
geodel 5y ago
Agree. It just means same snake oil is available in new improved packaging. No longer one has to keep using grubby old bottle.
tharne 5y 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 5y 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.

Chris_Newton 5y 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_holmes 5y 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_Newton 5y 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”.

bm3719 5y 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 5y 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_middleton 5y ago
The last line gave me a chuckle.
noptd 5y 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 5y 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.
dragonwriter 5y 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.

throwaway2016a 5y 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 5y 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…
- throwaway2016a 5y 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."

brightball 5y 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 5y 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 5y 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 5y 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_middleton 5y 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 5y 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 5y 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 5y 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.

midrus 5y 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.

midrus 5y 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 5y 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.