11 ms·

My first team, some 14 years ago, had the best experience with Agile. What made this work > During planning, everyone understood that the estimates were _esti

by plughs 6y ago

My first team, some 14 years ago, had the best experience with Agile. What made this work > During planning, everyone understood that the estimates were _estimates_. Tasks could take longer or shorter, that was OK and even expected. The goal was to improve velocity, not to accomplish every story, every time. > Engineers felt comfortable taking stories in areas they knew nothing about. A stated goal was that every engineer understand every piece of the project. > Standups were team only. Engineers felt comfortable saying they got stuck or needed help or got lost in a rathole and didn't make the progress they hoped. > Demos were important so that the team and the clients could understand what had changed and what new features were available. But it quickly got lost - managers and PMs and Directors got involved and Jira boards became published for all to see. (In the beginning it was whiteboards and sticky note). Standups and Demos were all about self-promotion. No one ever wanted to take on a task they weren't 100% certain they could do. If a task was 3 point it needed to be done in 3 days or there would be questions. When I left the last company it had gotten outrageous. Every task should be completed in three days and in production in five days - and if not that team was Doing Something Wrong. ( We were told that this was standard FAANG practice, I have no idea how true that was ) What happened was what you'd expect - shortcuts, tech debt, unit tests cynically design to pass and meet code coverage expectations instead of actually usefully testing. The reality is that any process is going to fail one senior leadership decides it's a way to evaluate engineers, not create a good product.

wpietri 6y ago
Totally. "When a measure becomes a target, it ceases to be a good measure. https://en.wikipedia.org/wiki/Goodhart%27s_law https://en.wikipedia.org/wiki/Goodhart%27s_law And as you say, managerial involvement is the problem. Managers and execs mostly get paid to appear to be in control, so having the appearance of control is vital to them, even if that makes the results wildly worse.
- brightball 6y ago
  That is one of the all time best quotes that nobody is willing to hear.
  - wpietri 6y ago
    Which reminds me of one of the other great quotes: "It is difficult to get a man to understand something when his salary depends upon his not understanding it."
  - jay_kyburz 6y ago
    Actually, I think its dumb. A better saying would be, you should only use your target as a measure. If your target is working software, measure how well the software works.
    - wpietri 6y ago
      I don't think you quite get this. In your imaginary case, what would your specific numerical measure be?
- mavelikara 6y ago
  "We are not doing it like the FAANG companies" is a refrain you get from engineers themselves too.
  - goostavos 6y ago
    Surely uttered by people who haven't been at FAANG companies. It's not magical over here, people. I've legit sat through 1.5 hour long calls with 6 other devs so we could watch our manager type notes into a presentation that he'll give to a collection of other managers who will only be half-listening until it's their turn to be visible, and all because some other, more powerful manager, decided this was important for the org to do. It was layers of bureaucracy so deep I wasn't sure where I was anymore.
- Roboprog 6y ago
  Like measuring nitrogen content as a proxy for protein?
  - dkbrk 6y ago
    Exactly, then unscrupulous people adulterate it with melamine to artificially boost measured protein.
timwis 6y ago
Really insightful. Thanks for sharing.
marktangotango 6y ago
A looong time ago I went through Army basic training. As a BS degree holder I was given the job of "book man". This meant I carried around the platoon training book and carried placards to put in signs at various training locations that told what battalion, company, and platoon we were so if anyone driving by a gun range, motor pool, or classroom could look and see oh that's 1st platoon, C company, 1st training battalion. I've come to believe that that main driver for Agile adoption has come to be something similar. Making visible to outsiders what software development teams are doing, and making progress (or it's lack) visible to management. I thinks that's a completely reasonable expectation. Businesses are paying exorbitant salaries and providing ping pong tables, why shouldn't they have visibility into what's being done? Where it becomes toxic is in areas this posts parent indicates; posturing, one upsmanship, pressure to perform. Effective teams need "safe spaces" to learn, discover, try and fail. Agile isn't that anymore. Hasn't been for a long time.
- plughs 6y ago
  There are certainly good reasons to make a team's progress visible. PMs/POs ( I'm never sure of the difference ) will want to know if a project can meet the release date. They will want to know that the need-to-have features are being worked on before the nice-to-have. I don't want to sat a team should work in total isolation. I can only say that IME a team is going to be a lot more productive if they are able to own their development process. Good infrastructure, knowledgeable engineers, healthy relationships instead of competitive ones - that's what creates a highly productive team and highly productive engineers.
  - lonelappde 6y ago
    > will want to know if a project can meet the release date The number one main headline takeway axiom of Agile is that this question is completely banned. Agile is about delivering working software continuously, delivering whatever increment you get working at each timepoint, adapting to observed reality as it comes, and not having deadlines for specific features that might turn out to be impossible or harder than estimated.
