13 ms·

Less is more agile

282 points by beny23 4y ago

ess3 4y ago
I think what’s missing from a lot of agile teaching material is how you build trust with your stakeholders/management. Without it whatever process you implement will still morph to have to include deadlines and estimates.
Surfactant7 4y ago
> Allen described his work as a consultant when he goes into a new organisation: > - First he observes > - Then he would try to identify the biggest problem > - Then he would try change it (i.e. run an experiment) > - Then if that works, run another experiment > - If it doesn’t work, go back It's probably no accident, but this is pretty close to the scientific method.
- chii 4y ago
  > - Then if that works, run another experiment > - If it doesn’t work, go back The problem is that if it doesn't work for a couple times, you get fired, or at least seen as incompetent. Management want magic rituals that fixes everything, not the scientific method.
  - smcleod 4y ago
    I agree this happens at places with a toxic management culture (one could argue that almost all management culture is toxic). This can however work in places that are (truly) leadership focused where you A) fail fast and B) clearly outline your intention to accept failure as part of the process of improvement.
  - pjc50 4y ago
    > if it doesn't work for a couple times, you get fired That is .. not a reliable description of the outcomes for management consultants, who can inflict spectacular disasters sometimes and still come out ahead. Largely because they deliver the right magic ritual.
    - hef19898 4y ago
      As long as it can be perceived it worked, all is good.
    - baobabKoodaa 4y ago
      Management consultants run powerpoint decks, not scientific experiments.
- tgv 4y ago
  It's common building/engineering sense. It's no accident that (part of) the scientific method looks like that: it's the outcome of this precise process. It may not be optimal, but it delivers.
peteradio 4y ago
> Compared to waterfall, it is fundamentally less constrained. Waterfall demands that we know the system and all the possible problems upfront How I know you don't know what you're talking about in 2 dozen words or less.
- Ecstatify 4y ago
  Could you elaborate?
  - peteradio 4y ago
    Waterfall is not practiced, its an ill-defined strawman meant to be the "other wrong way of doing things". At best its a self-deprecating measure meaning the more agile you are, the less you know where you are going, and the more waterfall your project management appears the more you know what you are doing. Is that supposed to sell me on agile? I want the strawman.
    - dbxkcichhdfufu 4y ago
      Waterfall absolutely was practiced. Budgets always overrun and developers had to work overtime to meet deadlines completing all the tasks that weren't mentioned in the plan.
      - azemetre 4y ago
        This still happens under agile too. It’s not like a process magically fixes things. Most of the issues I read from SWE in regards to agile is that they are often neglected in both decision making and the ability to hold leadership accountable. No amount of agileness is going to save you from a miss managed team.
        denimnerd42 4y ago
        Well I wouldn't count mismanagement against agile then. At my work we practice SWE by managerial dictatorship and also "agile." I'm certainly not holding the failures against agile.
teddyh 4y ago
Related: The Land that Scrum Forgot https://www.youtube.com/watch?v=hG4LH6P8Syk#t=5m37s https://www.youtube.com/watch?v=hG4LH6P8Syk#t=5m37s
samizdis 4y ago
> Recruiting people does not work by doing laundry lists of questions asked by HR drones that don’t understand context or demand 10 years of experience in a technology that’s 8 years old. Five rounds of interviews, tests and exams where people have to recite algorithms by heart are pretty pointless. I second that sentiment. I've worked in places small and autonomous enough that the office manager would handle the admin of posting a job ad, passing on the CVs to the person who knew what their team was looking for in a colleague - note, a colleague, not a "new hire". The absence of an HR filtering layer left hiring decisions to those it most directly affected, but with the admin side handled by office managers (or in some cases COOs). I've also worked in far larger places with heavyweight HR departments. Frustrating and backed by corporate policy (and as declared to shareholders) regarding recruitment processes. The question "Why can’t hiring be agile?" is worth exploring, I think.
- user_named 4y ago
  Hiring is agile in China big tech. Over-hire, do it quickly, and expect people to churn within 1 day to 6 months. Annual turnover of >100% in the places I've been.
- intelVISA 4y ago
  We in tech are the only ones smart enough to fall for all the well-paid productivity sinks, when was the last time your physician had a scrum master?
  - disgruntledphd2 4y ago
    They'd be called a ward director or something, but equivalent roles do exist in hospitals, which are analogous to enterprises.
    - intelVISA 4y ago
      Fair, would they have the same frequency of exposure?
  - rufflez 4y ago
stephc_int13 4y ago
Agile was a relatively good idea, I welcomed the Agile manifesto with open arms because freaking UML was all the rage at the time. Unfortunately, Agile quickly turned to be even worse than what preceded. Corporate bureaucracy should be fought against at all times and by all means. If you work in software, you are valuable enough to have a say, and a choice about who you work for. Not everything has to turn into a bullshit job.
- andsoitis 4y ago
  people > process creative work requires a different environment than widget-making.
  - asdajksah2123 4y ago
    I think this is one of the biggest problems with the Agile manifesto. The actual line is: > Individuals and interactions over processes and tools This makes it seem like processes and tools are not important. But when you get beyond 5 or so people working on something, processes and tools are absolutely critical. There is no contradiction between processes and tools, and individuals and interactions. Better processes and tools will enable better interactions between individuals and will allow those individuals to influence the larger team. What this should have been is something like: Individuals and interactions <=> Processes and Tools Both feed into each other and should be improving each other.
- bracketslash 4y ago
  What would you recommend as a better alternative?
  - stephc_int13 4y ago
    As little middle management as possible. Flat hierarchy is an other kind of bullshit, clearly established leadership is important. When you absolutely need middle management, force them to also do some real work, if they can’t, don’t hire them. Most of the bureaucracy problems are magically going away when middle management is gone.
j45 4y ago
An idea I’ve begun to understand better is the the higher the formality.. often the lower the average velocity, experience, capability and trust in and among the team. Standards, structures and processes are still something I wouldn’t do without, but the configuration or extent can vary based on the team.
zac23or 4y ago
> Don't estimate I agree. But in my experience, the real problem is out of the developers' hands: 1. On a project, my team worked hard not to miss any deadlines. it worked, but the project was delayed for other reasons, and the PO told his superiors that the project was delayed because of the development team anyway. 2. On another project, my team didn't need to estimate or have a deadline. BUT at every meeting the boss said the project was behind schedule. WE WERE LATE EVEN WITHOUT A DEADLINE. Total nonsense. If your boss is crazy, your job has a lot of politics, etc, nothing will work, and this kind of environment loves to embrace Agile methods.
- ilaksh 4y ago
  So-called agile methods. The manifesto is the only thing I know for sure is really agile.
FpUser 4y ago
When I hear agile and SCRUM I just want to puke. Luckily I've been agile free for all my programming life.
- abacadaba 4y ago
  Need a job board for dev jobs that don't do scrum, seems pervasive.
  - FpUser 4y ago
    >"seems pervasive" Sort of. I find real businesses with real needs who hire me as a contractor to design / develop software. They have no extra time and money for propaganda. I work either alone or hire subcontractors for help. How I actually do development is my internal business. They do not go into that area.
  - intelVISA 4y ago
    This really should be a thing.
mbrodersen 4y ago
It’s not hard. Maintain a priority list. Always work on what is #1 priority. If #1 priority is blocked then work on #2 priority. Use the priority list to negotiate with your stake holders. That’s it. I have had a lot of success using this simple formula in my 30+ years career. Both as an individual developer and when managing small to large software teams. It’s simple. It works.
- AdieuToLogic 4y ago
  Agreed. It’s not hard. Maintain a priority list. Always work on what is #1 priority. If #1 priority is blocked then work on #2 priority. I've described this same approach as "risk driven development." Identify the highest risk to an effort's success, address it, then the next highest, etc. If, during this process, a newly discovered risk is identified as being more than what is currently being worked, put the new risk at the front of the queue and address it. This drives risk to 0, which drives the probability of success to 1. And as you succinctly stated: It’s simple. It works.
  - pramodbiligiri 4y ago
    There’s an old term called Spiral Model and an associated paper that puts Risk at the centre of software development decisions - https://en.m.wikipedia.org/wiki/Spiral_model https://en.m.wikipedia.org/wiki/Spiral_model
