22 ms·

Hard deadlines are not user-first

• latchkey 7y ago
  At Pivotal, I learned that having sprints is silly. They have the concept of one week iterations instead. The PM just keeps a rolling backlog of stories and devs just pick the next one off the top. Dev's are responsible for pointing the stories and the sum of those points averaged over time (usually 2-3 weeks) become velocity. Just keep the velocity as consistent as possible and things work out for the best. If the PM wants a story moved up the list, then they can see how much work will fit into an iteration and how it will affect schedules. All of this is managed in their homegrown, but publicly available tool called Pivotal Tracker. You can read the website documentation for a more thorough explanation. Once I learned this methodology and started practicing it like a religion, deadlines went away and PM's could estimate due dates many weeks in advance. It was a life changing experience that I highly recommend at least giving a shot at your own workplace.
  • alasdair_ 7y ago
    This sounds exactly like every other sprint-based process I have ever encountered.
    • latchkey 7y ago
      Sprints have deadlines and a set amount of work... 'A two week sprint.' Iterations are 1 week and there is no expectation that a story will always fit within the current iteration. The only tool that I have found which can accurately visualize this difference is PT.
      • supermatt 7y ago
        What is the point in an iteration?
        • latchkey 7y ago
          Good question. An iteration is a marker to generate velocity. All of the points collected in that week are summed together and the average of those points across a configurable threshold (typically 3 weeks) is the velocity. Once you have a velocity, you can start to make predictions about the future. For example, if velocity is 10, that means 10 points worth of stories can fit into an iteration. If the PM moves another story into the iteration, the last story would be automatically pushed into the next iteration. Makes it easier to answer the question of 'when will a story be done?' as well as 'how will changing the flow of stories affect deliverables?' Highly recommend you read the documentation, it has been formed over many years and is excellent. https://www.pivotaltracker.com/help/articles/quick_start/ https://www.pivotaltracker.com/help/articles/quick_start/
        • winrid 7y ago
          Because then we'd call them weeks and Sprints would be Fortnights :) In all seriousness I'm curious about the story pointing. Does the team meet together for that at Pivotal?
          • latchkey 7y ago
            Repeated from above: Pivotal has 3 regular meetings: daily morning standup (short), iteration planning (monday), retrospective (friday). Any new stories during the week that haven't been pointed get pointed in the morning meeting.
            • brlewis 7y ago
              Sounds like Pivotal combines elements from scrum and kanban in a way that works well for them. That's what you're supposed to do with agile -- keep adjusting the process until it's working well for your organization.
              • latchkey 7y ago
                this ^^^^^^^^^^^
      • vidarh 7y ago
        In practice, most places I've worked treats sprints much closer to how you describe your iterations than to a fixed amount of work. Most of the time, the sprint planning just provides some ceremony around ensuring important stories are discussed and points allocated, and priorities set, and the planned sprint is pretty much a line in the backlog that suggests an aspirational goal that is likely to change. The point is rarely to hit exactly that, but for it to serve as a means of talking about what needs to be done first - whether something needs to fit into this round, or can wait for the next. It also serves as a means of talking about inter-dependencies and sequencing of changes.
        • latchkey 7y ago
          I think you've been lucky in where you have worked. You read some of the other responses and it isn't the case at all. I've seen some really tragic examples. Pivotal has 3 regular meetings: daily morning standup (short), iteration planning (monday), retrospective (friday). Any new stories during the week that haven't been pointed get pointed in the morning meeting.
          • 0xFACEFEED 7y ago
            out of curiosity what value do you see in morning standups? 15 yrs and i still don't see it (i've really tried).
            • latchkey 7y ago
              I agree that the whole typical 'what did you do yesterday' is indeed lacking value. The standups are mostly just pointing the stories that need pointing, covering any questions and picking the pairs for the days work (pivotal is 100% pair programming). The meetings can be done within 5-15 minutes at most. I'm currently living at a yoga retreat center in the mountains of Vietnam. I can see from the practice that the first few minutes of silence is good to clear the mind. I think having standups is a similar good way to start the day with a positive attitude.
              • 7y ago
      • matt74827289 7y ago
        The end of the sprint should not be a deadline, but a goal. Wasn't that kinda the point of the article? No one ever said a story has to fit within a sprint, that's not how agile or sprints are supposed to work. Some stories take multiple sprints. You should always break down large stories into sub-tasks that do fit within sprints. This iteration thing your describing sounds almost exactly like sprints to me, just reworded to sound like their own thing.
        • latchkey 7y ago
          Ah, the difference is that with iterations, there is never an 'end' and goals are just epics. Correct, all larger stories should be broken down. To be super clear, this is not my own thing. =) It is Pivotal's thing. I am just explaining the process as it was taught to me.
          • alasdair_ 7y ago
            >Ah, the difference is that with iterations, there is never an 'end' and goals are just epics. Jira uses epics in the same way. And I'm not sure what you mean by "there is never an 'end'" - how does that differ from sprints? Iterations and sprints are just two words for exactly the same thing.
      • kerblang 7y ago
        When you say, "devs just pick the next one off the top", that sounds very much like Kanban instead of Scrum. Kanban is radically different but considered "agile". When Scrum degenerates into mgmt screaming, "you missed all your deadlines - again!", Kanban is often a great source of relief, because the only deadlines that count anymore are the "real" ones. It also allows much more flexibility with shifting priorities, which stakeholders love. Absolutely worth a try when Scrum has become a tool of oppression & misery.
        • latchkey 7y ago
          I wouldn't really try to put a name on it other than Pivotal Process or Pivotal Methodology... I was just googling around to see if they even name it and found these articles... https://infocus.dellemc.com/rahul_bhandari/software-development-dell-agile-methodology-pivotal/ https://infocus.dellemc.com/rahul_bhandari/software-developm... (corporate version) https://pivotal.io/agile https://pivotal.io/agile (this one bugs me a bit since it really just compares against waterfall) https://medium.com/@ryanjjones10/what-is-the-pivotal-process-417fab075f4f https://medium.com/@ryanjjones10/what-is-the-pivotal-process... (this one is more accurate)
          • kerblang 7y ago
            Okay well it looks like they've put even more emphasis on pair programming, which Kanban certainly doesn't require, and... I'm not gonna advocate for that part.
            • alasdair_ 7y ago
              Pair programming all the time comes from XP. Almost no one does it, not even Kent Beck. In fact, the only place that I know of that tried "real" eXtreme Programming was the Chrysler Compensation project, which ultimately failed. I'd be amazed that Pivotal actually does pair programming all the time, except that they are in the business of selling tools to facilitate exactly this process.
              • 7y ago
      • balfirevic 7y ago
        > Sprints have deadlines and a set amount of work... Well, they shouldn't: https://www.scrum.org/resources/commitment-vs-forecast https://www.scrum.org/resources/commitment-vs-forecast
      • nradov 7y ago
        You don't understand how agile development actually works and appear to be confused about terminology. There is no difference between a sprint and an iteration; they are two words for the same thing. A sprint is a planning cycle, not a deadline. Many other tools such as Jira or Rally work as well or better than PT. Recommend you broaden your experience.
  • mattlondon 7y ago
    Sounds like every agile team I've ever worked on - sprint and iteration is usually interchangeable. The problem is that Devs making estimates tends not to be accurate IME. Some stuff is easy to estimate, but adding in new & significant functionality is notoriously usually hideously mis-estimated (either high or low). So much so that the numbers basically b come meaningless and can't be relied upon because every major new thing was a lot easier/a lot harder than expected. The reaction to this is to split the task up, but this often requires that you do a lot of pre-work-work to architect and design the work so you know how it can be broken up, and that design work needs to be estimated so you are back at square one with wildly inaccurate estimates.
    • latchkey 7y ago
      If the story estimation isn't accurate, then the velocity goes haywire and this shows up in the reporting in Pivotal Tracker. So like you said, devs learn to get better at forcing the PM's to split the stories into smaller chunks. Smaller stories are almost always easier to accurately point since it is always 2 (1 point for the story, 1 point for testing). The numbers are not meaningless though. That is why velocity is an average of 3 weeks. A single week doesn't blow things out of the water and if it is a new project, the expectation is that we won't know where we are at all those first 3 weeks. It gives a built in ramp-up period for the project. Agreed, the PM's role is SUPER important. For this reason, at Pivotal the PM's usually have a developer background.
      • ec109685 7y ago
        Aren’t you putting all your faith in the PM in this methodology? The way you describe it, a developer’s role is to point out stories and jointly perform the work the PM has allocated. Instead, if those same developers understood the users, use cases and metrics and co-created the work the team does, the team would have 10 or mor engaged minds all working to make a better experience instead of the one super PM.
        • latchkey 7y ago
          It isn't black and white like that. The team always has a voice and can express it at any time. Communication is always key and that is the whole point of developers pointing stories. They could just call a story 8 points and the PM would never get it into the backlog. =)
  • mikekchar 7y ago
    In my experience, there are a few reasons why you would choose sprints over a continuous backlog like this. Originally, these kinds of agile processes did not use continuous deployment. Often you used trunk based development (TBD) where you merged your work directly into trunk/master several times a day. Continuous Integration servers were invented because this style of CI often broke the build. You wanted the test suite to run after you pushed so that other developers would be alerted to a broken build before they pulled. Of course even better to check before you merge, but the source management systems of the day often weren't capable of doing that easily. Sometimes even making a branch was hard work. The end result of this kind of system was that master was not always deployable. You needed a point in time where the system was deployable. That's the end of the sprint. Although it's a very unusual way of doing development these days, prioritising true CI over CD has definite advantages in some environments. In the same spirit, the longer you keep code out of trunk/master, the more risk you have and the more difficult it is for people to do refactoring. If you make large changes over a whole week, then you end up with difficult integrations. Even if you aren't doing true CI (i.e. actually integrating your code with everyone else's on a continuous basis), it's important to limit the amount of time your branch is held out of master. If you have a 2 week sprint and you have 1 week stories, you will almost certainly fail every single sprint (been there, done that ;-) ). The only way for a sprint to succeed is if the vast majority of stories are small enough that you are unlikely to start it without finishing it. The funny thing about having small stories (around 10% of the size of your sprint) is that if you are doing them, then having a sprint end is inconsequential. You may drop a story or two from your board if things don't go as planned, but you will almost never start something and not finish it (especially if you prioritise stories by risk). So the main reason for preferring sprintless backlogs is because keeping the story size small is difficult. In order to keep all your story sizes small, you have to be doing some things very, very well. First, you need to be doing your analysis very well. If you don't know exactly what you are building before you start, you will have wide variability in the amount of time it takes. It will also be very difficult to break problems apart because you aren't entirely sure where the good break points are. Second, your code needs to be very, very clean. You need to be refactoring literally constantly. The code needs to be simple in order to break your problem up easily. This requires a lot of iterations of design in all of your code as the code grows. All of this actually feeds back to the preference for CI over CD. It's not a system that a lot of teams will prefer to use, but it has definite advantages. My experience has been that the potential is quite a bit better, especially over time. You need a team that is completely on board, though. It is especially difficult for PMs who usually don't want to think about problems in as much detail as is necessary for this system to succeed. However, I would encourage developers to keep an open mind because when it works, it works amazingly well.
  • meerita 7y ago
    Hi, PM here. I ditched scrum long time ago with the team and setup 1 week cycles. We meet on monday, to kick off and see results at friday. We managed to keep executable development cycles, so from my part, i tend to ask for less every single weekend because that's how I get most of the results, and keep moving. In the end, it's better than seeing results every 2 weeks and some major results in a month or so. I preffer to move quickly, and iterate those "mini-sprints" in case one went wrong.
    • latchkey 7y ago
      this ^^^^^
    • KZeillmann 7y ago
      This sounds like Scrum with one week sprints.
      • meerita 7y ago
        we don't do retrospectives, groomings, estimation of stories, etc.
  • thomk 7y ago
    This actually sounds a lot like Kanban.
  • himynameisdom 7y ago
    This sounds a lot like Kanban for Scrum Teams. https://www.scrum.org/resources/kanban-guide-scrum-teams https://www.scrum.org/resources/kanban-guide-scrum-teams
  • tootie 7y ago
    It strongly depends on the maturity of the team. All the comments in this thread are assuming the point of view of the heroic developer and his tribulations. Managers know that some devs will sit on their hands and do shoddy work without constant prodding. A good process has the appropriate amount of incentives to move quickly and checkpoints for quality and accuracy. The more mature your team, the lighter these checkpoints can be. I've found that a lot of teams will essentially graduate from sprint-based Scrum to Kanban once they've acclimated and gained some trust. Same with estimates. They may be necessary at first, but eventually become less valuable.
  • slumdev 7y ago
    > At Pivotal, I learned that having sprints is silly. They have the concept of one week iterations instead. So you're doing Scrum with a 1-week sprint?