hinkley 6y ago
> Engineers felt comfortable taking stories in areas they knew nothing about. and it was understood and expected that this meant the estimate would go up Today we have 'bidding', which if that sounds like something a three year old does to their parents, you'd be right, and it's the same thing. You just ask someone else until you get the answer you want to hear (instead of the one you need to hear).
- Supermancho 6y ago
  > you'd be right, and it's the same thing. It's not the same thing. It's not "bidding", even if it's called that because the lowest or highest or middling bid doesn't necessarily get the work. I know, I know, it sounds like another "you're doing Agile wrong", but Agile already fucked it up by saying "bidding", so we get these wild stories of how companies have their laziest incompetents in charge of trying to make improvements to process. > You just ask someone else until you get the answer you want to hear (instead of the one you need to hear). Otherwise you will only have the most jr or senior people working on everything. The system of bidding just doesn't work, which is why it's not bidding in a practical sense. You ask why people put down their estimates by describing what they know about the work. This is an opportunity to transfer some cursory knowledge and reinforce pain points. At a very progressive "Agile" company (we would invite speakers and A/B tested various practices across teams), I notoriously inflated/deflated all estimates by bringing up edge cases and/or constraining objectives. Story grooming aside, there are always people trying to over-engineer and estimation is another gate to prevent that. Agile was a good try to create software process, but it's incomplete at best. The idea that it would evolve is laughably naiive (https://app.spectator.co.uk/2020/04/22/the-illusion-of-certainty/content.html https://app.spectator.co.uk/2020/04/22/the-illusion-of-certa...). Companies want S&Ps, not sauce that they have to mix themselves.
  - hinkley 6y ago
    I'm not talking about Planning Poker, per se. I'm talking about the dickering about whether something is N points or N-2 points. Or whether the points even mean the same between two teams. Or whether it's appropriate to assign it to another team or individual who says a smaller number because they have a different definition of Done or are more or less invested in the long-term health of the project. I'm going to ask this person or the question in this way because I'll get the answer I like, even if that answer is unhealthy or even pure fiction.
analyst74 6y ago
I agree with what you say in principle, but just to play devil's advocate. One difference between those highly paid software companies and others, is the expectation of performance. Netflix famously considers their team a sports team rather than a typical corporation. It's totally common for a great engineer to bomb out of those companies, just like how great athletes get kicked off top tier sports teams when they failed to perform due to reasons out of their control. While most other companies, lacking the ability or willingness to pay top dollars, are probably better off creating a safe environment for engineers who can be on-par or even better than FAANG engineers, but lack the political maturity to survive those high pressure environment.
- lonelappde 6y ago
  N's philosophy is famous because it's NOT how FAAG operate.
Zelphyr 6y ago
> We were told that this was standard FAANG practice I'm getting really tired of companies trotting out the "because [Facebook|Apple|Google] does it" excuse. Those are massive companies. Are we so delusional to believe that what works for a $70B/year company will automatically work for our $20MM/year company?
- lonelappde 6y ago
  Spoiler alert: it's not how FAANG operate. The idea that FAANG are faster then your startup is absurd on its face. The revenue and legal risk is absolutely huge.
  - joejerryronnie 6y ago
    The idea that all dev teams within a single FAANG operate in the same manner is also absurd (much less that all dev teams across all FAANGs operate in some identical, optimal fashion).
    - deleted 6y ago
      [deleted]
    - saagarjha 6y ago
      Finally, the idea that you should blindly emulate FAANG because they’ve clearly thought through what is the best is also absurd. They make poor, short-sighted choices too.
  - mkhpalm 6y ago
    Its never made much sense to me when people hinge their beliefs on entities that have to acquire little companies to round out their portfolios.
- plughs 6y ago
  The craziest part of this was that it was banking software. Every so often someone would inadvisedly suggest that banking customers weren't waiting on the edge of their seats for new features and really really really disliked bugs. Perhaps - the hapless engineer would suggest - companies like facebook weren't the greatest model for how our company should operate. It was a good way to get your head bitten off.
BurningFrog 6y ago
This reminds me why the agile "customer" concept is so important. As a customer, you get to decide what you want to buy, and you get to be happy or unhappy with the delivered product. But you don't get to control or even monitor the work in the factory/kitchen/etc. That's instead the job of a boss! Of course, an agile team also has a boss. But it's not the customer.
- einpoklum 6y ago
  Isn't it the case the most places "doing agile" don't actually involve the eventual customer in the process, just junior and higher management?
  - BurningFrog 6y ago
    If you can find an end customer that's willing to do the work, you're very lucky. But usually some proxy for the customer in your organization has to take on that role.
  - tootie 6y ago
    That's the point of this article, but honestly it seems to be neither here nor there. Being disconnected from business goals happens with or without agile. Agile can only solve delivery problems, not defects in business strategy.
- jay_kyburz 6y ago
  It's not that customers don't "get to". It's more that customers don't "have to" because they can see working software coming out of the team, and they are confident that things are progressing. There are no "rules" in agile that says who can do what, just teams of people negotiating what works best for them. "Individuals and interactions" over process.
  - BurningFrog 6y ago
    Well, I'm saying that the team needs to insist on those boundaries, to keep the relationships healthy. Not claiming it's inscribed on some sacred tablet.