osigurdson 4y ago
If you don’t have a good idea, don’t even start. The problem with a lot of projects is they focus on the process (because it’s easy) without having a good or clear vision to begin with. If you have a clear and compelling vision, then everything else falls into place. Start with no process and add (sparingly) as needed. Always treat process as the least important thing on any project.
teeray 4y ago
Everything in my experience aligns with what this post states. The best teams had processes that they developed themselves, organically. However, there is a very real, pressing need from middle management to answer “what’s going on with X” when upper management asks. “I don’t know” is not an answer and neither is “we don’t know when it will be done.” These conversations ultimately control the flow of funding. So we make up these elaborate games to create guesses for these conversations. Sometimes the guesses are close, other times not. I don’t know what the answer is, but there exists a gulf between what developers and managers need. Both needs are equally valid.
- bluepnume 4y ago
  Simple: it's the job of a good line manager to embed and ingratiate themselves well enough with those doing the engineering work, that at any point they can give a reasonable estimate for how long a certain thing is going to take when asked middle or upper management. That is, WITHOUT adding extra process. > I quoted the First Law of Mentat at her: ‘A process cannot be understood by stopping it. Understanding must move with the flow of the process, must join it and flow with it.’
  - hef19898 4y ago
    I spend the majority of my career in SCM, not software development. Your comment is absolutely true in my opinion. A good line manager knows what's going on, any KPIs or dashboards just make it easier for a manager to know. Managers rellying on dashboards and reports only to know whats going on in their teams, have always teams oerforming sub par. And they aren't able to answer upper management questions any better.
- ilaksh 4y ago
  The managers and executives need to have visibility into git commits and deployments. They should literally be able to see the front end and read the progress on the back end code, along with some simple reports as it goes. If they can't understand that stuff they should not be making decisions. But basically it's a list of stuff done, with proof, and stuff left to do. Then they can see the progress bar moving and make decisions based on that. To get estimates, ask for explanations of what is involved in the remaining steps. Again, they should have technical competence to get a rough estimate from those reports.
tpoacher 4y ago
I don't agree with the "no estimates" sentiment. My own view is that estimates are useful, but should be treated less as a fixed point-estimate prediction, and more as a single step in a kalman filter, with the understanding that the output at each step is probabilistic, and the number of steps is unknown.
- hannofcart 4y ago
  This is how we do estimates. Nothing set in stone, all just a rough guide. However, the "don't estimate" school is just a little crazy. In no other discipline would this be acceptable as a doctrine. Imagine a contractor you hire to build the house shrugging when you ask him how long or how much it will cost.
  - noirbot 4y ago
    The difference is you're hiring most other trades-people to do a generally fairly routine bit of work and then be done. A lot of programming is about doing unroutine work that has no clearly defined end-state. I've been on teams where estimation is easy - you've got years of roughly the same set of devs doing fairly similar feature/bug work on the same code base to look back on and give an educated guess on sizing. Right now I'm on a team that's mostly doing integrations with third-party systems where our skill levels on the team vary between 20 years and 6 months of experience in the field, let alone this team.
  - jesstaa 4y ago
    Contractor is the wrong metaphor. They're building a house based on a plan already designed by an architect. Software isn't the making of a thing, it's the designing of a thing. Ask an architect how long it will take for them to design your dream home.
    - ilaksh 4y ago
      Architect designing home is the wrong metaphor. Buildings do not have moving parts. Their core structures are almost all fundamentally the same. There are problems to solve, but again, not dynamic systems, and always variations on very well known themes. Programming is usually like building a new type of interdimensional alien spacecraft engine that interfaces with some other alien artifacts. There are usually a lot of unknowns, new concepts, many moving parts, unsolved problems, to build a new invention.
ineptech 4y ago
I generally agree, couple observations: 1. If the people on the team can't change the process, it ain't agile 2. Sprints aren't a failure of agile, they're a failure of devops. Once you start deploying multiple times a day, nobody will care when one sprint ends and the next begins and it'll be fine 3. Estimates aren't literally the devil, execs need to have a rough idea how big it is, just don't get more granular than months
- dfee 4y ago
  Point 2 is very interesting. Any anecdata to corroborate?
  - shoo 4y ago
    A subtlety of point 2 is that not all products or services benefit from multiple deploys per day. If each deploy creates work or risk for the customer, then beyond some point, frequent deploys may be harmful. Your customers may have more valuable things to do than consume or help QA the latest increment of your offering. Separately from deployments, in some less-than-ideally run organisations, management may whimsically change its mind about what the number one priority is from day to day. Two-week sprints can shield the delivery team from this, by acting as some kind of low-pass filter on thrashing priorities, to create space to get a few things entirely done.
  - ineptech 4y ago
    Sure. I worked on a legacy (monolith, >5 years old, no automated test coverage) thing and managed the teams that turned it in to a modern (microservices, ci/cd, full test coverage) thing. So, kind of a naturally occurring A/B test. Five years ago, we deployed once per sprint, and it was a big deal: the test pass takes this many days, the change management team needs this much time, etc. So quite often, finishing a story on day N might mean it goes out on day N+4, but finishing it on day N+1 means it'll take two more weeks, day N+18. That's where the urgency came from: that "tax" of lost time due to infrequent deploys. So there was a lot of pressure to get things into a given sprint. Hence, sprint commitments. Now, on the same platform but with frequent deploys, we still have pressure to get a story done by a certain day sometimes, but the sprint cadence no longer affects our ability to do that. It goes when it goes. Without that pressue, we realized that sprint commitments didn't serve much purpose, so w stopped doing them, and we haven't missed them. That's what I was referring to - it's not the sprint that matters, it's the "tax" on deployment time, which varies depending on where you are in the sprint. Take that away, and you stop caring where you are in the sprint, like a teenager in summertime losing track of the days of the week.
lkrubner 4y ago
The only practice that I've found to be reliably agile is simply having more one-on-one meetings and less large group meetings. Large group meetings tend to waste time for at least some of the people in the group. Often, if you get 8 people together, most of the conversation is between 3 or 4 of those people, while the other 4 or 5 are bored and disengaged. One on one meetings tend to be productive since the meeting would not happen unless one of those people needed to talk to the other person, so 100% of the people in attendance are needed in that meeting. (I'm excluding those companies that have mandatory one-on-one meetings, where the mandatory nature of the meeting sometimes makes the meeting as useless as a large group meeting.) I've known managers who say "Group meetings are great because I get to meet with everyone at once and it saves me so much time!" But that only benefits the manager. Meanwhile some of the people in the meeting are just sitting there, killing time, bored, waiting for the manager to have 10 minutes to talk to them. By contrast, more one-on-one meetings, even if only for 10 minutes, allows everyone to be involved during the moments when they need to be involved. When we criticize some of the rituals and bureaucracy that has become associated with the word "agile" most of the time we are criticizing group meetings. That includes the daily standup. I've run teams successfully by having quick one-on-one 10 minute meetings with everyone on my team, everyday. But I rarely feel the need to get the whole team together. In fact, when I'm leading a large team, I never need to get the whole team together, it is always some smaller subset that I pull together. If you are the team leader, then you need to think carefully about who you need to talk to for any given purpose. If you have the discipline to only talk to the minimum set of people you need to talk to, then you are freeing up a lot of people to keep working on their real work, since they are not in a meeting with you.
- zogomoox 4y ago
  Group meetings, the next exponent of that is SAFe (so called Scaled Agile Framework) where you'll see 2-day-long meetings with 80+ people. I am not a fan.
  - beny23 4y ago
    I think Martin Fowler said it best: SAFe is “Shitty Agile For enterprises”