• clumsysmurf 7y ago
  At the company I work for, our yearly performance reviews are based partially on the metric "Complete 90% of uninterrupted development sprints with no carry over." What I see most of the time, is developers hurrying towards the end of the sprint to meet this arbitrary deadline, choosing the easiest path A instead of the correct path B. Now the project has been run like this for years, you can imagine how much tech debt has accumulated.
  • latchkey 7y ago
    Sounds like a great way for the company to make people work hard (not smart), product mediocre results and not have to pay out bonuses. Have you considered either improving the process or finding a new job?
  • signal11 7y ago
    This is a good example of Godhart’s Law (“When a measure becomes a target, it ceases to be a good measure”) in action. There are better ways, but it requires enlightened management.
    • signal11 7y ago
      Sorry for the typo: it's Goodhart's Law, not Godhart.
  • cryptonector 7y ago
    Right, "agile" has become a developer metric system. I've seen many management fads. They come and go. They go because everyone tires of them and they get gamified anyways. At Sun I heard many people say things like "I'm going to code myself an SUV" whenever we got a new gamifiable management technique. Sprinting too shall pass.
• sudeepj 7y ago
  > just go talk to the stakeholders - product/sales team - ask them if the delay could be potentially customer losing In my experience, sales team rarely have any incentive to help out here. They almost always say that delay will create problems and they quantify in terms of dollars e.g. If X is not done by this date we will lose Y dollars. That Y number is almost made up to make things more urgent. Actually, I have seen sales blaming lack of sales numbers on engineering because the delivery was "too" late.
  • pm90 7y ago
    Agile works well when you’re working in a win win kinda relationship. What you describe happens more often than I am willing to admit. What helps here is if you hold Business Value meetings with real people involved and try to reason relative priorities of stories. This is the fuzzy, social aspect of Agile development but I suspect it’s really the core idea behind the whole thing: it forces people to talk in person and empathize more, hopefully building up cooperative relationships rather than extractive ones. If the stakeholders continue to be sociopaths though, you can either chose to give in and do whatever they say or lie. Both options break the spirit of the thing. Frequently there’s a 3rd invisible option where you use back channels to pull some influence. Which also defeats the purpose of Agile...
  • everdev 7y ago
    > If X is not done by this date we will lose Y dollars. That Y number is almost made up to make things more urgent. Sometimes it's real though. Clients might have to make a vendor decision by the end of a quarter for example and want a bug to be fixed or a feature to be added before they sign. In other cases, there might be a huge event and ad campaign where you have a limited timeframe to make a good first impression on a lot of potential customers. Deadlines suck but in certain cases they're very necessary.