janee 6y ago
> it's a way to evaluate engineers, not create a good product. Gonna play devils advocate here...would those two be mutually exclusive? I feel there's a fundamental flaw in the garden of agile eden you initially described and that's trust...if you don't have it or lose it then gl trying to convince someone to essentially write a blank cheque for something they don't understand If trust can erode a whole methodology then it's something to consider imo
lliamander 6y ago
In my experience, every successful engineering process is driven by the engineers. Not product owners, project managers, IT directors, VPs of Engineering, or CTOs. It's certainly reasonable for those various stakeholders to ask for visibility. Demos are great for that, and a lead engineer or front-line engineering manager can work with stakeholders to establish some metrics to report on, but those are epiphenomenal to the process chosen. I'm not saying it's a guarantee, just that nothing else really works well.
mcv 6y ago
All of that is corruption of the idea. Probably common, but unnecessary and really needs to the fought against. The primary point of Agile is to empower developers. If management is determined to micromanage them anyway, then Agile is pointless. If the term Agile is to have any business value at all, then let it be the stick with which developers beat some sense into stupid managers. Points are indeed rough estimates and can easily be off by a large factor, and they're definitely not meant to measure performance. Standups are about the team and about helping each other move forward. Demos are about getting feedback from stakeholders. It's fine if others see the Jira board, but it's not theirs. It's the developers'. And if a task isn't done, and it isn't done. I fight for this if necessary, but fortunately I'm currently working in a team of very vocal and opinionated developers who take charge of their project and push back against managers if necessary. We do Scrum, but we're not dogmatic about it. We change the sprint scope if the situation calls for it. And we rebel when it's management that's calling for it.
artsyca 6y ago
This has a lot to do with putting processes over people and it's been a lengthy process of us as so called engineers getting our hands forced while maintaining an appearance of being cool and entitled It's well known that the systems an organization produces are bound to reflect the communications structures within that organization this is known as Conway's principle In order to maintain flexibility in the design it's necessary to maintain flexibility in communication but engineers have no incentive to push for free communication and stick together to see the job done right, each of them is attached to a management minder who reports to a rigid top-down governance structure with very different ideas on how software should be done, effectively stifling any potential dissent at the source and acting like an authoritarian regime with the desire to divorce the workers from ownership of their work and turn them into compliant and productive cogs in the machine The reason for this is not because corporacy sucks but because humans suck at corporacy and when placed in group environments of over a handful of people we tend to resort to mob rule and groupthink at the expense of culture and individual rights It's rather complex but incentives are the clearest indicator of outcomes people simply have no incentives to help each other but every incentive to seek permission and recognition from management In such an environment it's been postulated that four types of personalities emerge as people attempt to exert control and these are known as Control Dramas: - The Intimidator - The Interrogator - The Aloof and - The Poor Me You can look these up there are several good articles online about identifying and mitigating these but it's not always just one but a combination that people exhibit Framed in this context you can see corporations as implemented naively operate on only four cylinders even if it's only figuratively or intuitively true it's far from the humane ideal of what agile intended and this also has to do with metrics becoming targets and incentives trumping ethics In the end we trumpet DRY and try to 'focus on our work' while we repeat the same inane insane dramas day after day expecting a different outcome that's the worst form of repeating yourself but we collectively walk into it in every case I'm personally carrying a lot of resentment at the engineer class because we've been trained to know better but we simply can't get over ourselves and wake up to the fact that we're not just part of the problem, we are the problem but as such we also possess the solution if we really sit down and think about it The solution lies in the following concepts A) it's possible to have alignment and autonomy it's not necessary to choose between chaos and blind compliance B) It's possible to have investment and productivity but it's necessary to trust people and that ultimately is where we fail
mattlondon 6y ago
Amen. We should make "estimate" a banned word and replace it with a word like "guess". Too often what starts out with an off-the-cuff chat about implementing some feature while people are getting coffee with a statement like "Oh I don't think it will be too hard to do this - will take a week tops <filddles with coffee machine />" etc ends up growing its own legs and becomming a gold-plated and irreversible commitment made to a director/VP/CxO somehow. What was a casual guess made without all the information required is now a rod for.our own back. Again. Perhaps as engineers we should give ourselves a sort of mental style-guide to never ever say the words hours/days/weeks/months/quarters/etc without alarm bells going off in our head and requiring extensive peer review in the same way we do when we're writing "dangerous" code (e.g. user-provided values going in to SQL queries etc) Only half joking really :)
- darekkay 6y ago
  I've tried replacing "commitment" with "forecast" in my team for the same reason. Even though it's an official recommendation [1], the management didn't like it. [1] https://www.scrum.org/resources/blog/commitment-versus-forecast https://www.scrum.org/resources/blog/commitment-versus-forec...