dhasso 4y ago
I'm always very confused about this kind of statement: "Don’t estimate". To me, projects without estimates tend to take way too much time. It's also federating a team to have deadlines. But I agree that estimations often become a joke when your manager asks you to estimate something that you have no idea how long it will take. How to reconcile both? Being more flexible on the estimation? Taking them as a team goal and not a business one? How to manage the lack of estimation when company planning is important? I can hardly see how "Ok everybody, we are going to release a product but we don't know when! Soon!" could work.
- namose 4y ago
  I've found estimations helpful when it's really about breaking down parts of a task that aren't independently deliverable, but still independently estimatable. When working with a sufficiently technical manager, it gives them the best idea of your confidence function. It also helps junior members of the team understand more of your process and get some problem-solving practice without years of experience.
- soperj 4y ago
  Estimating is a bit of a joke though. It's dependent on too many unknowns. Example: How long will it take you to get to China? It entirely depends on how you're getting there and where you're coming from. I can give you an estimate, but if the only known is that you're starting in North America, and you're going to be held to your estimate, you'd better give the estimated time it'll take to walk there. The real issue isn't the estimating, it's that once you give an estimate, you're held to it even if everything around it changes.
  - pillefitz 4y ago
    Then use ranges instead, problem solved
    - gherkinnn 4y ago
      I can get to China in the range of 12h and 6 Months, not including hoops to get a visa. Happy?