• GoToRO 7y ago
  Deadlines are for managers. If developers need to be aware of the deadlines then the managers are not doing their job.
  • captainredbeard 7y ago
    Maybe - for many product inclined engineers, participating in picking and managing deadlines is an extension of authority and autonomy. Additionally, some people need deadlines imposed to finish work. The alternative would be to fire them.
  • keyP 7y ago
    I don't quite agree here, developers need to have an idea of what they're working to so they can manage their own implementation time. If you don't make developers aware, you put too much control in the manager's hand which isn't a good thing here (unless you're referring to a developer lead but even then, individual developers should have an idea of when they need to complete by).
• pm90 7y ago
  This is a very well written article. TLDR: don’t be too steadfast with sprint deadlines, keep them fuzzy and understand how missing them will impact stakeholders before committing to working over the weekend to meet them. Many Scrum Fanatics, especially the ones holding various Certifications, will scream bloody murder at the idea of tampering with their precious sprint. But the sprint is a fucking artificial construct that was meant to be fuzzy. If it isn’t good at representing how software is delivered you can either change the sprint or try to force your team to sync with it. Unfortunately I’ve seen the agile processes be misused in many ways because it’s inherently so fuzzy and ill defined. It doesn’t really make much sense to bikeshed over minutiae but to focus on the outcomes and tinker liberally with the process to suit your teams style. Just keep your stakeholders informed of the changes.