blntechie 6y ago
This is my experience with Agile projects. All the good parts for the developers have been stripped out and all it remains are the parts which benefits the management. How it’s followed in most orgs, it’s a low key leash system mostly however harsh it is to say.
freshhawk 6y ago
People in middle management are often quite smart. They saw a process that did an end run around them in favour of more self-management, and it worked well and got a lot of hype, that's terrible for their careers obviously. So they fixed it and kept the same name for marketing.
tootie 6y ago
I disagree with one bit. We always have our boards as public as possible. I think one of the main selling points of following a product backlog is the visibility it grants to stakeholders. You can point to stories in the queue and what acceptance criteria was agreed to. And they can see and adjust the priority order of tasks to be done. And see when stories are in a demo-ready state. Estimates are an interesting one. The theory of story point estimation is that you are estimating the size of the work being and not even implying, let along guaranteeing any notion of timing. That being said, it's still sometimes a valid question to ask why something is taking so long.
drawkbox 6y ago
Projects that involve value creation contain "open" and "closes" modes. Any process that squashes the "open" mode and only has "closed" modes will stagnate, fail or acquire technical/creative/product debt. A great talk that I make everyone watch is John Cleese on Creativity In Management, it is a must watch for value extractors dealing with value creation that ultimately is creative work [1][2]. The open mode is allowing space, time and confidence. Closed mode is finishing/ship it mode. "CLOSED" MODE > By the "closed mode" I mean the mode that we are in most of the time when {we are} at work. > We have inside us a feeling that there's lots to be done and we have to get on with it if we're going to get through it all. > It's an active (probably slightly anxious) mode, although the anxiety can be exciting and pleasurable. > It's a mode which we're probably a little impatient, if only with ourselves. > It has a little tension in it, not much humor. > It's a mode in which we're very purposeful, and it's a mode in which we can get very stressed and even a bit manic, but not creative. "OPEN" MODE > The open mode, is relaxed… expansive… less purposeful mode… in which we're probably more contemplative, more inclined to humor (which always accompanies a wider perspective) and, consequently, more playful. > It's a mood in which curiosity for its own sake can operate because we're not under pressure to get a specific thing done quickly. We can play, and that is what allows our natural creativity to surface. ... > Humor is a natural concomitant in the open mode, but it's a luxury in the closed {mode}. COMBINING OPEN and CLOSED MODE > Once we've taken a decision we should narrow our focus while we're implementing it, and then after it's been carried out we should once again switch back to the open mode to review the feedback rising from our action, in order to decide whether the course that we have taken is successful, or whether we should continue with the next stage of our plan. Whether we should create an alternative plan to correct any error we perceive. > And then back into the closed mode to implement that next stage, and so on. EXAMPLE > ...one of Alfred Hitchcock's regular co-writers has described working with him on screenplays. > He says, "When we came up against a block and our discussions became very heated and intense, Hitchcock would suddenly stop and tell a story that had nothing to do with the work at hand. At first, I was almost outraged, and then I discovered that he did this intentionally. He mistrusted working under pressure. He would say "We're pressing, we're pressing, we're working too hard. Relax, it will come." And, says the writer, of course it finally always did. We need both modes. The world is value creators (product/engineer/creative/imagination) and value extractors (business/management/finance). Once the latter group get control, they end up squashing the "open" mode that is so key to making good products. The value extractors increase pressure but sometimes lowering pressure will let the product iterations flow to a better product end result. Value must be created first before value can be extracted, but you can't force value creation with only the "closed" mode. Value creation processes that make sure there is an "open" mode along with the "closed" mode are always more successful, and sometimes the "open" mode doesn't look like work so the value extractors cut it first unknowingly killing the product slowly. The wrong type of Agile removes the "open" mode and cuts prototyping, iterations and refinement of creative value creation. A more open type of iterative development is always better. [1] https://www.youtube.com/watch?v=Pb5oIIPO62g https://www.youtube.com/watch?v=Pb5oIIPO62g [2] https://genius.com/John-cleese-lecture-on-creativity-annotated https://genius.com/John-cleese-lecture-on-creativity-annotat...
mgreenleaf 6y ago
Most philosophies get badly diluted and warped after they get placed into a wider audience. A lot of good ideas come from a small group of competent individuals who have experience and think deeply about how they could improve things; but a major reason why so much of the world is still so dysfunctional is because so many people don't think deeply or carefully about what they are doing. So when a good idea comes along, they commit the old mistake of jumping on the bandwagon without deeply imbibing the real reasoning behind it, but that corrupts the idea over time to be a prescriptive cure. So we have fads every few years when the majority of people find out that the old silver bullet didn't work for them, and start looking for a new silver bullet-- and there is always another small group who want to improve things and write a new book with a slightly different take on how to do so.
jerzyt 6y ago
I think that Jira killed Agile. It's such an overhead on the Agile process. Engineers spend more time documenting stuff in Jira than actually solving problems.
- m0xte 6y ago
  Crawled into this thread to make the same comment. It’s implicit vs explicit. JIRA makes everything so explicit it hurts
- heisenbit 6y ago
  Jira is only a tool. You can use it for reasonable lightweight communication. Or you can use it as a basis for defensive posturing, preparing for financial change discussions and control freakish micromanagement. If you have a distributed team and can keep management out of it and stick to basic features Jira can help still today. Agile is about culture and the culture of the pioneers and early adopters was different. I‘m seriously thinking I should try to go more the Kanban direction these days to aboid the story point hitting / fitting in ever shrinking sprint trend.