travisgriggs 4y ago
Here’s the part that jumped out at me: > The problem is that Scrum started out as a lightweight wrapper around Extreme Programming (XP) to make it palatable to management, and it is all that extra cruft that people of added that is the problem. Look at that statement, and then let’s abstract it and make it a bit more “polymorphic.” The problem is that process ______ started out as a wrapper around idea/adhoc practice _______ to make it include management, and it is all the other crap that is added that is the problem. Every time management gets involved with the teams I work on, this is what happens. I hear tales of people who have “helpful” management. Some of my managers have been the nicest guys, and tried to do well by me. But because they’re not part of the team, they rarely add value, but rather burden the team with their non value adding presence. (Kinda ranty, I know, I’m just channeling the OP which was titled a rant, I guess)
cube00 4y ago
> And at the end of it, the estimate has to be thrown out anyway because the devs who picked up the story didn’t have the same experience as the devs estimating. I thought the "rule" was a single core team, not multiple sub-teams of devs. If devs with less experience are also at the planning poking table to voice their concerns; the more experienced devs can take that feedback on board to come to a consensus estimate. Individual tasks may be over or under depending on which dev picks it up but the idea is to get the average as close as possible to being accurate.
haspok 4y ago
> It is not the technology that matters, it’s interacting with people. The better engineers can communicate, the better a team will perform. This pretty neatly summarizes my ~25 years of experience in the industry! With the additional observation that most developers and managers are not aware of this phenomenon... :(
locallost 4y ago
Everybody else does it, we have to do it, don't question anything even though you think it's not really that important or even detrimental. It's emperor's new clothing all the way down. I agree it's helpful that there's a common theme on how "we" do things, but the point about making it organic is spot on. Nobody does things so they do scrum. The goal is to deliver something useful, how that gets done might be very different in different contexts. So mold it to how you do things.
polotics 4y ago
Nice enough article, but I don't know where the author found such a poor definition for the word "ceremony". A ceremony ain't just going through motions, it is going through motions to reconnect with elders, identity, re-confirm to all the position of some in the local structure of power, show symbolic values. As such, that word is the most precise one in the Faux-Agile lingo, and clearly shows the purposes have nothing to do with delivering better software faster...
ajb 4y ago
The problem with this kind of article is that it doesn't recognise that software is built in different contexts. "Don't estimate" may be fine if your product is an SAAS that gets updated incrementally. It won't cut it if your clients question is "we've booked the O2 arena for April 2023. Can you build this by then?"
- philderbeast 4y ago
  The problem is these clients have no idea what they are doing, they should be working out if something will be ready before booking. If they are coming to you telling you the deadline and asking if you can meet it you know your going to have problems with them. Invariably they won't have a backup for when its not done on time for whatever reason.
  - ajb 4y ago
    Yeah. The point remains though- even if they haven't booked yet, at some point they're gonna book and then it's a hard deadline. There are even cases where it's valid to come to you with a deadline: can't move Christmas, for example.
- ema 4y ago
  If you have a fixed deadline you descope to something you think will take ten percent of the remaining time build it in what turns out to be more like half of the remaining time and then add enhancements until you hit the deadline.
xlii 4y ago
I'm seeing a lot of people making Agile something it isn't/shouldn't be. There's a difference between core Agile (as in Agile Manifesto) and one of the many commercial imagination of it. Agile wasn't meant for project management but instead as as a tool to organize work in development teams and respond to situation arising in such landscape. It was "weaponized" by business but (at least from my experience) everything that is wrong with it was brought to the table by those business practices. Agile isn't for planning long term projects or managing projects portfolios. It isn't a communication method not a risk management one. There are dozens (if not hundreds) of PM methods implementing full scope of PMBOK's areas of concern that one should use for those. Some even use Agile as an internal process, but still plan using other tools. Yet, I understand many of comments here. In many places I've seen Agile is misused if not bastardized to a level where I hated it. But just to show the contrast: I've worked recently in an environment where there was no scrum, no sprints, no agile points, and environment was really allergic to any mention of Agile (Oh no, we don't use it HERE). There was a lead who talked to everyone on Monday and said "we want to have X by the end of the week, can you do it?". Every single person had their X and everyone worked toward that goal. That planning usually worked and each week ended with deploying next iterative version of the software. It was the most Agile place I ever saw.
- BlargMcLarg 4y ago
  >Agile wasn't meant for project management but instead as as a tool to organize work in development teams and respond to situation arising in such landscape. I wouldn't describe it as such. Such descriptions are how managers got the idea they can put development teams into their bubbles while restricting their access to assets required, demanding they go through multiple layers of management to get simple things done. Ideally, you don't just have a response, but the power to change things more efficiently. Case in point: devops, CICD. Most teams would benefit from having their own CICD. Many companies silo a separate "devops" team and multiple development teams, while pipelining the demands of dev teams from manager to manager. "Devops" team gets swarmed by status pings every day, development teams are annoyed because trivial things don't get solved, management gets annoyed because "why is it taking so long?". And the team could easily teach someone the basics and get their test environment running. Of course, above scenario requires management gives the power to change things to more people. Management in general thrives on lack of trust, so that's a no-no. "We love agile!", they say. Yes, when the teams get nicely silo'd and somehow become "more predictable", but are still as powerless as before.
SuperSandro2000 4y ago
Less is more
mihaigalos 4y ago
I loved this article. Countless times I had to estimate Jira "tickets" (actually called issues in Jira terminology) in hours. To this day, I fail to understand why and I haven't gotten a pertinent answer other than "the business needs it for planning, they're paying us, so you do it." Yet this contradicts at least 2 Agile Manifesto pillars: 1. People and interactions over processes and tools (fostering the estimation ceremony + booking time rather than actual interaction or developer happiness). 2. Reacting to change over following a plan (plan-the-work and work-the-plan over reacting to change). How do you even "do" estimates?! Clean Agile (ISBN-13: 978-0135781869) says "Estimates are never commitments. They are guesses." So it seems the business is trying to get a commitment out of an estimation, at hour granularity. What are your thoughts here?
- meheleventyone 4y ago
  Businesses want to be able to forecast and goals are often set aggressively and ahead of knowing whether they are achievable. There are three basic levers to wiggle at that point. Money, time and project scope. Money can only really be applied early by staffing up, adding more people to a late project will invariably make it later. Thanks Mythical Man Month. So for anything in flight that looks like it will miss a desired goal you can only really change the delivery date or reduce project scope. But you also need to know you’re going to miss so you need some idea of how much work is left and how quickly you’ll get through it. Detailed estimates are a reaction to this along with the idea of measuring ‘velocity’. I’ve never seen either work well but people seem to cling to the idea that next time it’ll help them get it right. One of the funniest Agile meetings I’ve been in had a producer explaining the state of the project. Slide 1: Velocity doesn’t mean anything outside of the team it’s for, comparisons don’t make sense. Slide 2: A line graph plotting each teams velocity against one another. Cue any useful discussion derailed because people want to know how we can get everyone’s velocity up to what looks like the best teams. There’s a lot of dysfunction in business and a lot of winging it without really trying to understand why things are being done. You get a lot of odd practices spread around because project success is not necessarily because of “good leadership” but often project success is the measure used for leaders. A couple of wins and you can gracefully fail upwards believing in your own bullshit.
O__________O 4y ago
Agile is a way being, not a thing to be. For the majority of people, they just want to know what to do and expecting them to “become agile” is like asking them to change their beliefs related to politics, religion, etc. — AND more importantly, practice them. If you want to become more agile, focus on improving yourself and finding others that align to what you feel is agile. ____ * Personally, to me, Boyd’s OODA model of agility is the the most adaptable. Problem is it’s not a check list and requires you to internalize is. For example, most people think being agile is always about speed, but it’s not, it’s about dynamically controlling yourself in to optimally control what is not yourself; sometimes most agile thing to do is be slow, or even do nothing — to see what happens, force someone else to act, etc. People that to me felt the most agile are the ones that enjoy being agile all the time and playing agility games.
he0001 4y ago
Aren’t all business models at odds with agile (agile is one but hardly taught in economics schools, or?)? It sure feels like it, as soon as a agile process gets formalized towards business, it crashes. Execs wants metrics, which gets abused from both sides of it. And to create relevant metrics you need details which just adds to the bureaucracy and slows things down. As there are deliveries to consider and business contracts, management and sales wants hard deadlines to sell. Thus you need to estimate everything to give management an idea if and how relevant something is to do in relation to what needs to be done from a sales perspective. It always ends up in bureaucratic hell because the more formalized something gets, the more data it needs to be accurate and deterministic, which is a goal from management.
thejackgoode 4y ago
I disagree with “don’t estimate” part. If it’s hard, it doesn’t mean it’s wasted effort. And it’s very valuable to business to know with higher degree of precision how much things cost to develop. It depends on many things, but from my experience, it’s possible, we went from 40% to 10% margin of error per quarter. When there’s a will, there’s a way.
torginus 4y ago
Scrum is like communism. It never fails, but when it does, it wasn't real Scrum anyways.
twawaaay 4y ago
There is a whole industry of selling "Agile" to corporations that is peddling this shit. If you are implementing a set process from a book you are by very definition anti-agile. When I implement agile at companies I don't even call it agile. And the only initial practices are: * transparency -- you can't fix what you can't see * improvement loop -- you need to learn from your mistakes and feed the results into next cycle * process building fundamentals -- once you learned you need mechanisms to preserve the results. Checklists, templates, documentation, automation, infrastructure as code, etc. Everything else is result of the learning. As we go, we spot problems or improvement opportunities and we decide how to fix it together. A lot of these fixes come from agile literature. Nobody said you have to reinvent everything. But now that we have implemented it in response to our actual problem we know why it is there which is way better than just implementing it without understanding. Along the way people learn they have power to change things in a realistic way and not only they are welcome to do so but it is actually their job. Which is exactly the goal of all of this and yet completely missing when you put forward a book and say the process has to be implemented exactly as in the book.
- davidthewatson 4y ago
  Nothing has resonated more with the way I work than this. Plan, act, reflect in practical terms. Build, measure, learn in lean terms. Vita activa, vita contemplativa, and sensemaking in academic or philosophical terms. Alistair Cockburn, Allen Hollub, and Bonita Roy in software terms. It’s all a cycle. It doesn’t matter which page from which of those playbooks you take from on any given Sunday. They are remarkably consistent. The observation I’ve made is that friends who succeed at this deftly avoid agile cliches and their teams are focused and efffective while checking all the boxes from crystal clear or spolsky’s list or accelerate. This points to the fact that agile has become the cargo cult dogma it set out to replace twenty years ago.
- azangru 4y ago
  What you described here is perfectly consistent with scrum, which Holub and Farley ridicule. > feed the results into next cycle Right, so you have a concept of cycles; in scrum these would be thought of as sprints (larger cycles) or single days of work (smaller cycles) > transparency -- you can't fix what you can't see Yep. In scrum, this would would be addressed by daily scrums (transparency and coordination on a daily basis), sprint reviews (transparency about the finished cycle), sprint planning (transparency about the next cycle), and sprint retrospectives (transparency about the way the team works) > improvement loop In scrum, that would be sprint retrospectives with a commitment to attempt to address at least some issues raised during a retrospective in the following cycle. > once you learned you need mechanisms to preserve the results In scrum, those would be backlogs (for the product and for the sprint). The practices specific to software engineering, such as automation, infrastructure as code, etc., fall out of the purview of scrum and will be picked up by other engineering practices (CI/CD, version control, etc.)
grahamm 4y ago
'A'gile is broken and should be stopped. I am seriously considering doing something else than the job I love for the reasons in this post.
ethical 4y ago
What a crock of poo. No security as ever. Fowler now bothers to mention Threat mOdeling. You engineers are rubbish. You are so lazy, and hate security so much. Even in healthcare and medical devices. Security is EASY! but alas, most of you and the management drones do not have a clue. Agile has killed more people than Waterfall. Terrible. You should all be ashamed of yourselves. Do try harder! lol
serial_dev 4y ago
The way I use these words goes like this. Agile is what managers who have no clue about the agile manifesto do after they attended a mandatory, 6 hours long SAFe training. "Doing Agile helps the coding monkeys output three times as much as before? Gotcha!" When you prescribe the same sprint start day across the entire organization, that is Agile. If you have 6 weeks sprint commitment, that's Agile. When all teams need to estimate stories using Fibonacci, that's Agile. When the dev team needs to commit how much time they need for a feature that is planned for next year Q4, that's Agile. When the company needs an certified coach, that is Agile. When I need to create a Jira ticket and got it approved by three people to change the name of a small class, that's Agile. I use "agile", when a company or product team understands that when writing software, you need to adapt to the things you find out. You don't know what you will do in 27 weeks and there is no point in story point estimating that stuff a half a year in advance. The company is agile when one team can use Scrum, another team can do Kanban, yet another can do whatever they come up with that works for them.
skeeter2020 4y ago
A lot of this really resonates with me as a manager of dev teams, but once again the very unhelpful advice for "how do you figure out when you'll be done?" is "refuse to do it". If an executive is asking me when we will deliver something this is a completely valid question. It's how everyone outside software development lives. If lean aglie can't give me a way to shape expectation of what we're building AND answer the delivery question we're stuck with BS agile, or we might as well go back to waterfall which (accurate or not) has always been very clear with a delivery date.
- andrei_says_ 4y ago
  How do you answer the delivery date question?
vermooten 4y ago
Waterfall / no process -> Scrum -> Kanban -> XP Problem I found with this journey is that Scrum concepts pollute Kanban and beyond. We now just do what works, as little process as works for us - and we implicitly review the process with each commit.
rufflez 4y ago
I understand that 30 years of experience has to count for something, and maybe some people are fortunate enough to be able to work in an environment that is devoid of all the politics that "Agile" leaves in its wake. My own years of experience have taught me that estimates will always be sought by the customer. They may even shop around for a better price with a different software vendor/low code solution etc. If the development team doesn't know the estimate, how is management expected to know? Simply put, management will be held to whatever number (of person hours) they provide, and are also expected to keep it low enough to close the deal. Deadlines are part of doing business, no matter how much we try to dance around that fact. This is why management will immediately turn around and convert story points into hours. These guesstimates will then become deadlines. I hate having deadlines for creative work, and would rather not be bothered by them, but they exist nonetheless. Until you convince your customers to accept "NFC" and still do business with you, Agile will remain a quixotic idea for the corporate world Can we please not fool the next generation of software developers into believing all this bs?
- beny23 4y ago
  The problem is that all too often do customers think they know what they want but actually have NFC what they need. Unless there is a constructive dialogue between the people who build it and the people that want it, it will end disastrously. Just think of all the failed white elephant projects that get “negotiated” on the golf course. Until there’s an acceptance that being agile isn’t just something developers do but has to be adopted by the whole org, it’s not going to work. I know it sounds a bit dreamy but I’ve worked in big orgs that did agile rather well, so it is possible…
  - rufflez 4y ago
    When it comes to money, the person footing the bill will get pushy rather fast. So I am curious how such a process works closer to the business side of the project, even in a big org

282 points by beny23 4y ago

ess3 4y ago

I think what’s missing from a lot of agile teaching material is how you build trust with your stakeholders/management. Without it whatever process you implement will still morph to have to include deadlines and estimates.

Surfactant7 4y ago

> Allen described his work as a consultant when he goes into a new organisation: > - First he observes > - Then he would try to identify the biggest problem > - Then he would try change it (i.e. run an experiment) > - Then if that works, run another experiment > - If it doesn’t work, go back It's probably no accident, but this is pretty close to the scientific method.

chii 4y ago
> - Then if that works, run another experiment > - If it doesn’t work, go back The problem is that if it doesn't work for a couple times, you get fired, or at least seen as incompetent. Management want magic rituals that fixes everything, not the scientific method.
- smcleod 4y ago
  I agree this happens at places with a toxic management culture (one could argue that almost all management culture is toxic). This can however work in places that are (truly) leadership focused where you A) fail fast and B) clearly outline your intention to accept failure as part of the process of improvement.