• ozmbie 7y ago
  In my experience when people focus too much on sprint deadlines, they miss the purpose of sprints. Timed sprints exist not for the benefits of managers, but for the benefit of developers. They exist so that the development team has a shield against managers making last-minute decisions and changing priorities without notice. If the focus and discussion is regularly on short term deadlines, then the developers are not driving the process, the managers are. It means that sprints are seen as a management methodology and not a development methodology. And then everyone has a hard time. Managers who think this way know they’re not “allowed” to make mid-sprint changes so instead they focus on the end/deadline. The managers should be spending their energy supporting the team and figuring out what the priorities are for the next sprint(s). If they’re spending their mental energy on deadlines then they’re doing everyone involved a disservice.
  • jake_morrison 7y ago
    Scrum is for when you have a central dev team in a company that's shared between multiple groups. Once every sprint, you get all the managers in a room and let them fight it out. The result is a list of features that will be in the sprint. Everyone more or less gets their turn, depending on how powerful they are and whether something is legitimately urgent. Even if something is urgent, they can probably wait two weeks if they don't get it in this sprint. The dev team gets to work on something without interruptions for two weeks. The alternative is having everyone pushing around the devs, continuously changing requirements, overloaded devs, and general chaos.
    • regularfry 7y ago
      The critical factor there isn't the sprint, it's the product owner. As long as the PO has the power to prioritise work, and as long as they are the only gateway for getting work into the team, chaos (from this direction, anyway) is minimised.
      • loopz 7y ago
        PO or scrum master as gateway for new work is sort of misguided malpractice that continues the insulation of developers. It may work if PO or scrum master has a clue, "lead" by asking/helping the team, but often in practice they are not technical themselves or external to the team. Having stakeholders fighting for priority and say, builds up helluva toxic environment that trickles down as well.
• hyfgfh 7y ago
  More 4 year to make Mickey Mouse public domain or the law extent the period again.
• 29athrowaway 7y ago
  This is what Steve Jobs has to say about project managers: https://youtu.be/rQKis2Cfpeo?t=116 https://youtu.be/rQKis2Cfpeo?t=116
  • winrid 7y ago
    Well that hits home pretty hard. I didn't know Steve Jobs did these kinds of interviews, thanks.
    • 29athrowaway 7y ago
      Another gem: Steve Jobs on sales and marketing, https://youtu.be/-AxZofbMGpM?t=21 https://youtu.be/-AxZofbMGpM?t=21
  • ec109685 7y ago
    Isn’t that about managers in general?
    • 29athrowaway 7y ago
      It is about preconceived notions about what project management should be. I think many practitioners of Scrum would fall into what Steve Jobs described in that video as bozos.
      • captainredbeard 7y ago
        Scrum is riddled with bozos.
• mikekchar 7y ago
  There are 2 normal ways to do things: work until you achieve the functionality you want and release it when that happens or work until an arbitrary date and release whatever you have at that point. Surprisingly, as a developer I always prefer the latter. As a coworker of mine if fond of saying, the time you know the most about the project is when you are finished. The time when you know the least is when you are starting. By choosing to release "whatever we can do" at a certain time it encourages you to make difficult prioritisation decisions as the "deadline" approaches. Are we really OK with releasing with just this functionality? Maybe we should axe X and replace it with Y since we don't look like we are going to get both. Maybe Z is an even better compromise that we didn't realise was an option at the beginning of the project. If you try to hit functionality, it allows the organisation to avoid rethinking its planning decisions. We aren't releasing until the ideas we had 6 months ago are all implemented exactly as we envisioned it back then. By the way, why is it taking so long? Of course trying to hit both at the same time is just a recipe for disaster.
  • ec109685 7y ago
    The problem with little upfront planning is the team might spend too much time on certain features in the beginning and get crunches at the end to deliver an MVP experience at the agreed upon deadline. By signaling early that a deadline may be missed, there is an opportunity to make course corrections in the spec or shift folks from other projects to deliver a higher quality experience at the agreed upon deadline.
    • bordercases 7y ago
      Clear-as-possible descriptions of uncertainty are the only real hedges against this, because they create the opportunity for directed experiments.
  • hrktb 7y ago
    If the organization is mature enough to rethink the project scope when approaching deadlines, couldn’t it also take the first approach and rethink the delivery as features are getting worked on ? There is effectively organizations that look at ongoing R&D subjects and say “this is almost shippable, we’d just need X. Let’s just priorize X and ship it”
• terryf 7y ago
  The essay is just a long winded way of saying the quote from Eisenhower: "Plans are worthless, but planning is essential" Which is of course a short winded way of saying that the article makes a lot of sense. We for example have sprint goals - these are things that the team commits to actually getting done during the sprint. Then there are tasks in the sprint which may or may not overlap with the sprint goals and may or may not get done during the sprint. It's always about trade-offs.
• keyP 7y ago
  I find being transparent with my team makes it a lot easier. There are internal deadlines and external deadlines. Former are internal ones which have no real consequence if missed and just keep a development rhythm (e.g. weekly iteration, monthly release, quarterly roadmap update catchup etc...). The other type comes from third parties, generally, such as clients or the board. Once you separate these two types of deadlines, I find my engineers more understanding about having to meet external ones whereas blurring internal and external into one "deadline" simply causes people to either burnout or lose faith in management because everything is marked as urgent.
  • Cthulhu_ 7y ago
    I've found most deadlines I've worked with to be internal. The only exceptions to that however was legislation dates; Cookie walls and GDPR, new laws for stock trading on an European level (forgot the name), things like that. These are things for which your company can be fined heavily for. Other deadlines are likely to be of the "we'll start earning money later" variety.
    • Tade0 7y ago
      I have one additional type of external deadline: "The marketing campaign already promised it would be ready by X"
    • ozim 7y ago
      Those are BS as well. No one is going to fine company on day 1 of a new law. GDPR was effective 25 may 2018 but companies still had half of a year to implement it. Basically if you prove you are working on it I bet they will let you off the hook.
  • bcrosby95 7y ago
    I work on a lot of features lately handed down from the CEO of our client. And he places deadlines so unrealistic his own team oftentimes doesn't get us the details until a couple of days before the deadline. For work that takes weeks to do. Stuff is constantly pushed back. The India launch so far has been pushed back 9 months. A new product launch in the USA was pushed back 3 weeks - he initially said they were launching January 1st, when they get 2 weeks off for Christmas and no one works on new years day. Lol. Even external deadlines need to face reality.