- constantine42 6y ago
  Jira can be highly customized. I find it easy to use for day-to-day. I also have to deal with Jira with a subsidiary company, and their Jira is completely different, but it works well for their use case. The reporting is a whole other issue. I don't use this, but my PM does because upper management keeps changing their reports and my PM has to keep linking and organizing. But as a developer, doing spring planning and burndown charts work quite nicely.
wobbleblob 6y ago
You forgot the part where the product owner negotiates the number of story points down for every story, and negotiates up the number of sp in every sprint, and complains that the team gets a velocity of exactly 50% every single sprint.
PeterStuer 6y ago
If you do not change the power dynamics in companies, then the exposure of agile will rapidly descend into micro=management, metrics gaming, pass the hot potato and self promotion.
zubairq 6y ago
I wish I could +1000 this. "Standups and Demos were all about self-promotion"

by plughs 6y ago

wpietri 6y ago

Totally. "When a measure becomes a target, it ceases to be a good measure. https://en.wikipedia.org/wiki/Goodhart%27s_law https://en.wikipedia.org/wiki/Goodhart%27s_law And as you say, managerial involvement is the problem. Managers and execs mostly get paid to appear to be in control, so having the appearance of control is vital to them, even if that makes the results wildly worse.

brightball 6y ago
That is one of the all time best quotes that nobody is willing to hear.
- wpietri 6y ago
  Which reminds me of one of the other great quotes: "It is difficult to get a man to understand something when his salary depends upon his not understanding it."
- jay_kyburz 6y ago
  Actually, I think its dumb. A better saying would be, you should only use your target as a measure. If your target is working software, measure how well the software works.
  - wpietri 6y ago
    I don't think you quite get this. In your imaginary case, what would your specific numerical measure be?
mavelikara 6y ago
"We are not doing it like the FAANG companies" is a refrain you get from engineers themselves too.
- goostavos 6y ago
  Surely uttered by people who haven't been at FAANG companies. It's not magical over here, people. I've legit sat through 1.5 hour long calls with 6 other devs so we could watch our manager type notes into a presentation that he'll give to a collection of other managers who will only be half-listening until it's their turn to be visible, and all because some other, more powerful manager, decided this was important for the org to do. It was layers of bureaucracy so deep I wasn't sure where I was anymore.
Roboprog 6y ago
Like measuring nitrogen content as a proxy for protein?
- dkbrk 6y ago
  Exactly, then unscrupulous people adulterate it with melamine to artificially boost measured protein.

timwis 6y ago

Really insightful. Thanks for sharing.

marktangotango 6y ago

A looong time ago I went through Army basic training. As a BS degree holder I was given the job of "book man". This meant I carried around the platoon training book and carried placards to put in signs at various training locations that told what battalion, company, and platoon we were so if anyone driving by a gun range, motor pool, or classroom could look and see oh that's 1st platoon, C company, 1st training battalion. I've come to believe that that main driver for Agile adoption has come to be something similar. Making visible to outsiders what software development teams are doing, and making progress (or it's lack) visible to management. I thinks that's a completely reasonable expectation. Businesses are paying exorbitant salaries and providing ping pong tables, why shouldn't they have visibility into what's being done? Where it becomes toxic is in areas this posts parent indicates; posturing, one upsmanship, pressure to perform. Effective teams need "safe spaces" to learn, discover, try and fail. Agile isn't that anymore. Hasn't been for a long time.

plughs 6y ago
There are certainly good reasons to make a team's progress visible. PMs/POs ( I'm never sure of the difference ) will want to know if a project can meet the release date. They will want to know that the need-to-have features are being worked on before the nice-to-have. I don't want to sat a team should work in total isolation. I can only say that IME a team is going to be a lot more productive if they are able to own their development process. Good infrastructure, knowledgeable engineers, healthy relationships instead of competitive ones - that's what creates a highly productive team and highly productive engineers.
- lonelappde 6y ago
  > will want to know if a project can meet the release date The number one main headline takeway axiom of Agile is that this question is completely banned. Agile is about delivering working software continuously, delivering whatever increment you get working at each timepoint, adapting to observed reality as it comes, and not having deadlines for specific features that might turn out to be impossible or harder than estimated.

hinkley 6y ago

> Engineers felt comfortable taking stories in areas they knew nothing about. and it was understood and expected that this meant the estimate would go up Today we have 'bidding', which if that sounds like something a three year old does to their parents, you'd be right, and it's the same thing. You just ask someone else until you get the answer you want to hear (instead of the one you need to hear).