- pjc50 4y ago
  > if it doesn't work for a couple times, you get fired That is .. not a reliable description of the outcomes for management consultants, who can inflict spectacular disasters sometimes and still come out ahead. Largely because they deliver the right magic ritual.
  - hef19898 4y ago
    As long as it can be perceived it worked, all is good.
  - baobabKoodaa 4y ago
    Management consultants run powerpoint decks, not scientific experiments.
tgv 4y ago
It's common building/engineering sense. It's no accident that (part of) the scientific method looks like that: it's the outcome of this precise process. It may not be optimal, but it delivers.

peteradio 4y ago

> Compared to waterfall, it is fundamentally less constrained. Waterfall demands that we know the system and all the possible problems upfront How I know you don't know what you're talking about in 2 dozen words or less.

Ecstatify 4y ago
Could you elaborate?
- peteradio 4y ago
  Waterfall is not practiced, its an ill-defined strawman meant to be the "other wrong way of doing things". At best its a self-deprecating measure meaning the more agile you are, the less you know where you are going, and the more waterfall your project management appears the more you know what you are doing. Is that supposed to sell me on agile? I want the strawman.
  - dbxkcichhdfufu 4y ago
    Waterfall absolutely was practiced. Budgets always overrun and developers had to work overtime to meet deadlines completing all the tasks that weren't mentioned in the plan.
    - azemetre 4y ago
      This still happens under agile too. It’s not like a process magically fixes things. Most of the issues I read from SWE in regards to agile is that they are often neglected in both decision making and the ability to hold leadership accountable. No amount of agileness is going to save you from a miss managed team.
      - denimnerd42 4y ago
        Well I wouldn't count mismanagement against agile then. At my work we practice SWE by managerial dictatorship and also "agile." I'm certainly not holding the failures against agile.

teddyh 4y ago

Related: The Land that Scrum Forgot https://www.youtube.com/watch?v=hG4LH6P8Syk#t=5m37s https://www.youtube.com/watch?v=hG4LH6P8Syk#t=5m37s

samizdis 4y ago

> Recruiting people does not work by doing laundry lists of questions asked by HR drones that don’t understand context or demand 10 years of experience in a technology that’s 8 years old. Five rounds of interviews, tests and exams where people have to recite algorithms by heart are pretty pointless. I second that sentiment. I've worked in places small and autonomous enough that the office manager would handle the admin of posting a job ad, passing on the CVs to the person who knew what their team was looking for in a colleague - note, a colleague, not a "new hire". The absence of an HR filtering layer left hiring decisions to those it most directly affected, but with the admin side handled by office managers (or in some cases COOs). I've also worked in far larger places with heavyweight HR departments. Frustrating and backed by corporate policy (and as declared to shareholders) regarding recruitment processes. The question "Why can’t hiring be agile?" is worth exploring, I think.

user_named 4y ago
Hiring is agile in China big tech. Over-hire, do it quickly, and expect people to churn within 1 day to 6 months. Annual turnover of >100% in the places I've been.
intelVISA 4y ago
We in tech are the only ones smart enough to fall for all the well-paid productivity sinks, when was the last time your physician had a scrum master?
- disgruntledphd2 4y ago
  They'd be called a ward director or something, but equivalent roles do exist in hospitals, which are analogous to enterprises.
  - intelVISA 4y ago
    Fair, would they have the same frequency of exposure?
- rufflez 4y ago

stephc_int13 4y ago

Agile was a relatively good idea, I welcomed the Agile manifesto with open arms because freaking UML was all the rage at the time. Unfortunately, Agile quickly turned to be even worse than what preceded. Corporate bureaucracy should be fought against at all times and by all means. If you work in software, you are valuable enough to have a say, and a choice about who you work for. Not everything has to turn into a bullshit job.

andsoitis 4y ago
people > process creative work requires a different environment than widget-making.
- asdajksah2123 4y ago
  I think this is one of the biggest problems with the Agile manifesto. The actual line is: > Individuals and interactions over processes and tools This makes it seem like processes and tools are not important. But when you get beyond 5 or so people working on something, processes and tools are absolutely critical. There is no contradiction between processes and tools, and individuals and interactions. Better processes and tools will enable better interactions between individuals and will allow those individuals to influence the larger team. What this should have been is something like: Individuals and interactions <=> Processes and Tools Both feed into each other and should be improving each other.
bracketslash 4y ago
What would you recommend as a better alternative?
- stephc_int13 4y ago
  As little middle management as possible. Flat hierarchy is an other kind of bullshit, clearly established leadership is important. When you absolutely need middle management, force them to also do some real work, if they can’t, don’t hire them. Most of the bureaucracy problems are magically going away when middle management is gone.

j45 4y ago

An idea I’ve begun to understand better is the the higher the formality.. often the lower the average velocity, experience, capability and trust in and among the team. Standards, structures and processes are still something I wouldn’t do without, but the configuration or extent can vary based on the team.

zac23or 4y ago

> Don't estimate I agree. But in my experience, the real problem is out of the developers' hands: 1. On a project, my team worked hard not to miss any deadlines. it worked, but the project was delayed for other reasons, and the PO told his superiors that the project was delayed because of the development team anyway. 2. On another project, my team didn't need to estimate or have a deadline. BUT at every meeting the boss said the project was behind schedule. WE WERE LATE EVEN WITHOUT A DEADLINE. Total nonsense. If your boss is crazy, your job has a lot of politics, etc, nothing will work, and this kind of environment loves to embrace Agile methods.

ilaksh 4y ago
So-called agile methods. The manifesto is the only thing I know for sure is really agile.

FpUser 4y ago

When I hear agile and SCRUM I just want to puke. Luckily I've been agile free for all my programming life.

abacadaba 4y ago
Need a job board for dev jobs that don't do scrum, seems pervasive.
- FpUser 4y ago
  >"seems pervasive" Sort of. I find real businesses with real needs who hire me as a contractor to design / develop software. They have no extra time and money for propaganda. I work either alone or hire subcontractors for help. How I actually do development is my internal business. They do not go into that area.
- intelVISA 4y ago
  This really should be a thing.

mbrodersen 4y ago

It’s not hard. Maintain a priority list. Always work on what is #1 priority. If #1 priority is blocked then work on #2 priority. Use the priority list to negotiate with your stake holders. That’s it. I have had a lot of success using this simple formula in my 30+ years career. Both as an individual developer and when managing small to large software teams. It’s simple. It works.

AdieuToLogic 4y ago
Agreed. It’s not hard. Maintain a priority list. Always work on what is #1 priority. If #1 priority is blocked then work on #2 priority. I've described this same approach as "risk driven development." Identify the highest risk to an effort's success, address it, then the next highest, etc. If, during this process, a newly discovered risk is identified as being more than what is currently being worked, put the new risk at the front of the queue and address it. This drives risk to 0, which drives the probability of success to 1. And as you succinctly stated: It’s simple. It works.
- pramodbiligiri 4y ago
  There’s an old term called Spiral Model and an associated paper that puts Risk at the centre of software development decisions - https://en.m.wikipedia.org/wiki/Spiral_model https://en.m.wikipedia.org/wiki/Spiral_model