• maury91 7y ago
  I don't want to criticize but you spell critic wrong on the first period: "crtitic" Pun intented.
• jillesvangurp 7y ago
  I've done a lot of scrum like projects in the past 15 years. I say scrum like, because absolutely nobody does it "by the book". And if you do, you are doing it wrong because you are being rigid and dogmatic. Every agile manifesto signee will tell you that (I've heard several of them talk about this). I meet a lot of "you are doing it wrong" types. You know the type. Self styled agilists that throw the book at you and seem to love having lots of post its stuck on their walls that provide the illusion of progress in the absence of exactly that. These days, I prefer Kanban style processes for several reasons. Most importantly, the practice of ignoring new requirements for two weeks (aka. doing a sprint) is not sustainable in most projects I'm on. It's just not a thing. Stuff changes all the time, deal with it now instead of in two weeks. Another reason is that I prefer continuous deployment and automating PM reviews away so we don't block shipping stuff over somebody's opinion. Sprint deadlines are utterly meaningless from a release point of view if you release multiple times per day. If it's better than what we have then merge and ship it ASAP. If it's obviously broken, obviously fix it now ASAP and don't wait to have a meeting about it in 2 weeks. Do that multiple times per day. Have responsible processes to ensure bad stuff gets caught before it is merged. It works. Shipping early means you catch stuff early and get feedback from real users rather than opinionated PMs and managers detached from reality. Also people stop throwing things over the fence when they are confronted with the consequences of what they did right away. It forces them to think end to end, a quality that I find is often missing with engineers because they are being shielded by layers of management. Finally, I work with remote developers a lot these days. Anything involving telcos or meetings is downright painful; especially if you add language and cultural barriers. Having full day scrum ceremonial crap is just not something I have a lot of patience for. Doing that over a hangouts meeting is just an exercise in futility. Kanban of course does not stop you from having regular planning meetings, estimation sessions, retrospectives, etc. All that can still work and if it adds value to your team, by all means keep on doing that. IMHO it makes less sense in distributed teams and those require more asynchronous approaches. I find decoupling what we do from when we do it in a Kanban style to be helpful. If the backlog is getting too short, add more stuff and add it in the priority you want things fixed. Don't allow your team to lose focus (aka. multi task) and set concrete goals. Have breakout meetings when things need clarification. Don't pile on too much work in too much detail until it is ready to get done. Doing CD means you can specify changes in terms of what you have in production and how you want things changed. I find that injects a sense of reality that just stops a lot of BS. from ever happening.
• jake_morrison 7y ago
  There is a fundamental relationship between schedule duration, amount of work and quality. If estimates were all accurate, then the amount of work and the sprint duration would be the same. It inevitably takes more work than estimated, so something has to give. If you constrain the duration and the scope of work, then quality will vary. If you constrain the duration and allow overtime, then you get a mini crunch time every two weeks. Some bosses think that people will slack off unless they are given pressure, so they like this situation. A better way is Kanban. It's more or less Scrum where quality is the thing that's fixed. If the task is going to make more time than originally estimated, either you let it take more time or reduce the size of the feature, i.e. implement a simpler version of it.
  • commandlinefan 7y ago
    > If estimates were all accurate then every level of management between the devs up to the CEO could be replaced with a spreadsheet.
• shrimpx 7y ago
  This article has beef with artificially imposed internal deadlines, not deadlines in general. A deadline can be for a ton of legitimate reasons, like delivering a signed contract by the agreed upon date.
• viach 7y ago
  > We'd still be doing MVC in frontend apps if someone at Facebook didn't miss a deadline. After working with React for some tine I'm not so sure the good old Mvc is a bad thing, not always at least.
  • steve_g 7y ago
    That line stuck out for me too. Is MVC as a pattern really all that bad for the majority of web apps?
    • viach 7y ago
      I think it depends on what kind of code mess you prefer - client side or backend. I personally prefer to mess up on the backend, feels much more comfortable to me to fix it up and write tests.
• loopz 7y ago
  Talking to "product managers", managers and various stakeholders everyday, the problem is at the times when these otherwise good people are disconnected to the rest of the organization and have no operational clue. Then they will demand deadlines, push dates backwards, do all sort of non-intentional self-sabotage to the org. They might get their thing done, badly, while hurting the rest of the organization and creating unhealthy competition. When goals are accomplished, they often are unable to even get the value out of the thing they wanted in the first place. These same people won't be able to prioritize when given the choice, and basically just want it all now, again like little toddlers, with checklists! So what do you do? Only healthy thing is to push back, give explanations for what is required before work can begin and have good relationships with all parts of the org yourself. Insulate the toddlers. If they need a PM, they gotta provide a budget.
• mlthoughts2018 7y ago
  > “ There is another problem with locking your sprints. Say you get a new customer ask, it's a potentially trivial but low priority bug. The developer could fix it in a day. But you follow The Process TM, the task gets added to your team's backlog, maybe gets picked couple sprints down the line and does get fixed. But you lost the opportunity to delight the user!” Nope. That context switching will cost you more on average than sticking to the process. And most often you’ll be wrong about the time estimate, or the customer will be wrong about actually wanting that feature, etc., making the context switch even worse and more costly.
