14 ms·

The State of Agile Software in 2018

213 points by fagnerbrack 8y ago

hamilyon2 8y ago
Much, much better transcript version https://martinfowler.com/articles/agile-aus-2018.html https://martinfowler.com/articles/agile-aus-2018.html
- dang 8y ago
  Ok, we changed to that from https://www.infoq.com/presentations/agile-2018 https://www.infoq.com/presentations/agile-2018. Thanks!
airfreak 8y ago
This might just be the best, well-balanced talk on how agile has gone wrong, and ways to combat the decay. I've seen a lot great teams and poor teams operate. A common set of components in great teams: Technical excellence, freedom coupled with accountability and giving a shit about the quality of their work. Poor teams: lack of discipline, not caring and poor technical skills. I've also seen great teams fall apart due to external influence. That influence was agile gone wrong, imposed from the top. Freedom: gone, but accountability remains. Technical practices valued by the team: deprioritized by the process. Giving a shit: demotivation followed by quitting or being fired.
a_imho 8y ago
I've always wondered what makes Martin Fowler such an authoritative voice in software?
- i_made_a_booboo 8y ago
  A microphone and a blog. Throw in a book for good measure.
- perlgeek 8y ago
  Fowler has been working for many years at a consulting company (ThoughtWorks), and thus has had insights into many, many software development projects. Then he has started writing blogs, books, giving talks etc, which has increased his reputation. I don't agree with everything he writes, probably because we have very different perspectives, but nearly everything technical he writes seems to be very solid, and I've never seen any bullshit from him. I respect that, lots of other developers do that too.
  - pytester 8y ago
    He's definitely no bullshit but he's not very good at contextualizing the stuff he writes. Instead of writing "we did X in Y situation and it worked out great, but it probably wouldn't work well in Z situation" he just says "X is awesome, everybody should be doing it". And that's the story of how I came to work on a team that maintained ~16 unnecessary microservices.
pjmlp 8y ago
Around me agile has turned into 2 week mini-waterfalls, and everything else seems a very distant past.
- Cthulhu_ 8y ago
  I've been in a project like that for a while and it was actually pretty good, we got stuff done on a regular and predictable cadence.
  - pjmlp 8y ago
    Not saying it is that bad, just confirming that agile hasn't lived up to the promises as most companies aren't willing to go all way in. Which is understandable, because according to my experience it is very hard to fit all departments into an agile concept, specially in companies which aren't focused on selling software. Then you also get stuff like 100% unit test coverage for beautiful management reports, which blows up development costs, as some teams spend more time writing mocks and trying to find ways to test UI code than actually writing product code.
    - himynameisdom 8y ago
      You can lead a horse to water, but you can't make them drink it. I don't know why anyone would blame the water for a dehydrated horse.
      - pjmlp 8y ago
        Maybe the water is tainted and staying dehydrated is a matter of survival.
  - xab9 8y ago
    I worked last time on a large scale project with full waterfall and heck, it was good. I knew what to do, when to do it, team lead had great domain knowledge and was a nice guy etc. Then the company decided that products are not built fast enough, so we should be "agile". Guess we all know the rest of the story.