osigurdson 4y ago

If you don’t have a good idea, don’t even start. The problem with a lot of projects is they focus on the process (because it’s easy) without having a good or clear vision to begin with. If you have a clear and compelling vision, then everything else falls into place. Start with no process and add (sparingly) as needed. Always treat process as the least important thing on any project.

teeray 4y ago

Everything in my experience aligns with what this post states. The best teams had processes that they developed themselves, organically. However, there is a very real, pressing need from middle management to answer “what’s going on with X” when upper management asks. “I don’t know” is not an answer and neither is “we don’t know when it will be done.” These conversations ultimately control the flow of funding. So we make up these elaborate games to create guesses for these conversations. Sometimes the guesses are close, other times not. I don’t know what the answer is, but there exists a gulf between what developers and managers need. Both needs are equally valid.

bluepnume 4y ago
Simple: it's the job of a good line manager to embed and ingratiate themselves well enough with those doing the engineering work, that at any point they can give a reasonable estimate for how long a certain thing is going to take when asked middle or upper management. That is, WITHOUT adding extra process. > I quoted the First Law of Mentat at her: ‘A process cannot be understood by stopping it. Understanding must move with the flow of the process, must join it and flow with it.’
- hef19898 4y ago
  I spend the majority of my career in SCM, not software development. Your comment is absolutely true in my opinion. A good line manager knows what's going on, any KPIs or dashboards just make it easier for a manager to know. Managers rellying on dashboards and reports only to know whats going on in their teams, have always teams oerforming sub par. And they aren't able to answer upper management questions any better.
ilaksh 4y ago
The managers and executives need to have visibility into git commits and deployments. They should literally be able to see the front end and read the progress on the back end code, along with some simple reports as it goes. If they can't understand that stuff they should not be making decisions. But basically it's a list of stuff done, with proof, and stuff left to do. Then they can see the progress bar moving and make decisions based on that. To get estimates, ask for explanations of what is involved in the remaining steps. Again, they should have technical competence to get a rough estimate from those reports.

tpoacher 4y ago

I don't agree with the "no estimates" sentiment. My own view is that estimates are useful, but should be treated less as a fixed point-estimate prediction, and more as a single step in a kalman filter, with the understanding that the output at each step is probabilistic, and the number of steps is unknown.

hannofcart 4y ago
This is how we do estimates. Nothing set in stone, all just a rough guide. However, the "don't estimate" school is just a little crazy. In no other discipline would this be acceptable as a doctrine. Imagine a contractor you hire to build the house shrugging when you ask him how long or how much it will cost.
- noirbot 4y ago
  The difference is you're hiring most other trades-people to do a generally fairly routine bit of work and then be done. A lot of programming is about doing unroutine work that has no clearly defined end-state. I've been on teams where estimation is easy - you've got years of roughly the same set of devs doing fairly similar feature/bug work on the same code base to look back on and give an educated guess on sizing. Right now I'm on a team that's mostly doing integrations with third-party systems where our skill levels on the team vary between 20 years and 6 months of experience in the field, let alone this team.
- jesstaa 4y ago
  Contractor is the wrong metaphor. They're building a house based on a plan already designed by an architect. Software isn't the making of a thing, it's the designing of a thing. Ask an architect how long it will take for them to design your dream home.
  - ilaksh 4y ago
    Architect designing home is the wrong metaphor. Buildings do not have moving parts. Their core structures are almost all fundamentally the same. There are problems to solve, but again, not dynamic systems, and always variations on very well known themes. Programming is usually like building a new type of interdimensional alien spacecraft engine that interfaces with some other alien artifacts. There are usually a lot of unknowns, new concepts, many moving parts, unsolved problems, to build a new invention.

ineptech 4y ago

I generally agree, couple observations: 1. If the people on the team can't change the process, it ain't agile 2. Sprints aren't a failure of agile, they're a failure of devops. Once you start deploying multiple times a day, nobody will care when one sprint ends and the next begins and it'll be fine 3. Estimates aren't literally the devil, execs need to have a rough idea how big it is, just don't get more granular than months

dfee 4y ago
Point 2 is very interesting. Any anecdata to corroborate?
- shoo 4y ago
  A subtlety of point 2 is that not all products or services benefit from multiple deploys per day. If each deploy creates work or risk for the customer, then beyond some point, frequent deploys may be harmful. Your customers may have more valuable things to do than consume or help QA the latest increment of your offering. Separately from deployments, in some less-than-ideally run organisations, management may whimsically change its mind about what the number one priority is from day to day. Two-week sprints can shield the delivery team from this, by acting as some kind of low-pass filter on thrashing priorities, to create space to get a few things entirely done.
- ineptech 4y ago
  Sure. I worked on a legacy (monolith, >5 years old, no automated test coverage) thing and managed the teams that turned it in to a modern (microservices, ci/cd, full test coverage) thing. So, kind of a naturally occurring A/B test. Five years ago, we deployed once per sprint, and it was a big deal: the test pass takes this many days, the change management team needs this much time, etc. So quite often, finishing a story on day N might mean it goes out on day N+4, but finishing it on day N+1 means it'll take two more weeks, day N+18. That's where the urgency came from: that "tax" of lost time due to infrequent deploys. So there was a lot of pressure to get things into a given sprint. Hence, sprint commitments. Now, on the same platform but with frequent deploys, we still have pressure to get a story done by a certain day sometimes, but the sprint cadence no longer affects our ability to do that. It goes when it goes. Without that pressue, we realized that sprint commitments didn't serve much purpose, so w stopped doing them, and we haven't missed them. That's what I was referring to - it's not the sprint that matters, it's the "tax" on deployment time, which varies depending on where you are in the sprint. Take that away, and you stop caring where you are in the sprint, like a teenager in summertime losing track of the days of the week.

lkrubner 4y ago

The only practice that I've found to be reliably agile is simply having more one-on-one meetings and less large group meetings. Large group meetings tend to waste time for at least some of the people in the group. Often, if you get 8 people together, most of the conversation is between 3 or 4 of those people, while the other 4 or 5 are bored and disengaged. One on one meetings tend to be productive since the meeting would not happen unless one of those people needed to talk to the other person, so 100% of the people in attendance are needed in that meeting. (I'm excluding those companies that have mandatory one-on-one meetings, where the mandatory nature of the meeting sometimes makes the meeting as useless as a large group meeting.) I've known managers who say "Group meetings are great because I get to meet with everyone at once and it saves me so much time!" But that only benefits the manager. Meanwhile some of the people in the meeting are just sitting there, killing time, bored, waiting for the manager to have 10 minutes to talk to them. By contrast, more one-on-one meetings, even if only for 10 minutes, allows everyone to be involved during the moments when they need to be involved. When we criticize some of the rituals and bureaucracy that has become associated with the word "agile" most of the time we are criticizing group meetings. That includes the daily standup. I've run teams successfully by having quick one-on-one 10 minute meetings with everyone on my team, everyday. But I rarely feel the need to get the whole team together. In fact, when I'm leading a large team, I never need to get the whole team together, it is always some smaller subset that I pull together. If you are the team leader, then you need to think carefully about who you need to talk to for any given purpose. If you have the discipline to only talk to the minimum set of people you need to talk to, then you are freeing up a lot of people to keep working on their real work, since they are not in a meeting with you.

zogomoox 4y ago
Group meetings, the next exponent of that is SAFe (so called Scaled Agile Framework) where you'll see 2-day-long meetings with 80+ people. I am not a fan.
- beny23 4y ago
  I think Martin Fowler said it best: SAFe is “Shitty Agile For enterprises”

dhasso 4y ago

I'm always very confused about this kind of statement: "Don’t estimate". To me, projects without estimates tend to take way too much time. It's also federating a team to have deadlines. But I agree that estimations often become a joke when your manager asks you to estimate something that you have no idea how long it will take. How to reconcile both? Being more flexible on the estimation? Taking them as a team goal and not a business one? How to manage the lack of estimation when company planning is important? I can hardly see how "Ok everybody, we are going to release a product but we don't know when! Soon!" could work.