Supermancho 6y ago
> you'd be right, and it's the same thing. It's not the same thing. It's not "bidding", even if it's called that because the lowest or highest or middling bid doesn't necessarily get the work. I know, I know, it sounds like another "you're doing Agile wrong", but Agile already fucked it up by saying "bidding", so we get these wild stories of how companies have their laziest incompetents in charge of trying to make improvements to process. > You just ask someone else until you get the answer you want to hear (instead of the one you need to hear). Otherwise you will only have the most jr or senior people working on everything. The system of bidding just doesn't work, which is why it's not bidding in a practical sense. You ask why people put down their estimates by describing what they know about the work. This is an opportunity to transfer some cursory knowledge and reinforce pain points. At a very progressive "Agile" company (we would invite speakers and A/B tested various practices across teams), I notoriously inflated/deflated all estimates by bringing up edge cases and/or constraining objectives. Story grooming aside, there are always people trying to over-engineer and estimation is another gate to prevent that. Agile was a good try to create software process, but it's incomplete at best. The idea that it would evolve is laughably naiive (https://app.spectator.co.uk/2020/04/22/the-illusion-of-certainty/content.html https://app.spectator.co.uk/2020/04/22/the-illusion-of-certa...). Companies want S&Ps, not sauce that they have to mix themselves.
- hinkley 6y ago
  I'm not talking about Planning Poker, per se. I'm talking about the dickering about whether something is N points or N-2 points. Or whether the points even mean the same between two teams. Or whether it's appropriate to assign it to another team or individual who says a smaller number because they have a different definition of Done or are more or less invested in the long-term health of the project. I'm going to ask this person or the question in this way because I'll get the answer I like, even if that answer is unhealthy or even pure fiction.

analyst74 6y ago

I agree with what you say in principle, but just to play devil's advocate. One difference between those highly paid software companies and others, is the expectation of performance. Netflix famously considers their team a sports team rather than a typical corporation. It's totally common for a great engineer to bomb out of those companies, just like how great athletes get kicked off top tier sports teams when they failed to perform due to reasons out of their control. While most other companies, lacking the ability or willingness to pay top dollars, are probably better off creating a safe environment for engineers who can be on-par or even better than FAANG engineers, but lack the political maturity to survive those high pressure environment.

lonelappde 6y ago
N's philosophy is famous because it's NOT how FAAG operate.

Zelphyr 6y ago

> We were told that this was standard FAANG practice I'm getting really tired of companies trotting out the "because [Facebook|Apple|Google] does it" excuse. Those are massive companies. Are we so delusional to believe that what works for a $70B/year company will automatically work for our $20MM/year company?

lonelappde 6y ago
Spoiler alert: it's not how FAANG operate. The idea that FAANG are faster then your startup is absurd on its face. The revenue and legal risk is absolutely huge.
- joejerryronnie 6y ago
  The idea that all dev teams within a single FAANG operate in the same manner is also absurd (much less that all dev teams across all FAANGs operate in some identical, optimal fashion).
  - deleted 6y ago
    [deleted]
  - saagarjha 6y ago
    Finally, the idea that you should blindly emulate FAANG because they’ve clearly thought through what is the best is also absurd. They make poor, short-sighted choices too.
- mkhpalm 6y ago
  Its never made much sense to me when people hinge their beliefs on entities that have to acquire little companies to round out their portfolios.
plughs 6y ago
The craziest part of this was that it was banking software. Every so often someone would inadvisedly suggest that banking customers weren't waiting on the edge of their seats for new features and really really really disliked bugs. Perhaps - the hapless engineer would suggest - companies like facebook weren't the greatest model for how our company should operate. It was a good way to get your head bitten off.

BurningFrog 6y ago

This reminds me why the agile "customer" concept is so important. As a customer, you get to decide what you want to buy, and you get to be happy or unhappy with the delivered product. But you don't get to control or even monitor the work in the factory/kitchen/etc. That's instead the job of a boss! Of course, an agile team also has a boss. But it's not the customer.

einpoklum 6y ago
Isn't it the case the most places "doing agile" don't actually involve the eventual customer in the process, just junior and higher management?
- BurningFrog 6y ago
  If you can find an end customer that's willing to do the work, you're very lucky. But usually some proxy for the customer in your organization has to take on that role.
- tootie 6y ago
  That's the point of this article, but honestly it seems to be neither here nor there. Being disconnected from business goals happens with or without agile. Agile can only solve delivery problems, not defects in business strategy.
jay_kyburz 6y ago
It's not that customers don't "get to". It's more that customers don't "have to" because they can see working software coming out of the team, and they are confident that things are progressing. There are no "rules" in agile that says who can do what, just teams of people negotiating what works best for them. "Individuals and interactions" over process.
- BurningFrog 6y ago
  Well, I'm saying that the team needs to insist on those boundaries, to keep the relationships healthy. Not claiming it's inscribed on some sacred tablet.

janee 6y ago

> it's a way to evaluate engineers, not create a good product. Gonna play devils advocate here...would those two be mutually exclusive? I feel there's a fundamental flaw in the garden of agile eden you initially described and that's trust...if you don't have it or lose it then gl trying to convince someone to essentially write a blank cheque for something they don't understand If trust can erode a whole methodology then it's something to consider imo

lliamander 6y ago

In my experience, every successful engineering process is driven by the engineers. Not product owners, project managers, IT directors, VPs of Engineering, or CTOs. It's certainly reasonable for those various stakeholders to ask for visibility. Demos are great for that, and a lead engineer or front-line engineering manager can work with stakeholders to establish some metrics to report on, but those are epiphenomenal to the process chosen. I'm not saying it's a guarantee, just that nothing else really works well.

mcv 6y ago