• gregdoesit 7y ago
  The post is solid on criticising sprint deadlines, but doesn’t give many suggestions on what works better. Except for this: > Another idea is to experiment with more elaborate probabilistic ways of setting shipping estimates rather than gut based estimates. In my experience, teams setting estimates and holding _themselves_ accountable is a great way to go with multiple benefits. This is why I’m a big fan on estimating software projects with a few ground rules [1]. Sprints and deadlines could be a tool to get here - as with a bunch of things, context, people and culture matter just as much as processes do. Iterating and learning from iterations is how good software is produced, with a team that is motivated and continuously growing. [1] https://blog.pragmaticengineer.com/yes-you-should-estimate/ https://blog.pragmaticengineer.com/yes-you-should-estimate/
  • hcarvalhoalves 7y ago
    One estimation method I found good and worked at a risky project in my job (involved a regulator, they love deadlines) was: 1. Do the usual breakdown of tasks and point game to get relative difficulty estimates 2. Calculate the std dev points for each task instead of just averaging. The assumption is that this is valuable information about how uncertain developers are about the task, so we don’t want to throw it away. 3. Create happy-path and worst-case scenarios considering +-1sigma and +-2sigma 4. Prioritize tasks by deviation, to remove the most uncertainties at the beginning of the project With this you start w/ a more realistic view of the uncertainty of the project, and it’s supposed to converge to the avg as the project goes.
• walterkrankheit 7y ago
  This goes for external (outgoing deadlines) as well as for internal. When you don't tell the world to expect exactly this on THIS day, they won't be unhappy. They'll simply be happy when it happens - and happens correctly!
• taf2 7y ago
  The only deadline I set are for customers. That is either internal customer because they asked can it be done by x day and I either answered yes or no. Or an external customer because I got on a phone call or someone in sales/support indicated an opportunity or at risk customer. Ok fine and sometimes I set deadlines because I’m like OMFG how have we not done this yet. Let’s get it done by x day. For example upgrading framework x to latest version y
• thrownaway954 7y ago
  deadlines exists because managers believe that the team will focus to accomplish the goal. the reality is that _most_ managers are lousy at estimating the amount of time a given task takes and _most_ developers are cowards to stand up to a manager and tell them this. _everyone_ sucks when it comes for planning for the unexpected. in the end, all deadlines do is cause unnecessary stress and disappointment for _everyone_ involved. i'm no different and have been caught up in this game more times than i can count, yes, i suck too. later in life i've come to determine, that whatever deadline i have in my head, i just extended by a factor of 2.5. if i think it will take a month, i say two and half months. that is more than enough time to not only get the project done, but also deal with anything that crops up unexpectedly. my serenity is worth more to me than looking good or being a hero.
  • HereBeBeasties 7y ago
    IME, if the manager is primarily coming up with the estimates, rather than the team, you're doing it wrong. (And are doomed to an eternal cycle of blame, stress and lack of trust.)
    • commandlinefan 7y ago
      You don’t know how this game works. Of course the devs come up with the _initial_ estimates - they have to, or else it wouldn’t be possible to blame them when they end up delivering “late”. But those initial estimates are always “negotiated down” to whatever looks best on the manager’s quarterly bonus review - they might not be brilliant at designing products or scheduling, but they’re geniuses when it comes to re-stating things so that they sound different but are actually the same until you finally get tired of arguing with them (I mean, it’s tricky to argue with somebody who decides whether you get paid or not) and agree to whatever they say and just disappoint them later.
      • HereBeBeasties 7y ago
        We tend to try to do any vaguely longer term/important estimation as a team exercise, which ends up with people talking each other's estimates up, not down - you explore the problem space more effectively as a team and a lot of "but what about X" stuff comes out of the woodwork then. If you have a manager who sets your team up for pressure and failure by artificially revising your estimates down, without cutting the scope of the work, then personally, I would find a new manager. Source: Am a manager.