wokwokwok 8y ago
This a lovely read, and rings true on so many levels. Dark scrum huh? Nice. I feel like there are a lot of people who will read that, about technical excellence, about teams choosing their own ways to work, about needing to constantly change and feel uncomfortable about it. ...but, face it. If you do, you’re not doing agile, you’re just calling it agile.
hliyan 8y ago
This may vary from region to region, but my biggest issue with the present Agile trend is the cargo-culting of SCRUM. Sprints, standups, reviews and retros, planning poker, all followed blindly, but to no effect. Worse yet, the dreaded term "anti-agile" is used to shut down any other way of operating. It has almost become a religion and any attempts at advocating planning discipline or detailed designs (even in domains where it's called for) are quickly labeled and rejected as "waterfall". Some project managers trained in agile methodologies have trouble grasping some basic common sense project management practices such as dependency tracking and capacity planning. I recently gave up on all buzzwords and boiled the whole thing down to 3 things: 1. Deliver things in small, testable chunks 2. Start with a best-effort plan, but refine weekly based on how things went 3. If you're blocked or your work is at risk, let others know ASAP
- electrotype 8y ago
  Amen
- ChrisSD 8y ago
  The irony being that agile was meant to be a rejection of blindly following a ONE TRUE WAY. A major point was to periodically review your processes and adapt them to better suit your situation. The idea being you don't get locked in to a process that's no longer working and even have some freedom to experiment.
  - gonzo41 8y ago
    But I'm telling you people!, the earth revolves around the sun. ---Burn him!!!! We're currently swallowing the Scaled Agile Framework pill and I honestly think that it's cause maybe 3 serious episode of depression and burnout in 7 person team. We failed a sprint a while back. No one knew you could do that until we did. So at least we're learning.
    - arcbyte 8y ago
      SAFe is actually fine if you choose an appropriate level and follow the practices. It's ridiculous how people read that SAFe is "tailorable" and then promptly do something that is in no way Safe. Every single day i tell my coworkers to RTFM
pytester 8y ago
>We have to recognize that and fight against it because some people have said, "Oh, we're going to 'post-agile', we've got to come up with some new word," - but that doesn't help the fundamental problem. It's the values and principles that count and we have to address and keep pushing those forwards and we might as well use the same label, but we've got to let people know what it really stands for. The heart of the problem he's describing here stems from the fact that those principles were originally quite vague: * Individuals and interactions over processes and tools (does this mean prefer meetings to writing tests and creating a CI pipeline?) * Working software over comprehensive documentation (don't write documentation? do write documentation? Why not both? Moreover even the most waterfall of companies I've seen have never actually prioritized documentation over working software) * Customer collaboration over contract negotiation (never did encounter a situation where this principle could even be applied... does this phrase use contract negotiation as a metaphor or is he talking about literal contract negotiation?) * Responding to change over following a plan (he actually complains in this article that he never meant "don't plan"... idk) Contrast that with, say "develop iteratively, in small chunks and, where feasible write the test first and release frequently and talk regularly with the customer" -- those are specific principles. If you create a vague set of principles surrounding an idea that resonates deeply with people then the emergence of a "priesthood" that doesn't necessarily agree with your original intentions is somewhat inevitable, no?
- virtualized 8y ago
  Yes, the values are too vague. The twelve principles are better for conveying what Agile is trying to be. The "responding to change" point means in practice that it's better to deviate from a plan than to not have any plan to deviate from. The plan has to be adjusted all the time. For that to be possible, there has to be a plan. The twelve principles are very basic, common sense. Common sense is not common though.
  - hotcrossbunny 8y ago
    Well said!
- i_made_a_booboo 8y ago
deleted 8y ago
[deleted]
ManuelKiessling 8y ago
Related: "The Tragedy of Craftsmanship" https://blog.cleancoder.com/uncle-bob/2018/08/28/CraftsmanshipMovement.html https://blog.cleancoder.com/uncle-bob/2018/08/28/Craftsmansh...
Khaine 8y ago
Many aspects of this talk (around the lessons to learn from Agile and failed Agile) can be applied more broadly to most functions and industries, not just software development.
- pjmlp 8y ago
  Given the age of software industry we are quite late to the party, hence relearning history. I still look forward to proper quality assessment and responsibility like in other industries.
arendtio 8y ago
I always knew that Scrum wasn't as agile as some people want to tell you, but this was the first time I read about 'Dark Scrum' [1]. In my opinion, Scrum is a good tool to kickstart the process of becoming an agile organization, but too often the process languishes there and generates a lot of frustration. [1]: https://ronjeffries.com/articles/016-09ff/defense/ https://ronjeffries.com/articles/016-09ff/defense/
lmilcin 8y ago
That's unfortunately roughly what I am seeing. It is pattern of management pushing on teams and then team members themselves declaring "agile" without willingness to actually understand what and why they want to achieve this way, without willingness to understand what Agile really entails and why it works. Being "agile" is a political issue now in every major corporation. Everybody "is" "agile" because not declaring "being agile" puts you against your management who themselves don't understand and don't care and wouldn't recognize Agile way of thinking if they stumbled on it. But that's just what you have to do because you already have scores of other things to fight for and you can't fight every war so you decide this is just one of the things corporations do and you will just try to do your job. This is really problematic because it completely undermines efforts of people really understanding and trying to introduce Agile way of thinking. Since everybody else already "is agile" and since the effects can only be seen through participation of everybody in the way of thinking and only after a longer period of practice, the management is very unlikely to ever observe any Agile team and and observe positive results of that team as flowing from them working on being Agile. Effectively management is never going to learn Agile because the setup is such that it severely impedes any efforts to introduce and promote Agile.
- deleted 8y ago
  [deleted]
keithnz 8y ago
agile is a manifesto that I don't think should have ever become whatever people think it is today , its sort of become this Scrumish thing with consultants that try to sell faux zen like wisdom. Some of the silly thought experiments that were getting done on the email lists about how "extreme" we could take things that were done around the early 2000s have now become weird dogma. It's just a mess. I think part of the problem is that some of the core philosophy that people like Kent Beck were trying to capture and communicate was actually quite nuanced and subtle that it simply got lost in the noise of the new "Agile Industry" that quickly latched onto blunt and concrete rules about how to do things and a lot of things seemed lost and diluted over time.
tempodox 8y ago
> And yet what I'm hearing so much is the Agile Industrial Complex imposing methods upon people, and that to me is an absolute travesty. I find it depressing that Fowler sees the same problem I do. I have yet to find a shop that practices “agile” in a way that's actually consistent with the Agile Manifesto. What I've been seeing instead was micromanagement and cargo cult. All power to make decisions lies with management and if there are developers involved at all, it's the top one or two who are de facto part of management.
- johan_larson 8y ago
  Agile methods do have a bit of a problem with the concept of authority. They really really want to believe that at least within a development team, everyone is equal. That's not a great fit to actual dev teams in companies where there are junior devs, senior devs, architects, and managers.
  - JoeAltmaier 8y ago
    I'm thinking they make an effort to accommodate that. The poker idea is to average out the team's estimates which is shown to come to a reasonable number (adding up noisy signals equals a better signal). And the whole scrum thing is explicitly to let mentoring happen organically
  - pjc50 8y ago
    In my experience the power structure within the team is fairly flat, it's the managers outside the team that insist on having authority, micromanagement and veto rights over things they don't understand.
  - conradfr 8y ago
    A senior dev in an Scrum team is supposed to do the same work as the junior, except faster! Then they'll wonder why the experienced people quit.
    - detaro 8y ago
      > A senior dev in an Scrum team is supposed to do the same work as the junior, except faster! Where do Scrum principles/rules/... say that? (I have only passing familarity with, but I haven't seen much that went into more detail than "the development team organizes itself to complete the tasks", which leaves the internal structure open)
snarfy 8y ago
After doing software for almost 30 years now, I honestly believe Agile has been the most destructive thing to happen to the industry. Software has become buggy shit that's shoveled out the door as fast as possible. It's not just your development team, it's all development teams. Windows 10 update deleting your files? Is it the lack of testing, poor code quality, too many features or not enough engineers? Ultimately it's going to boil down to some cargo cult scrum process of reviews, retros, and bs that we are all familiar with, and Windows 10 is buggy. Android is buggy. iOS is buggy. Nobody cares about the software. They blindly follow the process.
- Bombthecat 8y ago
  Windows 10 failed because they fired all there testers...
  - pjmlp 8y ago
    Which is exactly what happens in many "agile" projects, test team gets replaced by devops and unit tests. Except those unit tests get a lower priority than writing documentation. And we all know which priority writing documentation gets.
    - ggregoire 8y ago
      Not sure what “agile” projects you are talking about, but SCRUM doesn’t advocate writing documentation. Also SCRUM has a concept of Definition of Done, which can include writing the unit/functional/integration tests related to your task. Also SCRUM recommends to have a human tests that your task is not bugged before shipping (that’s the job of the PO or the tech lead).
      - pjmlp 8y ago
        That is the theory, then there is the actual practice on software development battlefield.
        8y ago
jeremyjh 8y ago
Perhaps we need to question the basic assumption that these ideas and values are worth a damn. The C3 project that started this whole circus twenty years ago completely failed[0] after if its primary business subject matter expert burnt out. This stuff only works when you have really good people committed to each other and their goal. That just isn't something you can expect to find in most of corporate america. If things are so bad that you are bringing in a process consultant, its almost a surety that agile cannot work for you. [0]: http://wiki.c2.com/?WasChryslerComprehensiveCompensationSuccess http://wiki.c2.com/?WasChryslerComprehensiveCompensationSucc...
johan_larson 8y ago
I've worked at four companies that have claimed to do agile development. Not one of them has deeply embraced the principles of doing so. Generally they have added a few easy practices, like stand-up meetings and sprints. They've kept large-scale chunks assigned to specific developers, defining both the work to be done and the time to do it, and substantial design docs. Unit testing tends to be spotty. We're not living in Agile World. We're living in Fake Agile World. I have some reservations about true-blue agile, but I'd be willing to give it a shot. Let's do Fundamentalist Scrum once. I'd be up for it. At least I'd know whether it works or not.
abernard1 8y ago
My problem with current "Agile" beyond the complaints in that talk is it can mean absolutely anything. Nothing is falsifiable, and the snake oil industry views that as a feature. Most of that revolves around the way retrospectives are handled and the weird way in which "continuous improvement" is viewed. Agile sees this as continuous process improvement, instead of say, people improvement, team improvement, or software improvement. This process for creating process (aka "bureaucracy") has led to retrospectives evaluating things like burndowns, "What about our process went well?" or "What about our process didn't go well?", etc. Scrum has basically a built-in bias to destroy itself: "We've iterated into this super process-oriented way of doing work, and we did it in small steps.... Agile!!!" I once made a comment that neither I, my company's customers, nor their customers were paid in story points. I still think that is the crux of why Scrum is so broken. Agility will become more pronounced in software teams when the feedback mechanism ("retrospective") is based upon 1) qualitatively evaluating product success, and 2) quantitatively measuring something that is relevant to the product or business being built and not a peripheral concern like how much work was done or how it was done. Work done, predictability, and even lateness have very little to do with product success outside the realm of contracting.
- himynameisdom 8y ago
  Focusing on story points is not Scrum, so why blame Scrum? Rather it's clearly delineated that a Scrum team product owner's main job is to maximize the value delivered through development to the customer. 50 story points means nothing unless the PO has prioritized work that's going to yield the most value to the client. Scrum isn't broken. It's literally all laid out in a 16 page document. Nowhere will you find mention of story points. Stop blaming the framework for someone's bastardization of what said framework is meant to achieve.
asaph 8y ago
> ... the reality is troubling, because much of what is done is faux-agile, disregarding agile's values and principles. This is a problem with "agile" and scrum. If the process isn't working for you, it's your fault for not doing it right. And no one is ever doing it right. A truly "agile" team is one that operates in some impossibly perfect Zen-like state that no team achieves in practice. Maybe it's not you. Maybe it is the process.
- himynameisdom 8y ago
  Scrum isn't a process, it's a framework to utilize your own processes. That's like blaming the framework of the house for a bad paint job.
denimnerd 8y ago
my gigantic org is transforming to agile pretty well to be honest. wish there was some positivity in here. biggest problem is lack of technical excellence but people understand the point of agile pretty well and we are working through what makes it difficult to "be agile"
- maxxxxx 8y ago
  If everyone is adapting to it this may work. What I have seen in companies is that the devs suddenly have to do scrum but everybody else in the company does business as usual. In my current company we did scrum training a while ago and not even the dev managers showed up. And it shows when you talk to them. They have no idea what agile really means other than sprints and "commitments". So instead of being an environment where everybody respects each other it has turned into a pressure cooker for the devs.
  - denimnerd 8y ago
    yeah it’s complete buyin from senior execs to business leaders, to business side employees who are tasked with being product owner. no such thing as a tech lead, organization got flattened out etc.
    - maxxxxx 8y ago
      That's how an agile introduction should be done but almost never does.
asaph 8y ago
I've always had a problem with the scrum concept of team velocity i.e. assigning story points to tasks and then measuring how many story points a team delivers each sprint. The idea that this yeilds any predictive power is flawed. It's based on the assumption that the team is static. As soon as someone leaves the team or someone new joins, all the historical velocity data becomes useless and you need to recalibrate. The reality is that teams are dynamic. They grow/shrink/change all the time.
- himynameisdom 8y ago
  This is up to the team to help other people understand that velocity/productivity is more than likely decrease as team dynamics change. Even if more people are put on a product, the velocity is expected to decrease as those people absorb new responsibilities. Same story for losing people on a product.
- AnimalMuppet 8y ago
  Sure, the team is dynamic. Smart agile people expect that changing the team will change the achievable velocity. Clueless "agile" people proceed as if nothing had changed. But that's not really an agile problem. You can have a waterfall-ish schedule, then the team changes, and management wants to keep the original dates. It's the same problem.
bsvalley 8y ago
I started working with agile since day one and it was fun back then. Why? Because it made projects so much more interesting. We were learning how to do things differently and it was pretty cool. Unfortunately, it became more popular and upper management started looking at the benefits of Agile. “Tell me one reason why we should adopt agile in our company?”. Unfortunately, a good answer to that was the ability to track the progress and a large increase in delivery and productivity. Teams hate those words but management love them. That’s what agile became today, tracking progress with constant status updates, charts and metrics that tell a team “clearly you did a really bad job this time” or “you’re late”. Management doesn’t even have to do the dirty job anymore. Meaningless meetings, less power for engineers, no creativity (ain’t got time for that!), etc. It went from a cool way to do things to a perfect tool for factories. No offense to factory workers.
- JoeAltmaier 8y ago
  And the illusion of getting things done, because tickets! makes it seem like progress is happening even if churn is all that's happening. Last contract (I left) was 6 years into churning the same awful pile of spaghetti. I came on board to help break the logjam. Micromanaging Agile manager put me on fire fighting, just like all his other reports, just like the last 6 years of churning had done. Left after 6 months and it was obvious they were going nowhere.
- pjc50 8y ago
  Exactly. Doing Agile properly requires a bi-directional mutually respectful communication between the development team and the product stakeholders. It's the complete opposite of traditional suspicion-based hierarchical management. That's why it has so much difficulty getting adopted.
da_murvel 8y ago
"... much of what is done is faux-agile, disregarding agile's values and principles." This. It feels so easy to get caught up in methods and tools, to not make a proper commitment (because it is tough to change the way you work) and to land in a sort of semi-agile state that no one likes.
lbriner 8y ago
Is there a problem in what we might call a meta-framework like agile in that it requires the "good people" that Martin Fowler talks about when the reality is that most of our teams are at least partially average? People have to learn examples of its implementation but are either not knowledgable enough or trusted enough to start doing things their own way, which causes the rigidity that everyone is talking about. That and the fact that tooling is not something that most people can knock up in a few days so we relay on the software and its somewhat rigid processes which means we aren't free to innovate fully anyway. It's a bit like complaining that most musicians only do music the way they learned at college and do not adapt to the "principles of music".
tnolet 8y ago
This whole discussion echoes the DevOps discussion and its definition. What DevOps is and what it means to different people is still hazy and can be twisted into anti-DevOps quite easily.
- perlgeek 8y ago
  It's even worse with DevOps, IMHO. Agile at least has the Manifesto of Agile Software Development, which you can go back to, and see if a given process adheres to the ideas in the manifesto. With DevOps, you have basically nothing foundational that people can agree on.
dandare 8y ago
Agile is like a religion. There is not a single consistent definition and any criticism is easily deflected along the lines that your organization did not embrace Agile on all levels of management. The uncomfortable truth is that Agile is internally inconsistent - you can not build an Agile methodology that will not contradict itself and that will not contradict the real world. A perfect example is the INVEST mnemonic for backlog items or the notion that Acceptance Criteria is against Agile. One Agile coach ($$$) recently told me that the fact that I have contractual requirements and legal requirements in AC that I need to test for is a symptom of my customers not being Agile and the government not being Agile.
codeulike 8y ago
I like to sneakily endorse people on LinkedIn with the 'Waterfall' skill tag.
venantius 8y ago
This article really hit home for me living in London. Having spent 7 years working in San Francisco and the valley, the degree to which "project management" and the use of buzzwords in the greater London tech scene are divorced from their original uses drives me absolutely bananas. And what's worse is that faux-agile has taken such a strong hold that I seem like the crazy person when I tell them that's not how software is developed in California.
- mrfredward 8y ago
  I live in the U.S. but I'm working remotely with a mainly U.K. based team that's doing "agile". The way they do it, at the end of a sprint all your tests have to pass, but it's normal for the trunk (yes we're using SVN) to be totally broken until then. That's all a sprint means to them, a block of time when it's okay for things to be broken. I think this company got into it's current predicament by buying a ticket tracker that uses the word "agile" and never learning anything about it beyond the words in the tracker. Needless to say, the current process isn't working very well.
- himynameisdom 8y ago
  I agree. It's amazing how many people on here are blaming the framework for their organization's implementation/interpretation of the framework. There's an insane amount of work going into discussions with people who've been burned by Dark Agile.
bullen 8y ago
https://news.ycombinator.com/item?id=16772788 https://news.ycombinator.com/item?id=16772788
mathw 8y ago
Four weeks ago my team changed from not-really-scrum-we're-just-pretending some some sort of kanban-like process, which was the first real change after I stuck an item on the wall during a retro which just said "Are we doing Scrum? Should we be?" Today we had a retro in which we talked about how things are going, and we're all more comfortable with how the process fits our actual workflow, and how it's opened up some other changes that have really helped us with getting useful stuff done, delivered and in the hands of people who appreciate it. And this came from within the team, entirely, with the support of our team lead. It's not perfect, but it's good, and we feel able to change things. That's why the other changes happened - because we were reminded that we have the power to change things, and the company actually genuinely believes that. There are some things we can't change, or not so easily, because they cross team boundaries or require money to be spent that we can't convince someone to authorise, but we have more freedom within the team than we had believed that we had. Largely I think because most of us are fairly new to the company and had long ago forgotten the idea of self-organising agile teams because the very concept was a joke most other places we've worked. I suspect we'll change things in the future, and we do have some concerns at the moment about how we split up big bits of work like implementing a completely new system component into cards of a suitable size and self-containedness and various other issues around definitions of done, but we'll work it out. For now, we're apparently more productive, we certainly feel more productive, and we're all happier because we don't have the entirely artificial pressure to ship something every sprint. That's not how the software we maintain works, and not how it should work either. We just ship stuff when it's ready, because that's what makes us and our stakeholders happy. What Fowler's describing is something I've seen so many times. Scrum-adherence is in itself something of a cult in some places, and it's done without any mindfulness for why you choose certain processes, the purpose of certain things and whether Scrum was a good choice for you or not. And I think honestly that's most people's experience of "agile" software development, because people have turned it into an industry of its own and with that comes the books, the rules, the certifications, and the legions of people who read a bit about it and decided that'd be great and it'd tick the trendy "agile" box without having to disrupt the company too much. Bleergh. Oh and something else my current employer does that I've seen literally nowhere else? A no-blame culture. We actually have one. I wish everyone could try it.
navane 8y ago
We're doing agile in a mechanical engineering firm. A multiyear project. The first thing we'll deliver will be two years from now. I struggle to put into words why this is such a bad idea because its so blatantly obvious. Imagine designing and building the golden gate bridge as an agile process.
- mixmastamyk 8y ago
  Agile process doesn't necessarily mean agile delivery. But I might worry too.
ggregoire 8y ago
So it’s probably an unpopular opinion on HN, but I’ve seen SCRUM implemented in 3 companies during my career and it has been an improvement for each one of them.
ryanmarsh 8y ago
Agile Coach here. FIRE YOUR AGILE COACHES The monstrosity that agile has become is an insult to the courageous pioneers who spoke out and swam against the current (at the time) to save software engineers from an overreaction to the growing complexity of computer systems. The result has been an overreaction to an overreaction. 1. MOST COACHES ARE MUPPETS Most Agile coaches today have a serious lack of engineering and leadership experience. They are merely the sum of the Agile classes they've attended and the book or two they may have skimmed. Most agile coaches do not understand the theoretical underpinnings of their field and therefore can only parrot statements from other "agile leaders". Most can't write code, have never managed anything as large as the groups they coach, don't understand software development in general, thus you would be a fool to take advice from them. Here's an example. A friend told me a story this week about a new coach who came in and pronounced that what they needed was "big room planning". He proclaimed this without having any context whatsoever. What is one to do when all one has is a hammer? This is not an anomaly, it's par for the course. 2. YOU'RE BETTER OFF IF YOU DO IT YOURSELF Today enough has been published about the dangers of approaching complex problems with the tools for solving merely complicated problems. You don't need a Priest of the All Mighty Agile to warn of you of Eternal Damnation and prescribe the One True Way. Every "tool" any agile coach can use to help you understand the challenges to production flow (such as Value Stream Mapping) can all be found in digestible articles on Medium. If you're having trouble finding these my email is in my bio. If you, as a leader, take the time to understand your chosen field of Software Engineering Leadership, and then... you know... actually lead, your organization will subsequently obtain the necessary habits to continue to change and improve as your company grows and changes. The value of this cannot be overstated. Most companies calling me for help today have anemic leadership and that's their problem. They don't need an expert in software delivery performance to help them skip some of the boilerplate, they need Extreme Ownership and true leadership. Instead they continue suckle on the tit of Agile Coaches 5-10 years into an "Agile Transformation" when they should be up on their own two legs walking and eating with a fork. Agile Coaches have, if anything become an enabler to the worst corporate cultures and mindless bureaucracies software engineers have ever had the displeasure to work under. 3. YOU CAN'T SHIP BECAUSE SOFTWARE DOESN'T MATTER Lastly, the reason most companies who struggle to increase quality and simultaneously increase delivery performance (aka Business Performance in 2018) is because they don't care about software. It is true, no one starts a bank to have an IT department. However some companies have awoken to the fact that in 2018 TECHNOLOGY PERFORMANCE IS BUSINESS PERFORMANCE. If you are not one of these companies you (personally) have two choices, go and work for one, or lead your company to become one. The alternative is... a steady paycheck? Even in the most laggardly industries, leaders are waking up to the fact that getting technology performance right is the only competitive angle. When these clients call me the things we accomplish are breathtaking. Sadly, they are a tiny minority. Most companies call coaches so a VP can show he's checking all the boxes, so they can continue with the status quo. Some financial institutions may talk about the danger of "Fin tech startups" but when you have enough in assets that you can coast for 50 years, or you have billions in infrastructure that a competitor with all the money in the world couldn't replace inside of a decade, the reality is SOFTWARE DOESN'T MATTER. You can suck as much as you want because the challengers are so incredibly far off it really doesn't matter. These places make Agile Coaches lots of money and they're also the ones who fill the conferences. Technology performance doesn't really matter at these companies. This is why you (who work in these companies) struggle to have a sane build pipeline, adequate test coverage with good tests, communication across teams, and you get nowhere. You're swimming against a tsunami. It's exhausting, don't waste your time. Find somewhere that actually sees the leverage technology can provide them and go work there. You'll be a hero.
borvo 8y ago
"this realization that people are operating at the best when they choose how they want to work" But what if how they want to work is "Dark Scrum"... or some kind of Agile religion, or waterfall.

213 points by fagnerbrack 8y ago

Much, much better transcript version https://martinfowler.com/articles/agile-aus-2018.html https://martinfowler.com/articles/agile-aus-2018.html

dang 8y ago
Ok, we changed to that from https://www.infoq.com/presentations/agile-2018 https://www.infoq.com/presentations/agile-2018. Thanks!

airfreak 8y ago

This might just be the best, well-balanced talk on how agile has gone wrong, and ways to combat the decay. I've seen a lot great teams and poor teams operate. A common set of components in great teams: Technical excellence, freedom coupled with accountability and giving a shit about the quality of their work. Poor teams: lack of discipline, not caring and poor technical skills. I've also seen great teams fall apart due to external influence. That influence was agile gone wrong, imposed from the top. Freedom: gone, but accountability remains. Technical practices valued by the team: deprioritized by the process. Giving a shit: demotivation followed by quitting or being fired.

a_imho 8y ago

I've always wondered what makes Martin Fowler such an authoritative voice in software?

i_made_a_booboo 8y ago
A microphone and a blog. Throw in a book for good measure.
perlgeek 8y ago
Fowler has been working for many years at a consulting company (ThoughtWorks), and thus has had insights into many, many software development projects. Then he has started writing blogs, books, giving talks etc, which has increased his reputation. I don't agree with everything he writes, probably because we have very different perspectives, but nearly everything technical he writes seems to be very solid, and I've never seen any bullshit from him. I respect that, lots of other developers do that too.
- pytester 8y ago
  He's definitely no bullshit but he's not very good at contextualizing the stuff he writes. Instead of writing "we did X in Y situation and it worked out great, but it probably wouldn't work well in Z situation" he just says "X is awesome, everybody should be doing it". And that's the story of how I came to work on a team that maintained ~16 unnecessary microservices.

pjmlp 8y ago

Around me agile has turned into 2 week mini-waterfalls, and everything else seems a very distant past.

Cthulhu_ 8y ago
I've been in a project like that for a while and it was actually pretty good, we got stuff done on a regular and predictable cadence.
- pjmlp 8y ago
  Not saying it is that bad, just confirming that agile hasn't lived up to the promises as most companies aren't willing to go all way in. Which is understandable, because according to my experience it is very hard to fit all departments into an agile concept, specially in companies which aren't focused on selling software. Then you also get stuff like 100% unit test coverage for beautiful management reports, which blows up development costs, as some teams spend more time writing mocks and trying to find ways to test UI code than actually writing product code.
  - himynameisdom 8y ago
    You can lead a horse to water, but you can't make them drink it. I don't know why anyone would blame the water for a dehydrated horse.
    - pjmlp 8y ago
      Maybe the water is tainted and staying dehydrated is a matter of survival.
- xab9 8y ago
  I worked last time on a large scale project with full waterfall and heck, it was good. I knew what to do, when to do it, team lead had great domain knowledge and was a nice guy etc. Then the company decided that products are not built fast enough, so we should be "agile". Guess we all know the rest of the story.

wokwokwok 8y ago

This a lovely read, and rings true on so many levels. Dark scrum huh? Nice. I feel like there are a lot of people who will read that, about technical excellence, about teams choosing their own ways to work, about needing to constantly change and feel uncomfortable about it. ...but, face it. If you do, you’re not doing agile, you’re just calling it agile.

hliyan 8y ago

This may vary from region to region, but my biggest issue with the present Agile trend is the cargo-culting of SCRUM. Sprints, standups, reviews and retros, planning poker, all followed blindly, but to no effect. Worse yet, the dreaded term "anti-agile" is used to shut down any other way of operating. It has almost become a religion and any attempts at advocating planning discipline or detailed designs (even in domains where it's called for) are quickly labeled and rejected as "waterfall". Some project managers trained in agile methodologies have trouble grasping some basic common sense project management practices such as dependency tracking and capacity planning. I recently gave up on all buzzwords and boiled the whole thing down to 3 things: 1. Deliver things in small, testable chunks 2. Start with a best-effort plan, but refine weekly based on how things went 3. If you're blocked or your work is at risk, let others know ASAP

electrotype 8y ago
Amen
ChrisSD 8y ago
The irony being that agile was meant to be a rejection of blindly following a ONE TRUE WAY. A major point was to periodically review your processes and adapt them to better suit your situation. The idea being you don't get locked in to a process that's no longer working and even have some freedom to experiment.
- gonzo41 8y ago
  But I'm telling you people!, the earth revolves around the sun. ---Burn him!!!! We're currently swallowing the Scaled Agile Framework pill and I honestly think that it's cause maybe 3 serious episode of depression and burnout in 7 person team. We failed a sprint a while back. No one knew you could do that until we did. So at least we're learning.
  - arcbyte 8y ago
    SAFe is actually fine if you choose an appropriate level and follow the practices. It's ridiculous how people read that SAFe is "tailorable" and then promptly do something that is in no way Safe. Every single day i tell my coworkers to RTFM

pytester 8y ago

>We have to recognize that and fight against it because some people have said, "Oh, we're going to 'post-agile', we've got to come up with some new word," - but that doesn't help the fundamental problem. It's the values and principles that count and we have to address and keep pushing those forwards and we might as well use the same label, but we've got to let people know what it really stands for. The heart of the problem he's describing here stems from the fact that those principles were originally quite vague: * Individuals and interactions over processes and tools (does this mean prefer meetings to writing tests and creating a CI pipeline?) * Working software over comprehensive documentation (don't write documentation? do write documentation? Why not both? Moreover even the most waterfall of companies I've seen have never actually prioritized documentation over working software) * Customer collaboration over contract negotiation (never did encounter a situation where this principle could even be applied... does this phrase use contract negotiation as a metaphor or is he talking about literal contract negotiation?) * Responding to change over following a plan (he actually complains in this article that he never meant "don't plan"... idk) Contrast that with, say "develop iteratively, in small chunks and, where feasible write the test first and release frequently and talk regularly with the customer" -- those are specific principles. If you create a vague set of principles surrounding an idea that resonates deeply with people then the emergence of a "priesthood" that doesn't necessarily agree with your original intentions is somewhat inevitable, no?

virtualized 8y ago
Yes, the values are too vague. The twelve principles are better for conveying what Agile is trying to be. The "responding to change" point means in practice that it's better to deviate from a plan than to not have any plan to deviate from. The plan has to be adjusted all the time. For that to be possible, there has to be a plan. The twelve principles are very basic, common sense. Common sense is not common though.
- hotcrossbunny 8y ago
  Well said!
i_made_a_booboo 8y ago

deleted 8y ago

[deleted]

ManuelKiessling 8y ago

Related: "The Tragedy of Craftsmanship" https://blog.cleancoder.com/uncle-bob/2018/08/28/CraftsmanshipMovement.html https://blog.cleancoder.com/uncle-bob/2018/08/28/Craftsmansh...

Khaine 8y ago

Many aspects of this talk (around the lessons to learn from Agile and failed Agile) can be applied more broadly to most functions and industries, not just software development.

pjmlp 8y ago
Given the age of software industry we are quite late to the party, hence relearning history. I still look forward to proper quality assessment and responsibility like in other industries.

arendtio 8y ago

I always knew that Scrum wasn't as agile as some people want to tell you, but this was the first time I read about 'Dark Scrum' [1]. In my opinion, Scrum is a good tool to kickstart the process of becoming an agile organization, but too often the process languishes there and generates a lot of frustration. [1]: https://ronjeffries.com/articles/016-09ff/defense/ https://ronjeffries.com/articles/016-09ff/defense/

lmilcin 8y ago

That's unfortunately roughly what I am seeing. It is pattern of management pushing on teams and then team members themselves declaring "agile" without willingness to actually understand what and why they want to achieve this way, without willingness to understand what Agile really entails and why it works. Being "agile" is a political issue now in every major corporation. Everybody "is" "agile" because not declaring "being agile" puts you against your management who themselves don't understand and don't care and wouldn't recognize Agile way of thinking if they stumbled on it. But that's just what you have to do because you already have scores of other things to fight for and you can't fight every war so you decide this is just one of the things corporations do and you will just try to do your job. This is really problematic because it completely undermines efforts of people really understanding and trying to introduce Agile way of thinking. Since everybody else already "is agile" and since the effects can only be seen through participation of everybody in the way of thinking and only after a longer period of practice, the management is very unlikely to ever observe any Agile team and and observe positive results of that team as flowing from them working on being Agile. Effectively management is never going to learn Agile because the setup is such that it severely impedes any efforts to introduce and promote Agile.

deleted 8y ago
[deleted]

keithnz 8y ago

agile is a manifesto that I don't think should have ever become whatever people think it is today , its sort of become this Scrumish thing with consultants that try to sell faux zen like wisdom. Some of the silly thought experiments that were getting done on the email lists about how "extreme" we could take things that were done around the early 2000s have now become weird dogma. It's just a mess. I think part of the problem is that some of the core philosophy that people like Kent Beck were trying to capture and communicate was actually quite nuanced and subtle that it simply got lost in the noise of the new "Agile Industry" that quickly latched onto blunt and concrete rules about how to do things and a lot of things seemed lost and diluted over time.

tempodox 8y ago

> And yet what I'm hearing so much is the Agile Industrial Complex imposing methods upon people, and that to me is an absolute travesty. I find it depressing that Fowler sees the same problem I do. I have yet to find a shop that practices “agile” in a way that's actually consistent with the Agile Manifesto. What I've been seeing instead was micromanagement and cargo cult. All power to make decisions lies with management and if there are developers involved at all, it's the top one or two who are de facto part of management.

johan_larson 8y ago
Agile methods do have a bit of a problem with the concept of authority. They really really want to believe that at least within a development team, everyone is equal. That's not a great fit to actual dev teams in companies where there are junior devs, senior devs, architects, and managers.
- JoeAltmaier 8y ago
  I'm thinking they make an effort to accommodate that. The poker idea is to average out the team's estimates which is shown to come to a reasonable number (adding up noisy signals equals a better signal). And the whole scrum thing is explicitly to let mentoring happen organically
- pjc50 8y ago
  In my experience the power structure within the team is fairly flat, it's the managers outside the team that insist on having authority, micromanagement and veto rights over things they don't understand.
- conradfr 8y ago
  A senior dev in an Scrum team is supposed to do the same work as the junior, except faster! Then they'll wonder why the experienced people quit.
  - detaro 8y ago
    > A senior dev in an Scrum team is supposed to do the same work as the junior, except faster! Where do Scrum principles/rules/... say that? (I have only passing familarity with, but I haven't seen much that went into more detail than "the development team organizes itself to complete the tasks", which leaves the internal structure open)

snarfy 8y ago

After doing software for almost 30 years now, I honestly believe Agile has been the most destructive thing to happen to the industry. Software has become buggy shit that's shoveled out the door as fast as possible. It's not just your development team, it's all development teams. Windows 10 update deleting your files? Is it the lack of testing, poor code quality, too many features or not enough engineers? Ultimately it's going to boil down to some cargo cult scrum process of reviews, retros, and bs that we are all familiar with, and Windows 10 is buggy. Android is buggy. iOS is buggy. Nobody cares about the software. They blindly follow the process.

Bombthecat 8y ago
Windows 10 failed because they fired all there testers...
- pjmlp 8y ago
  Which is exactly what happens in many "agile" projects, test team gets replaced by devops and unit tests. Except those unit tests get a lower priority than writing documentation. And we all know which priority writing documentation gets.
  - ggregoire 8y ago
    Not sure what “agile” projects you are talking about, but SCRUM doesn’t advocate writing documentation. Also SCRUM has a concept of Definition of Done, which can include writing the unit/functional/integration tests related to your task. Also SCRUM recommends to have a human tests that your task is not bugged before shipping (that’s the job of the PO or the tech lead).
    - pjmlp 8y ago
      That is the theory, then there is the actual practice on software development battlefield.
      - 8y ago

jeremyjh 8y ago

Perhaps we need to question the basic assumption that these ideas and values are worth a damn. The C3 project that started this whole circus twenty years ago completely failed[0] after if its primary business subject matter expert burnt out. This stuff only works when you have really good people committed to each other and their goal. That just isn't something you can expect to find in most of corporate america. If things are so bad that you are bringing in a process consultant, its almost a surety that agile cannot work for you. [0]: http://wiki.c2.com/?WasChryslerComprehensiveCompensationSuccess http://wiki.c2.com/?WasChryslerComprehensiveCompensationSucc...

johan_larson 8y ago

I've worked at four companies that have claimed to do agile development. Not one of them has deeply embraced the principles of doing so. Generally they have added a few easy practices, like stand-up meetings and sprints. They've kept large-scale chunks assigned to specific developers, defining both the work to be done and the time to do it, and substantial design docs. Unit testing tends to be spotty. We're not living in Agile World. We're living in Fake Agile World. I have some reservations about true-blue agile, but I'd be willing to give it a shot. Let's do Fundamentalist Scrum once. I'd be up for it. At least I'd know whether it works or not.

abernard1 8y ago

My problem with current "Agile" beyond the complaints in that talk is it can mean absolutely anything. Nothing is falsifiable, and the snake oil industry views that as a feature. Most of that revolves around the way retrospectives are handled and the weird way in which "continuous improvement" is viewed. Agile sees this as continuous process improvement, instead of say, people improvement, team improvement, or software improvement. This process for creating process (aka "bureaucracy") has led to retrospectives evaluating things like burndowns, "What about our process went well?" or "What about our process didn't go well?", etc. Scrum has basically a built-in bias to destroy itself: "We've iterated into this super process-oriented way of doing work, and we did it in small steps.... Agile!!!" I once made a comment that neither I, my company's customers, nor their customers were paid in story points. I still think that is the crux of why Scrum is so broken. Agility will become more pronounced in software teams when the feedback mechanism ("retrospective") is based upon 1) qualitatively evaluating product success, and 2) quantitatively measuring something that is relevant to the product or business being built and not a peripheral concern like how much work was done or how it was done. Work done, predictability, and even lateness have very little to do with product success outside the realm of contracting.

himynameisdom 8y ago
Focusing on story points is not Scrum, so why blame Scrum? Rather it's clearly delineated that a Scrum team product owner's main job is to maximize the value delivered through development to the customer. 50 story points means nothing unless the PO has prioritized work that's going to yield the most value to the client. Scrum isn't broken. It's literally all laid out in a 16 page document. Nowhere will you find mention of story points. Stop blaming the framework for someone's bastardization of what said framework is meant to achieve.

asaph 8y ago

> ... the reality is troubling, because much of what is done is faux-agile, disregarding agile's values and principles. This is a problem with "agile" and scrum. If the process isn't working for you, it's your fault for not doing it right. And no one is ever doing it right. A truly "agile" team is one that operates in some impossibly perfect Zen-like state that no team achieves in practice. Maybe it's not you. Maybe it is the process.

himynameisdom 8y ago
Scrum isn't a process, it's a framework to utilize your own processes. That's like blaming the framework of the house for a bad paint job.

denimnerd 8y ago

my gigantic org is transforming to agile pretty well to be honest. wish there was some positivity in here. biggest problem is lack of technical excellence but people understand the point of agile pretty well and we are working through what makes it difficult to "be agile"

maxxxxx 8y ago
If everyone is adapting to it this may work. What I have seen in companies is that the devs suddenly have to do scrum but everybody else in the company does business as usual. In my current company we did scrum training a while ago and not even the dev managers showed up. And it shows when you talk to them. They have no idea what agile really means other than sprints and "commitments". So instead of being an environment where everybody respects each other it has turned into a pressure cooker for the devs.
- denimnerd 8y ago
  yeah it’s complete buyin from senior execs to business leaders, to business side employees who are tasked with being product owner. no such thing as a tech lead, organization got flattened out etc.
  - maxxxxx 8y ago
    That's how an agile introduction should be done but almost never does.

asaph 8y ago

I've always had a problem with the scrum concept of team velocity i.e. assigning story points to tasks and then measuring how many story points a team delivers each sprint. The idea that this yeilds any predictive power is flawed. It's based on the assumption that the team is static. As soon as someone leaves the team or someone new joins, all the historical velocity data becomes useless and you need to recalibrate. The reality is that teams are dynamic. They grow/shrink/change all the time.

himynameisdom 8y ago
This is up to the team to help other people understand that velocity/productivity is more than likely decrease as team dynamics change. Even if more people are put on a product, the velocity is expected to decrease as those people absorb new responsibilities. Same story for losing people on a product.
AnimalMuppet 8y ago
Sure, the team is dynamic. Smart agile people expect that changing the team will change the achievable velocity. Clueless "agile" people proceed as if nothing had changed. But that's not really an agile problem. You can have a waterfall-ish schedule, then the team changes, and management wants to keep the original dates. It's the same problem.

bsvalley 8y ago

I started working with agile since day one and it was fun back then. Why? Because it made projects so much more interesting. We were learning how to do things differently and it was pretty cool. Unfortunately, it became more popular and upper management started looking at the benefits of Agile. “Tell me one reason why we should adopt agile in our company?”. Unfortunately, a good answer to that was the ability to track the progress and a large increase in delivery and productivity. Teams hate those words but management love them. That’s what agile became today, tracking progress with constant status updates, charts and metrics that tell a team “clearly you did a really bad job this time” or “you’re late”. Management doesn’t even have to do the dirty job anymore. Meaningless meetings, less power for engineers, no creativity (ain’t got time for that!), etc. It went from a cool way to do things to a perfect tool for factories. No offense to factory workers.

JoeAltmaier 8y ago
And the illusion of getting things done, because tickets! makes it seem like progress is happening even if churn is all that's happening. Last contract (I left) was 6 years into churning the same awful pile of spaghetti. I came on board to help break the logjam. Micromanaging Agile manager put me on fire fighting, just like all his other reports, just like the last 6 years of churning had done. Left after 6 months and it was obvious they were going nowhere.
pjc50 8y ago
Exactly. Doing Agile properly requires a bi-directional mutually respectful communication between the development team and the product stakeholders. It's the complete opposite of traditional suspicion-based hierarchical management. That's why it has so much difficulty getting adopted.

da_murvel 8y ago

"... much of what is done is faux-agile, disregarding agile's values and principles." This. It feels so easy to get caught up in methods and tools, to not make a proper commitment (because it is tough to change the way you work) and to land in a sort of semi-agile state that no one likes.

lbriner 8y ago

Is there a problem in what we might call a meta-framework like agile in that it requires the "good people" that Martin Fowler talks about when the reality is that most of our teams are at least partially average? People have to learn examples of its implementation but are either not knowledgable enough or trusted enough to start doing things their own way, which causes the rigidity that everyone is talking about. That and the fact that tooling is not something that most people can knock up in a few days so we relay on the software and its somewhat rigid processes which means we aren't free to innovate fully anyway. It's a bit like complaining that most musicians only do music the way they learned at college and do not adapt to the "principles of music".

tnolet 8y ago

This whole discussion echoes the DevOps discussion and its definition. What DevOps is and what it means to different people is still hazy and can be twisted into anti-DevOps quite easily.

perlgeek 8y ago
It's even worse with DevOps, IMHO. Agile at least has the Manifesto of Agile Software Development, which you can go back to, and see if a given process adheres to the ideas in the manifesto. With DevOps, you have basically nothing foundational that people can agree on.

dandare 8y ago

Agile is like a religion. There is not a single consistent definition and any criticism is easily deflected along the lines that your organization did not embrace Agile on all levels of management. The uncomfortable truth is that Agile is internally inconsistent - you can not build an Agile methodology that will not contradict itself and that will not contradict the real world. A perfect example is the INVEST mnemonic for backlog items or the notion that Acceptance Criteria is against Agile. One Agile coach ($$$) recently told me that the fact that I have contractual requirements and legal requirements in AC that I need to test for is a symptom of my customers not being Agile and the government not being Agile.

codeulike 8y ago

I like to sneakily endorse people on LinkedIn with the 'Waterfall' skill tag.

venantius 8y ago

This article really hit home for me living in London. Having spent 7 years working in San Francisco and the valley, the degree to which "project management" and the use of buzzwords in the greater London tech scene are divorced from their original uses drives me absolutely bananas. And what's worse is that faux-agile has taken such a strong hold that I seem like the crazy person when I tell them that's not how software is developed in California.

mrfredward 8y ago
I live in the U.S. but I'm working remotely with a mainly U.K. based team that's doing "agile". The way they do it, at the end of a sprint all your tests have to pass, but it's normal for the trunk (yes we're using SVN) to be totally broken until then. That's all a sprint means to them, a block of time when it's okay for things to be broken. I think this company got into it's current predicament by buying a ticket tracker that uses the word "agile" and never learning anything about it beyond the words in the tracker. Needless to say, the current process isn't working very well.
himynameisdom 8y ago
I agree. It's amazing how many people on here are blaming the framework for their organization's implementation/interpretation of the framework. There's an insane amount of work going into discussions with people who've been burned by Dark Agile.

bullen 8y ago

https://news.ycombinator.com/item?id=16772788 https://news.ycombinator.com/item?id=16772788

mathw 8y ago

Four weeks ago my team changed from not-really-scrum-we're-just-pretending some some sort of kanban-like process, which was the first real change after I stuck an item on the wall during a retro which just said "Are we doing Scrum? Should we be?" Today we had a retro in which we talked about how things are going, and we're all more comfortable with how the process fits our actual workflow, and how it's opened up some other changes that have really helped us with getting useful stuff done, delivered and in the hands of people who appreciate it. And this came from within the team, entirely, with the support of our team lead. It's not perfect, but it's good, and we feel able to change things. That's why the other changes happened - because we were reminded that we have the power to change things, and the company actually genuinely believes that. There are some things we can't change, or not so easily, because they cross team boundaries or require money to be spent that we can't convince someone to authorise, but we have more freedom within the team than we had believed that we had. Largely I think because most of us are fairly new to the company and had long ago forgotten the idea of self-organising agile teams because the very concept was a joke most other places we've worked. I suspect we'll change things in the future, and we do have some concerns at the moment about how we split up big bits of work like implementing a completely new system component into cards of a suitable size and self-containedness and various other issues around definitions of done, but we'll work it out. For now, we're apparently more productive, we certainly feel more productive, and we're all happier because we don't have the entirely artificial pressure to ship something every sprint. That's not how the software we maintain works, and not how it should work either. We just ship stuff when it's ready, because that's what makes us and our stakeholders happy. What Fowler's describing is something I've seen so many times. Scrum-adherence is in itself something of a cult in some places, and it's done without any mindfulness for why you choose certain processes, the purpose of certain things and whether Scrum was a good choice for you or not. And I think honestly that's most people's experience of "agile" software development, because people have turned it into an industry of its own and with that comes the books, the rules, the certifications, and the legions of people who read a bit about it and decided that'd be great and it'd tick the trendy "agile" box without having to disrupt the company too much. Bleergh. Oh and something else my current employer does that I've seen literally nowhere else? A no-blame culture. We actually have one. I wish everyone could try it.

navane 8y ago

We're doing agile in a mechanical engineering firm. A multiyear project. The first thing we'll deliver will be two years from now. I struggle to put into words why this is such a bad idea because its so blatantly obvious. Imagine designing and building the golden gate bridge as an agile process.

mixmastamyk 8y ago
Agile process doesn't necessarily mean agile delivery. But I might worry too.

ggregoire 8y ago

So it’s probably an unpopular opinion on HN, but I’ve seen SCRUM implemented in 3 companies during my career and it has been an improvement for each one of them.

ryanmarsh 8y ago

Agile Coach here. FIRE YOUR AGILE COACHES The monstrosity that agile has become is an insult to the courageous pioneers who spoke out and swam against the current (at the time) to save software engineers from an overreaction to the growing complexity of computer systems. The result has been an overreaction to an overreaction. 1. MOST COACHES ARE MUPPETS Most Agile coaches today have a serious lack of engineering and leadership experience. They are merely the sum of the Agile classes they've attended and the book or two they may have skimmed. Most agile coaches do not understand the theoretical underpinnings of their field and therefore can only parrot statements from other "agile leaders". Most can't write code, have never managed anything as large as the groups they coach, don't understand software development in general, thus you would be a fool to take advice from them. Here's an example. A friend told me a story this week about a new coach who came in and pronounced that what they needed was "big room planning". He proclaimed this without having any context whatsoever. What is one to do when all one has is a hammer? This is not an anomaly, it's par for the course. 2. YOU'RE BETTER OFF IF YOU DO IT YOURSELF Today enough has been published about the dangers of approaching complex problems with the tools for solving merely complicated problems. You don't need a Priest of the All Mighty Agile to warn of you of Eternal Damnation and prescribe the One True Way. Every "tool" any agile coach can use to help you understand the challenges to production flow (such as Value Stream Mapping) can all be found in digestible articles on Medium. If you're having trouble finding these my email is in my bio. If you, as a leader, take the time to understand your chosen field of Software Engineering Leadership, and then... you know... actually lead, your organization will subsequently obtain the necessary habits to continue to change and improve as your company grows and changes. The value of this cannot be overstated. Most companies calling me for help today have anemic leadership and that's their problem. They don't need an expert in software delivery performance to help them skip some of the boilerplate, they need Extreme Ownership and true leadership. Instead they continue suckle on the tit of Agile Coaches 5-10 years into an "Agile Transformation" when they should be up on their own two legs walking and eating with a fork. Agile Coaches have, if anything become an enabler to the worst corporate cultures and mindless bureaucracies software engineers have ever had the displeasure to work under. 3. YOU CAN'T SHIP BECAUSE SOFTWARE DOESN'T MATTER Lastly, the reason most companies who struggle to increase quality and simultaneously increase delivery performance (aka Business Performance in 2018) is because they don't care about software. It is true, no one starts a bank to have an IT department. However some companies have awoken to the fact that in 2018 TECHNOLOGY PERFORMANCE IS BUSINESS PERFORMANCE. If you are not one of these companies you (personally) have two choices, go and work for one, or lead your company to become one. The alternative is... a steady paycheck? Even in the most laggardly industries, leaders are waking up to the fact that getting technology performance right is the only competitive angle. When these clients call me the things we accomplish are breathtaking. Sadly, they are a tiny minority. Most companies call coaches so a VP can show he's checking all the boxes, so they can continue with the status quo. Some financial institutions may talk about the danger of "Fin tech startups" but when you have enough in assets that you can coast for 50 years, or you have billions in infrastructure that a competitor with all the money in the world couldn't replace inside of a decade, the reality is SOFTWARE DOESN'T MATTER. You can suck as much as you want because the challengers are so incredibly far off it really doesn't matter. These places make Agile Coaches lots of money and they're also the ones who fill the conferences. Technology performance doesn't really matter at these companies. This is why you (who work in these companies) struggle to have a sane build pipeline, adequate test coverage with good tests, communication across teams, and you get nowhere. You're swimming against a tsunami. It's exhausting, don't waste your time. Find somewhere that actually sees the leverage technology can provide them and go work there. You'll be a hero.

borvo 8y ago

"this realization that people are operating at the best when they choose how they want to work" But what if how they want to work is "Dark Scrum"... or some kind of Agile religion, or waterfall.