All of that is corruption of the idea. Probably common, but unnecessary and really needs to the fought against. The primary point of Agile is to empower developers. If management is determined to micromanage them anyway, then Agile is pointless. If the term Agile is to have any business value at all, then let it be the stick with which developers beat some sense into stupid managers. Points are indeed rough estimates and can easily be off by a large factor, and they're definitely not meant to measure performance. Standups are about the team and about helping each other move forward. Demos are about getting feedback from stakeholders. It's fine if others see the Jira board, but it's not theirs. It's the developers'. And if a task isn't done, and it isn't done. I fight for this if necessary, but fortunately I'm currently working in a team of very vocal and opinionated developers who take charge of their project and push back against managers if necessary. We do Scrum, but we're not dogmatic about it. We change the sprint scope if the situation calls for it. And we rebel when it's management that's calling for it.

artsyca 6y ago

This has a lot to do with putting processes over people and it's been a lengthy process of us as so called engineers getting our hands forced while maintaining an appearance of being cool and entitled It's well known that the systems an organization produces are bound to reflect the communications structures within that organization this is known as Conway's principle In order to maintain flexibility in the design it's necessary to maintain flexibility in communication but engineers have no incentive to push for free communication and stick together to see the job done right, each of them is attached to a management minder who reports to a rigid top-down governance structure with very different ideas on how software should be done, effectively stifling any potential dissent at the source and acting like an authoritarian regime with the desire to divorce the workers from ownership of their work and turn them into compliant and productive cogs in the machine The reason for this is not because corporacy sucks but because humans suck at corporacy and when placed in group environments of over a handful of people we tend to resort to mob rule and groupthink at the expense of culture and individual rights It's rather complex but incentives are the clearest indicator of outcomes people simply have no incentives to help each other but every incentive to seek permission and recognition from management In such an environment it's been postulated that four types of personalities emerge as people attempt to exert control and these are known as Control Dramas: - The Intimidator - The Interrogator - The Aloof and - The Poor Me You can look these up there are several good articles online about identifying and mitigating these but it's not always just one but a combination that people exhibit Framed in this context you can see corporations as implemented naively operate on only four cylinders even if it's only figuratively or intuitively true it's far from the humane ideal of what agile intended and this also has to do with metrics becoming targets and incentives trumping ethics In the end we trumpet DRY and try to 'focus on our work' while we repeat the same inane insane dramas day after day expecting a different outcome that's the worst form of repeating yourself but we collectively walk into it in every case I'm personally carrying a lot of resentment at the engineer class because we've been trained to know better but we simply can't get over ourselves and wake up to the fact that we're not just part of the problem, we are the problem but as such we also possess the solution if we really sit down and think about it The solution lies in the following concepts A) it's possible to have alignment and autonomy it's not necessary to choose between chaos and blind compliance B) It's possible to have investment and productivity but it's necessary to trust people and that ultimately is where we fail

mattlondon 6y ago

Amen. We should make "estimate" a banned word and replace it with a word like "guess". Too often what starts out with an off-the-cuff chat about implementing some feature while people are getting coffee with a statement like "Oh I don't think it will be too hard to do this - will take a week tops <filddles with coffee machine />" etc ends up growing its own legs and becomming a gold-plated and irreversible commitment made to a director/VP/CxO somehow. What was a casual guess made without all the information required is now a rod for.our own back. Again. Perhaps as engineers we should give ourselves a sort of mental style-guide to never ever say the words hours/days/weeks/months/quarters/etc without alarm bells going off in our head and requiring extensive peer review in the same way we do when we're writing "dangerous" code (e.g. user-provided values going in to SQL queries etc) Only half joking really :)

darekkay 6y ago
I've tried replacing "commitment" with "forecast" in my team for the same reason. Even though it's an official recommendation [1], the management didn't like it. [1] https://www.scrum.org/resources/blog/commitment-versus-forecast https://www.scrum.org/resources/blog/commitment-versus-forec...

blntechie 6y ago

This is my experience with Agile projects. All the good parts for the developers have been stripped out and all it remains are the parts which benefits the management. How it’s followed in most orgs, it’s a low key leash system mostly however harsh it is to say.

freshhawk 6y ago

People in middle management are often quite smart. They saw a process that did an end run around them in favour of more self-management, and it worked well and got a lot of hype, that's terrible for their careers obviously. So they fixed it and kept the same name for marketing.

tootie 6y ago

I disagree with one bit. We always have our boards as public as possible. I think one of the main selling points of following a product backlog is the visibility it grants to stakeholders. You can point to stories in the queue and what acceptance criteria was agreed to. And they can see and adjust the priority order of tasks to be done. And see when stories are in a demo-ready state. Estimates are an interesting one. The theory of story point estimation is that you are estimating the size of the work being and not even implying, let along guaranteeing any notion of timing. That being said, it's still sometimes a valid question to ask why something is taking so long.

drawkbox 6y ago