• ChrisMarshallNY 7y ago
  I tend to take a fairly dynamic approach to design. In many cases; especially where you have heterogenous projects, done by multi-disciplinary teams, dated milestones are pretty much required. You have to have some thing, by some time. I worked like that for many years, as part of massive, multi-national teams. But these days, I have the "luxury" of generally working alone, or as a member of a casual open-source team that doesn't have any specific deliverable deadlines. What I do, is define what "done" looks like, and set some very fuzzy milestones. At each of these inflection points, I reexamine the work I'm doing. In some cases, I decide to bin the whole effort, and either rewrite it, or simply scrag it, and move on to the next in the FIFO. In other cases (less often than I'd like), I am ahead of expected schedule, or the functionality of my work is better than expected. Boo-Ya. Go Me. The important thing for me, is that I have a solid idea of a deliverable. It may not be associated with a date, and may be subject to revision, but it exists. At some point, the project needs to be released. That may require some compromises, and it will require some tedium, like signing and provisioning, as well as producing marketing copy and graphic assets. That's part of what you need to do to have shrink-wrapped releases. A lot of times, I can put off some of the sexier stuff for a 1.1 release.
• bluGill 7y ago
  I think pretty much everybody is missing an important point of deadlines: money. If you are not done by the deadline you are dead. Management (with marketing) has a good idea of what will sell, fail to make the deadline and the product won't make money in the market and should be canceled early. This is the point of estimates: to decide early if the project is worth paying anyone to work on. (or course once you are part way in the project sunk costs become an issue) Note a result of this is deadlines are not something you should come close to: a break-even project isn't worth your time to develop, so there should be plenty of slack in the schedule to cut into before hitting the point of no profit.
  • gowld 7y ago
    That's a extremely high faith view of management's ability to predict the future.
    • davidsergey 7y ago
      It's not really faith, it an educated guess: CEO (or Director of Department) - Makes an educated guess, that if they can release Product A in next 18 months, they will earn $1,000,000. That means that they need to know that A: 1) Product A will be released in next 12-14 months. 2) They will spend less than $700,000. Otherwise they might be better off buying bonds or something. It's effectively a job of an exec / director to make bets. Hopefully they are educated guesses, but there are times when somebody just have to flip a coin too.
      • bluGill 7y ago
        There is a lot of education in those guesses. We know what previous sales are, we know what industry sales are. We know population growth rates. We know many other things. Everything we know puts bounds on what we can sell.
      • mistrial9 7y ago
        > make bets this is literally why a significant portion of high-end intellectuals refuse to participate in this charade, and instead build quality technology in the open. Open source technology, built largely without artificial deadlines and fake drama, define the execution environment that this exchange is taking place upon (in many cases). The old industrial plant planning algebra in 1950s textbooks, say something like "if we make widget N in six months with a team of 6 and $100,000 budget, we have a 30% chance of breaking even in two years, but if we make widget P in 12 months with a team of 4 and $20,000, we have a 60% chance of breaking even in 24 months" etc.. this is slightly useful in certain environments, but anyone here is going to argue that the "future" in 12 or 24 months is stable, technically? The capacity of certain mental models to "Reductio ad Absurdum" is amazing to me, in an age of moving literally one billion+ conversations at once across wires and through space.
• s17n 7y ago
  If it weren't for deadlines I would never do anything, pretty sure I'm not the only one.
• Arrezz 7y ago
  I have been struggling with scope creep for deadlines at my work, I am a junior dev and I have a product owner that means well but changes requirements several times and increases scope mid sprint. How do you push back against this in a nice and reasonable manner?
  • thomk 7y ago
    Document the truth. If you are employed and a product owner is required to give you your workload, you are kinda of stuck. The best you can do is illustrate (over time) that you are unable to get things done because of changing priorities. Put together a collaborative document where you write what you understand to be your tasks. When a task changes or a new one is added, add a new entry with a date/time. Invite him to see it and ask him to bookmark it because you want to be clear on what you should be working on. This is a good thing to have around review time as well, because you may be confronted with 'It doesn't seem like you are very productive'. Also if it is possible that your priorities are not changing as much as you thought, this is a good exercise for yourself as well.
  • DeBraid 7y ago
    Be open about the challenges of context switching and how that may lower your overall productivity. Use specific examples (so everyone can learn) and avoid making about people by focusing on the jobs to be done. If you're not comfortable bringing this up to boss directly, shoot through a Sr dev first (who may coach you around the issues / validate your concerns), or, Sr dev may speak up when needed to support your cause should you bring it to the group/boss.
  • commandlinefan 7y ago
    There’s an old saying: “people will forget what you said, people will forget what you did, but people will never forget how you made them feel.” It’s supposed to be inspirational, but it’s actually depressing because it’s so accurate. How do you put it into action as a dev? Never argue. Ever. If you argue, you’ll lose the argument anyway (you have no power), and they’ll just remember you as the person who was argumentative. If they say, “can you add AI to this product by Friday?” You say, “yeah, sure, let me look into that.” In a sane, rational, just world, everybody would be working together on a shared, common vision, and they’d realize that by giving you herculean tasks with impossible deadlines that nobody could achieve they’re actually hurting themselves as much as (if not more) than they’re hurting you, but the grim reality is that that isn’t the world we live in. If they add scope, just shrug and accept it. Don’t kill yourself with nights and weekends trying to meet their deadlines either - just say, unapologetically, “I was able to do ___ and I’m still working on ___”.
• bauerd 7y ago
  >An ideal solution to this would have been to just go talk to the stakeholders - product/sales team - ask them if the delay could be potentially customer losing. And if it is, by all means put in the extra hours, work those weekends. Strongly disagree, it's not on the shoulders of developers to ensure faulty promises can be kept. I will for sure not sacrifice weekends, this is far from ideal
  • lifeisstillgood 7y ago
    If we read between the lines that means the layers of management are not needed at all if developers are talking to sales / users - see "Developer Hegemony" and "Developer Anarchy"
  • sidcool 7y ago
    I second you. All stake holders will always say that it's critical. And they will make you work on weekends. My experience from consultancy.
  • nift 7y ago
    Have to agree here. I sometimes find quite a big gap between deadline setters (sales/management) and the ones who have to meet them (developers). I find it to be a very difficult topic, as everything has to coexist: no sales, no company but no developers no product to sell which is then no company. I find that the deadline setting sometimes gets out of hand because it's not the setter who has to meet the deadline. For example if I set a deadline you have to meet and I can not influence the work being done (help or somehow make it easier to hit the deadline) how could I ever understand the "true" consequence of setting the deadline? In other words, not my weekend so I probably won't care as much as you. What has worked for me (sometimes) is setting up the consequence; if we have to make x for deadline y, we won't be able to make a for deadline b. And then try and involve "sales" or the deadline setters in how we cut down whatever has to be made so we do make the deadline. But that completely aligns with the post as that rarely is user centric or building the best solution for users. This simply gets stuff done within an arbitrary deadline set by someone, to meet a contract etc. Bear in mind these experiences are from startups and not corporates.
  • 7y ago
• adrianmonk 7y ago
  Well, they are user-first... if you look at humans as resources and managers as users.
• commandlinefan 7y ago
  > So the developer, being a developer, pulls a couple all nighters, maybe works over the weekend and does get it done. And does minimal testing, skips documentation, adds some tech debt, copies-and-pastes code rather than doing proper code reuse - because the deadline is the only thing thing being measured.
• indigodaddy 7y ago
  What was so wrong with the author’s chosen article title that it had to be manually sanitized? I get that HN admins may not like the snark, but it’s the author’s title, it’s his snark, his tone, his article, and by sanitizing the title, you are basically making an editorial decision on his article.
  • dang 7y ago
    The HN guidelines call for changing titles that are misleading or baity. That one was baity, so we replaced it with representative language from the article body. Generally we err on the side of preserving articles' original titles and favoring authors above everyone else! But not when the title breaks that guideline. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
• saas_sam 7y ago
  Reading HN comments makes it sound like engineers think they're the only ones in a company who have to deal with deadlines. It's kind of hilarious. Go ask your sales team how they cope with hard deadlines of closing a specific dollar amount every quarter based on the presupposition that 1. the product delivers what it says without major issues, 2. competitors don't come out with feature or pricing changes that blindside you, 3. other departments (marketing) delivering them enough interested contacts to talk to... and 100 other things. Not to mention the main "stakeholder" in play for them -- the customer -- is ACTIVELY trying to deceive the salesperson in order to get the best deal for themselves. Like, they will literally lie and say they intend to sign a contract with you by end of quarter to get the salesperson to go the extra mile for them. With zero intention of actually following through... Yet the sales team gets it done every quarter. And if they don't? 2 bad quarters in a row = expectation is you're out of a job.
  • crashedsnow 7y ago
    I don't think the main point being made is that deadlines are a PITA, I think it's that the trade-off is unmeasured. Successfully meeting a sales deadline looks the same as signing the same contract after the deadline (other than the deadline), but the argument for deadlines in software being bad is that they materially erode quality and long term viability (shortcuts, tech debt, bugs, usability). The product delivered within the deadline is materially worse than the one delivered after. The problem is that it's hard to attribute these issues to "deadlines" although the intuition is that they are a major cause.
    • saas_sam 7y ago
      > Successfully meeting a sales deadline looks the same as signing the same contract after the deadline (other than the deadline) This is so far from the truth. I encourage you to spend more time with your sales team and even your stakeholders who are buying $100k+ software from vendors. There are so many parameters of a deal that go beyond contract signature date. Deliverables, SLAs, roadmap commitments, length of contract, legal definitions, opt-out conditions, payment terms, pricing, and more. Deals aren't just "on time" or not, they vary greatly in terms of quality. And that quality largely determines your company's ability to hire more engineers. Or fire them. ;-) Bad deals happen when you're down to the wire and have to get it done on time or people will lose their jobs. Not unlike bad software. Work in the real world has deadlines. The people doing the work will always advocate for the loosest deadlines (or none at all, as is often the case with engineers). The people who need the work done will always advocate for the fastest turnaround. Without these checks and balances, the work just does not get done fast enough or well enough to stay competitive.