namose 4y ago
I've found estimations helpful when it's really about breaking down parts of a task that aren't independently deliverable, but still independently estimatable. When working with a sufficiently technical manager, it gives them the best idea of your confidence function. It also helps junior members of the team understand more of your process and get some problem-solving practice without years of experience.
soperj 4y ago
Estimating is a bit of a joke though. It's dependent on too many unknowns. Example: How long will it take you to get to China? It entirely depends on how you're getting there and where you're coming from. I can give you an estimate, but if the only known is that you're starting in North America, and you're going to be held to your estimate, you'd better give the estimated time it'll take to walk there. The real issue isn't the estimating, it's that once you give an estimate, you're held to it even if everything around it changes.
- pillefitz 4y ago
  Then use ranges instead, problem solved
  - gherkinnn 4y ago
    I can get to China in the range of 12h and 6 Months, not including hoops to get a visa. Happy?

travisgriggs 4y ago

Here’s the part that jumped out at me: > The problem is that Scrum started out as a lightweight wrapper around Extreme Programming (XP) to make it palatable to management, and it is all that extra cruft that people of added that is the problem. Look at that statement, and then let’s abstract it and make it a bit more “polymorphic.” The problem is that process ______ started out as a wrapper around idea/adhoc practice _______ to make it include management, and it is all the other crap that is added that is the problem. Every time management gets involved with the teams I work on, this is what happens. I hear tales of people who have “helpful” management. Some of my managers have been the nicest guys, and tried to do well by me. But because they’re not part of the team, they rarely add value, but rather burden the team with their non value adding presence. (Kinda ranty, I know, I’m just channeling the OP which was titled a rant, I guess)

cube00 4y ago

> And at the end of it, the estimate has to be thrown out anyway because the devs who picked up the story didn’t have the same experience as the devs estimating. I thought the "rule" was a single core team, not multiple sub-teams of devs. If devs with less experience are also at the planning poking table to voice their concerns; the more experienced devs can take that feedback on board to come to a consensus estimate. Individual tasks may be over or under depending on which dev picks it up but the idea is to get the average as close as possible to being accurate.

haspok 4y ago