Projects that involve value creation contain "open" and "closes" modes. Any process that squashes the "open" mode and only has "closed" modes will stagnate, fail or acquire technical/creative/product debt. A great talk that I make everyone watch is John Cleese on Creativity In Management, it is a must watch for value extractors dealing with value creation that ultimately is creative work [1][2]. The open mode is allowing space, time and confidence. Closed mode is finishing/ship it mode. "CLOSED" MODE > By the "closed mode" I mean the mode that we are in most of the time when {we are} at work. > We have inside us a feeling that there's lots to be done and we have to get on with it if we're going to get through it all. > It's an active (probably slightly anxious) mode, although the anxiety can be exciting and pleasurable. > It's a mode which we're probably a little impatient, if only with ourselves. > It has a little tension in it, not much humor. > It's a mode in which we're very purposeful, and it's a mode in which we can get very stressed and even a bit manic, but not creative. "OPEN" MODE > The open mode, is relaxed… expansive… less purposeful mode… in which we're probably more contemplative, more inclined to humor (which always accompanies a wider perspective) and, consequently, more playful. > It's a mood in which curiosity for its own sake can operate because we're not under pressure to get a specific thing done quickly. We can play, and that is what allows our natural creativity to surface. ... > Humor is a natural concomitant in the open mode, but it's a luxury in the closed {mode}. COMBINING OPEN and CLOSED MODE > Once we've taken a decision we should narrow our focus while we're implementing it, and then after it's been carried out we should once again switch back to the open mode to review the feedback rising from our action, in order to decide whether the course that we have taken is successful, or whether we should continue with the next stage of our plan. Whether we should create an alternative plan to correct any error we perceive. > And then back into the closed mode to implement that next stage, and so on. EXAMPLE > ...one of Alfred Hitchcock's regular co-writers has described working with him on screenplays. > He says, "When we came up against a block and our discussions became very heated and intense, Hitchcock would suddenly stop and tell a story that had nothing to do with the work at hand. At first, I was almost outraged, and then I discovered that he did this intentionally. He mistrusted working under pressure. He would say "We're pressing, we're pressing, we're working too hard. Relax, it will come." And, says the writer, of course it finally always did. We need both modes. The world is value creators (product/engineer/creative/imagination) and value extractors (business/management/finance). Once the latter group get control, they end up squashing the "open" mode that is so key to making good products. The value extractors increase pressure but sometimes lowering pressure will let the product iterations flow to a better product end result. Value must be created first before value can be extracted, but you can't force value creation with only the "closed" mode. Value creation processes that make sure there is an "open" mode along with the "closed" mode are always more successful, and sometimes the "open" mode doesn't look like work so the value extractors cut it first unknowingly killing the product slowly. The wrong type of Agile removes the "open" mode and cuts prototyping, iterations and refinement of creative value creation. A more open type of iterative development is always better. [1] https://www.youtube.com/watch?v=Pb5oIIPO62g https://www.youtube.com/watch?v=Pb5oIIPO62g [2] https://genius.com/John-cleese-lecture-on-creativity-annotated https://genius.com/John-cleese-lecture-on-creativity-annotat...

mgreenleaf 6y ago

Most philosophies get badly diluted and warped after they get placed into a wider audience. A lot of good ideas come from a small group of competent individuals who have experience and think deeply about how they could improve things; but a major reason why so much of the world is still so dysfunctional is because so many people don't think deeply or carefully about what they are doing. So when a good idea comes along, they commit the old mistake of jumping on the bandwagon without deeply imbibing the real reasoning behind it, but that corrupts the idea over time to be a prescriptive cure. So we have fads every few years when the majority of people find out that the old silver bullet didn't work for them, and start looking for a new silver bullet-- and there is always another small group who want to improve things and write a new book with a slightly different take on how to do so.

jerzyt 6y ago

I think that Jira killed Agile. It's such an overhead on the Agile process. Engineers spend more time documenting stuff in Jira than actually solving problems.

m0xte 6y ago
Crawled into this thread to make the same comment. It’s implicit vs explicit. JIRA makes everything so explicit it hurts
heisenbit 6y ago
Jira is only a tool. You can use it for reasonable lightweight communication. Or you can use it as a basis for defensive posturing, preparing for financial change discussions and control freakish micromanagement. If you have a distributed team and can keep management out of it and stick to basic features Jira can help still today. Agile is about culture and the culture of the pioneers and early adopters was different. I‘m seriously thinking I should try to go more the Kanban direction these days to aboid the story point hitting / fitting in ever shrinking sprint trend.
constantine42 6y ago
Jira can be highly customized. I find it easy to use for day-to-day. I also have to deal with Jira with a subsidiary company, and their Jira is completely different, but it works well for their use case. The reporting is a whole other issue. I don't use this, but my PM does because upper management keeps changing their reports and my PM has to keep linking and organizing. But as a developer, doing spring planning and burndown charts work quite nicely.

wobbleblob 6y ago

You forgot the part where the product owner negotiates the number of story points down for every story, and negotiates up the number of sp in every sprint, and complains that the team gets a velocity of exactly 50% every single sprint.

PeterStuer 6y ago

If you do not change the power dynamics in companies, then the exposure of agile will rapidly descend into micro=management, metrics gaming, pass the hot potato and self promotion.

zubairq 6y ago

I wish I could +1000 this. "Standups and Demos were all about self-promotion"