• kerkeslager 7y ago
  One thing I've noticed on a lot of teams is that sales/product believes their own hype and overestimates the importance of their software in people's lives. There's this belief that customers/users are waiting impatiently for features when 99% of the time, they're just not. Yes, features affect users, but often users don't know what features are coming, because they just don't care enough to know. Software I use every day: Firefox, Slack, Vim, MacOS, Python, Bash, GCC, Android, StrongLifts 5x5 App, Gmail, Google Docs, Google Maps, Simple (Banking) App, VLC. All of these (except maybe Vim?) have released some significant features in the past year. Of these features, I only knew about a few Python features that were coming before they came, and none of them were ones where I was thinking "I can't wait for this to come out! If this doesn't come out soon I'm switching languages!" On the contrary, features take a long time after they come out for me to learn how to use them and for them to affect my decision making. In fact, my initial reactions to new features are much more likely to be a liability than to be an asset to the software company. I'm considering switching away from Simple because their expenses update doesn't really fit my needs, since as a freelancer I'm not paid on a regular schedule. And I'm definitely switching away from MacOS since their deprecations have broken some tools that are key for me. If they had taken more time, maybe someone would have noticed the problems and avoided them. Sure, early on things are different: first-to-market advantage is real. But for most of the lifetime of a project, you aren't releasing killer features. You're releasing incremental changes that have a much higher chance of losing you users than of gaining you users (in the short run, at least). Never releasing isn't an option--death by stagnation is a thing--but releases should be done with painstaking attention to detail rather than urgency.
  • Joeri 7y ago
    Another thing sales forgets is that the features you already have are more valuable than the new features to actual users. They always want to sell the new things, but provided features are added with most valuable first the earlier features will be more valuable than the new stuff. This gets really silly when they rush releases to get the new features and end up breaking old features, which actually decreases overall value of the software compared to releasing nothing new at all.
  • nullspace 7y ago
• vbtemp 7y ago
  I think Agile is the heart of the problem. It is a cargo cult that brings predictability to software projects by ensuring that it's always a dumpster fire, that everyone's stressed, and that everything takes longer than estimated. Eating up "tickets" and crapping out code is not how you quickly deliver software to customers and iterate in the face of changing needs. It's so sad there are generations of developers being raised thinking "Agile" and playing absurd, time-wasting games with "issues" is how to build software. Agile is to the 2020s what the Bobs in "Office Space" was to 2000: "Trendy" corporate management absurdity and fury signifying nothing. The alternative to Agile is Software Engineering, where you do important things like assess your requirements and capabilities, identify how to validate those requirements are functioning properly and support your business requirements, promote testing and QA to a first-class citizen. Most importantly to always have functioning software that is reasonably demonstrated to be correct. That way you release with confidence, people take pride in their work, and the product, team, and schedule all become quite pleasant.
  • heimidal 7y ago
    The Agile you describe is neither the agile I practice nor the one advocated for by sophisticated software development organizations who understand productivity and effectiveness. The things you describe as “software engineering” are part of any reasonable agile implementation. Many orgs have done a poor job of implementing agile practices, but throwing the baby out with the bath water seems like a great way to continue repeating the mistakes of those that came before us.
    • hinkley 7y ago
      Because, as someone observed in an earlier thread, agile has become a management practice instead of an engineering practice.
  • neonate 7y ago
    Things were even worse before agile, or at least as bad. The alternative you describe doesn't exist at scale, nor can it, because the same corporate culture that made agile suck and waterfall suck will make every other process approach suck in much the same way. The most that is possible are sporadic individual exceptions.
• crmrc114 7y ago
  Part of me wonders if the Author works for Amazon, because that sounds totally like Amazon.
• bordercases 7y ago
  Out of all of the factors that could potentially cause poor software (along with the "software disenchantment" as discussed in another recent thread), deadlines stand out as the most concrete and immediate driver of the decisions I take that may result in poor software quality. At least it's the one I can consciously acknowledge as influencing me more than once. I'll have to improve my efficiency at developing software anyway, but this article has given me more confidence that I can pace the promises I give to my clients as to when features will be delivered.