> It is not the technology that matters, it’s interacting with people. The better engineers can communicate, the better a team will perform. This pretty neatly summarizes my ~25 years of experience in the industry! With the additional observation that most developers and managers are not aware of this phenomenon... :(

locallost 4y ago

Everybody else does it, we have to do it, don't question anything even though you think it's not really that important or even detrimental. It's emperor's new clothing all the way down. I agree it's helpful that there's a common theme on how "we" do things, but the point about making it organic is spot on. Nobody does things so they do scrum. The goal is to deliver something useful, how that gets done might be very different in different contexts. So mold it to how you do things.

polotics 4y ago

Nice enough article, but I don't know where the author found such a poor definition for the word "ceremony". A ceremony ain't just going through motions, it is going through motions to reconnect with elders, identity, re-confirm to all the position of some in the local structure of power, show symbolic values. As such, that word is the most precise one in the Faux-Agile lingo, and clearly shows the purposes have nothing to do with delivering better software faster...

ajb 4y ago

The problem with this kind of article is that it doesn't recognise that software is built in different contexts. "Don't estimate" may be fine if your product is an SAAS that gets updated incrementally. It won't cut it if your clients question is "we've booked the O2 arena for April 2023. Can you build this by then?"

philderbeast 4y ago
The problem is these clients have no idea what they are doing, they should be working out if something will be ready before booking. If they are coming to you telling you the deadline and asking if you can meet it you know your going to have problems with them. Invariably they won't have a backup for when its not done on time for whatever reason.
- ajb 4y ago
  Yeah. The point remains though- even if they haven't booked yet, at some point they're gonna book and then it's a hard deadline. There are even cases where it's valid to come to you with a deadline: can't move Christmas, for example.
ema 4y ago
If you have a fixed deadline you descope to something you think will take ten percent of the remaining time build it in what turns out to be more like half of the remaining time and then add enhancements until you hit the deadline.

xlii 4y ago

I'm seeing a lot of people making Agile something it isn't/shouldn't be. There's a difference between core Agile (as in Agile Manifesto) and one of the many commercial imagination of it. Agile wasn't meant for project management but instead as as a tool to organize work in development teams and respond to situation arising in such landscape. It was "weaponized" by business but (at least from my experience) everything that is wrong with it was brought to the table by those business practices. Agile isn't for planning long term projects or managing projects portfolios. It isn't a communication method not a risk management one. There are dozens (if not hundreds) of PM methods implementing full scope of PMBOK's areas of concern that one should use for those. Some even use Agile as an internal process, but still plan using other tools. Yet, I understand many of comments here. In many places I've seen Agile is misused if not bastardized to a level where I hated it. But just to show the contrast: I've worked recently in an environment where there was no scrum, no sprints, no agile points, and environment was really allergic to any mention of Agile (Oh no, we don't use it HERE). There was a lead who talked to everyone on Monday and said "we want to have X by the end of the week, can you do it?". Every single person had their X and everyone worked toward that goal. That planning usually worked and each week ended with deploying next iterative version of the software. It was the most Agile place I ever saw.

BlargMcLarg 4y ago
>Agile wasn't meant for project management but instead as as a tool to organize work in development teams and respond to situation arising in such landscape. I wouldn't describe it as such. Such descriptions are how managers got the idea they can put development teams into their bubbles while restricting their access to assets required, demanding they go through multiple layers of management to get simple things done. Ideally, you don't just have a response, but the power to change things more efficiently. Case in point: devops, CICD. Most teams would benefit from having their own CICD. Many companies silo a separate "devops" team and multiple development teams, while pipelining the demands of dev teams from manager to manager. "Devops" team gets swarmed by status pings every day, development teams are annoyed because trivial things don't get solved, management gets annoyed because "why is it taking so long?". And the team could easily teach someone the basics and get their test environment running. Of course, above scenario requires management gives the power to change things to more people. Management in general thrives on lack of trust, so that's a no-no. "We love agile!", they say. Yes, when the teams get nicely silo'd and somehow become "more predictable", but are still as powerless as before.

SuperSandro2000 4y ago

Less is more

mihaigalos 4y ago

I loved this article. Countless times I had to estimate Jira "tickets" (actually called issues in Jira terminology) in hours. To this day, I fail to understand why and I haven't gotten a pertinent answer other than "the business needs it for planning, they're paying us, so you do it." Yet this contradicts at least 2 Agile Manifesto pillars: 1. People and interactions over processes and tools (fostering the estimation ceremony + booking time rather than actual interaction or developer happiness). 2. Reacting to change over following a plan (plan-the-work and work-the-plan over reacting to change). How do you even "do" estimates?! Clean Agile (ISBN-13: 978-0135781869) says "Estimates are never commitments. They are guesses." So it seems the business is trying to get a commitment out of an estimation, at hour granularity. What are your thoughts here?

meheleventyone 4y ago
Businesses want to be able to forecast and goals are often set aggressively and ahead of knowing whether they are achievable. There are three basic levers to wiggle at that point. Money, time and project scope. Money can only really be applied early by staffing up, adding more people to a late project will invariably make it later. Thanks Mythical Man Month. So for anything in flight that looks like it will miss a desired goal you can only really change the delivery date or reduce project scope. But you also need to know you’re going to miss so you need some idea of how much work is left and how quickly you’ll get through it. Detailed estimates are a reaction to this along with the idea of measuring ‘velocity’. I’ve never seen either work well but people seem to cling to the idea that next time it’ll help them get it right. One of the funniest Agile meetings I’ve been in had a producer explaining the state of the project. Slide 1: Velocity doesn’t mean anything outside of the team it’s for, comparisons don’t make sense. Slide 2: A line graph plotting each teams velocity against one another. Cue any useful discussion derailed because people want to know how we can get everyone’s velocity up to what looks like the best teams. There’s a lot of dysfunction in business and a lot of winging it without really trying to understand why things are being done. You get a lot of odd practices spread around because project success is not necessarily because of “good leadership” but often project success is the measure used for leaders. A couple of wins and you can gracefully fail upwards believing in your own bullshit.

O__________O 4y ago

Agile is a way being, not a thing to be. For the majority of people, they just want to know what to do and expecting them to “become agile” is like asking them to change their beliefs related to politics, religion, etc. — AND more importantly, practice them. If you want to become more agile, focus on improving yourself and finding others that align to what you feel is agile. ____ * Personally, to me, Boyd’s OODA model of agility is the the most adaptable. Problem is it’s not a check list and requires you to internalize is. For example, most people think being agile is always about speed, but it’s not, it’s about dynamically controlling yourself in to optimally control what is not yourself; sometimes most agile thing to do is be slow, or even do nothing — to see what happens, force someone else to act, etc. People that to me felt the most agile are the ones that enjoy being agile all the time and playing agility games.

he0001 4y ago

Aren’t all business models at odds with agile (agile is one but hardly taught in economics schools, or?)? It sure feels like it, as soon as a agile process gets formalized towards business, it crashes. Execs wants metrics, which gets abused from both sides of it. And to create relevant metrics you need details which just adds to the bureaucracy and slows things down. As there are deliveries to consider and business contracts, management and sales wants hard deadlines to sell. Thus you need to estimate everything to give management an idea if and how relevant something is to do in relation to what needs to be done from a sales perspective. It always ends up in bureaucratic hell because the more formalized something gets, the more data it needs to be accurate and deterministic, which is a goal from management.

thejackgoode 4y ago

I disagree with “don’t estimate” part. If it’s hard, it doesn’t mean it’s wasted effort. And it’s very valuable to business to know with higher degree of precision how much things cost to develop. It depends on many things, but from my experience, it’s possible, we went from 40% to 10% margin of error per quarter. When there’s a will, there’s a way.

torginus 4y ago

Scrum is like communism. It never fails, but when it does, it wasn't real Scrum anyways.

twawaaay 4y ago

There is a whole industry of selling "Agile" to corporations that is peddling this shit. If you are implementing a set process from a book you are by very definition anti-agile. When I implement agile at companies I don't even call it agile. And the only initial practices are: * transparency -- you can't fix what you can't see * improvement loop -- you need to learn from your mistakes and feed the results into next cycle * process building fundamentals -- once you learned you need mechanisms to preserve the results. Checklists, templates, documentation, automation, infrastructure as code, etc. Everything else is result of the learning. As we go, we spot problems or improvement opportunities and we decide how to fix it together. A lot of these fixes come from agile literature. Nobody said you have to reinvent everything. But now that we have implemented it in response to our actual problem we know why it is there which is way better than just implementing it without understanding. Along the way people learn they have power to change things in a realistic way and not only they are welcome to do so but it is actually their job. Which is exactly the goal of all of this and yet completely missing when you put forward a book and say the process has to be implemented exactly as in the book.

davidthewatson 4y ago
Nothing has resonated more with the way I work than this. Plan, act, reflect in practical terms. Build, measure, learn in lean terms. Vita activa, vita contemplativa, and sensemaking in academic or philosophical terms. Alistair Cockburn, Allen Hollub, and Bonita Roy in software terms. It’s all a cycle. It doesn’t matter which page from which of those playbooks you take from on any given Sunday. They are remarkably consistent. The observation I’ve made is that friends who succeed at this deftly avoid agile cliches and their teams are focused and efffective while checking all the boxes from crystal clear or spolsky’s list or accelerate. This points to the fact that agile has become the cargo cult dogma it set out to replace twenty years ago.
azangru 4y ago
What you described here is perfectly consistent with scrum, which Holub and Farley ridicule. > feed the results into next cycle Right, so you have a concept of cycles; in scrum these would be thought of as sprints (larger cycles) or single days of work (smaller cycles) > transparency -- you can't fix what you can't see Yep. In scrum, this would would be addressed by daily scrums (transparency and coordination on a daily basis), sprint reviews (transparency about the finished cycle), sprint planning (transparency about the next cycle), and sprint retrospectives (transparency about the way the team works) > improvement loop In scrum, that would be sprint retrospectives with a commitment to attempt to address at least some issues raised during a retrospective in the following cycle. > once you learned you need mechanisms to preserve the results In scrum, those would be backlogs (for the product and for the sprint). The practices specific to software engineering, such as automation, infrastructure as code, etc., fall out of the purview of scrum and will be picked up by other engineering practices (CI/CD, version control, etc.)

grahamm 4y ago

'A'gile is broken and should be stopped. I am seriously considering doing something else than the job I love for the reasons in this post.

ethical 4y ago

What a crock of poo. No security as ever. Fowler now bothers to mention Threat mOdeling. You engineers are rubbish. You are so lazy, and hate security so much. Even in healthcare and medical devices. Security is EASY! but alas, most of you and the management drones do not have a clue. Agile has killed more people than Waterfall. Terrible. You should all be ashamed of yourselves. Do try harder! lol

serial_dev 4y ago

The way I use these words goes like this. Agile is what managers who have no clue about the agile manifesto do after they attended a mandatory, 6 hours long SAFe training. "Doing Agile helps the coding monkeys output three times as much as before? Gotcha!" When you prescribe the same sprint start day across the entire organization, that is Agile. If you have 6 weeks sprint commitment, that's Agile. When all teams need to estimate stories using Fibonacci, that's Agile. When the dev team needs to commit how much time they need for a feature that is planned for next year Q4, that's Agile. When the company needs an certified coach, that is Agile. When I need to create a Jira ticket and got it approved by three people to change the name of a small class, that's Agile. I use "agile", when a company or product team understands that when writing software, you need to adapt to the things you find out. You don't know what you will do in 27 weeks and there is no point in story point estimating that stuff a half a year in advance. The company is agile when one team can use Scrum, another team can do Kanban, yet another can do whatever they come up with that works for them.

skeeter2020 4y ago

A lot of this really resonates with me as a manager of dev teams, but once again the very unhelpful advice for "how do you figure out when you'll be done?" is "refuse to do it". If an executive is asking me when we will deliver something this is a completely valid question. It's how everyone outside software development lives. If lean aglie can't give me a way to shape expectation of what we're building AND answer the delivery question we're stuck with BS agile, or we might as well go back to waterfall which (accurate or not) has always been very clear with a delivery date.

andrei_says_ 4y ago
How do you answer the delivery date question?

vermooten 4y ago

Waterfall / no process -> Scrum -> Kanban -> XP Problem I found with this journey is that Scrum concepts pollute Kanban and beyond. We now just do what works, as little process as works for us - and we implicitly review the process with each commit.

rufflez 4y ago

I understand that 30 years of experience has to count for something, and maybe some people are fortunate enough to be able to work in an environment that is devoid of all the politics that "Agile" leaves in its wake. My own years of experience have taught me that estimates will always be sought by the customer. They may even shop around for a better price with a different software vendor/low code solution etc. If the development team doesn't know the estimate, how is management expected to know? Simply put, management will be held to whatever number (of person hours) they provide, and are also expected to keep it low enough to close the deal. Deadlines are part of doing business, no matter how much we try to dance around that fact. This is why management will immediately turn around and convert story points into hours. These guesstimates will then become deadlines. I hate having deadlines for creative work, and would rather not be bothered by them, but they exist nonetheless. Until you convince your customers to accept "NFC" and still do business with you, Agile will remain a quixotic idea for the corporate world Can we please not fool the next generation of software developers into believing all this bs?

beny23 4y ago
The problem is that all too often do customers think they know what they want but actually have NFC what they need. Unless there is a constructive dialogue between the people who build it and the people that want it, it will end disastrously. Just think of all the failed white elephant projects that get “negotiated” on the golf course. Until there’s an acceptance that being agile isn’t just something developers do but has to be adopted by the whole org, it’s not going to work. I know it sounds a bit dreamy but I’ve worked in big orgs that did agile rather well, so it is possible…
- rufflez 4y ago
  When it comes to money, the person footing the bill will get pushy rather fast. So I am curious how such a process works closer to the business side of the project, even in a big org