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.
Sprints exist so that both management and devs can realize that there is more work than there is time. It forces devs to be focused and scope their work. It forces management to prioritize and scope down as well.
Keeping the deadline of the sprints is supposed to force management and devs to agree on reasonable scopes, such that the output of the dev team becomes predictable with time.
This enables devs to get trusted by management, breaking the poisonous relationship.
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.
> 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.
Right. This is the thing that's nearly impossible to achieve in most places and why so many people hate Agile: because they're dealing with "imposed agile" where the managers are driving the process.
Yep, the article argues that "locking sprints is a terrible process" because you're either going over or under the mark set upfront. As if those are the only options.
The idea of locking sprints was a reaction against the problem of going _sideways_ , i.e. "changing priorities without notice" and requests for unplanned work to be done "now" without any thought of the effects.
>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
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.
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.
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.
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.
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.
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.
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.
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.
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.
> 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.
That just sounds like Agile...
Like, legit just sounds like the Agile Manifesto.
Honestly, if anything is likely to be the issue. It's Scrum. Scrum has the cargo cult. Agile just seems to get drug through the mud by everyone that implements some authoritarian variant of Scrum.
But again, not exactly a proponent of Agile here anyway.
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.
Engineering-first culture is almost always the wrong idea. It's product-first or nothing. The entire point of agile is prioritization based on business value. Everything always takes longer than estimated regardless of how you manage your project. That's actually a core tenet of agile and one that stakeholders (and budget holders) have the hardest time accepting. Having worked in this industry before agile was prevalent, I can assure you it was never better than this in the past. QA as first-class is a pretty core principle as well. The point of things like Scrum is meant to be visibility and alignment rather than prediction, but impatient people are guaranteed to ruin your life no matter what.
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.
Without turning this into a No True Scotsman, I don't think the problem is Agile. I think the problem is that most companies have no idea what Agile is, and they just implement a subset of its ceremonies in a highly malignant way and pat themselves on the back.
If you have 10 hours a week of mandatory meetings and are asked to make projections about features and deadlines 6-12-18 months into the future, you are not Agile.
> 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.
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.
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.
> to decide early if the project is worth paying anyone to work on.
Yes, we know that’s what you think. We keep trying to explain to you that you’re living in a fantasy world where software development can be predicted accurately in significantly less time than it takes to just do the work. I understand why you WANT that to be true, but wanting something to be true doesn’t make it true, to the frustration of MBAs all over the world.
There are various types of reasons for deadlines. I have seen everything from very good reasons (an external API has to be replaced before its sunset date; regulatory changes that must be met when they come in place) to very bad ones ("$manager said it should be done by $date"; when asked $manager why, the answer was "I thought it should be doable by then, but it's not actually that important").
A deadline without the information of its importance is pretty useless, unless you happen to be in an organization where all deadlines are there for good reasons.
I work in consulting and this is the constant knife-edge we walk on. We scope and plan a project and then have to attach a budget to it in a contract knowing full well that our estimates are going to be wrong. It's such a struggle to get clients with fixed budgets to understand how they have to flex on scope and timing and it's not just because we're slow and lazy.
I once managed a handful of products for manufacturing. Our customers planned their down time, upgrades, etc around our releases. Defects, delays cost our customers real money.
> 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.
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.
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.
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.
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?
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 ___”.
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.
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.
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.
[+] [-] ozmbie|6 years ago|reply
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.
[+] [-] strictfp|6 years ago|reply
Keeping the deadline of the sprints is supposed to force management and devs to agree on reasonable scopes, such that the output of the dev team becomes predictable with time.
This enables devs to get trusted by management, breaking the poisonous relationship.
[+] [-] jake_morrison|6 years ago|reply
[+] [-] pjc50|6 years ago|reply
Right. This is the thing that's nearly impossible to achieve in most places and why so many people hate Agile: because they're dealing with "imposed agile" where the managers are driving the process.
[+] [-] SideburnsOfDoom|6 years ago|reply
The idea of locking sprints was a reaction against the problem of going _sideways_ , i.e. "changing priorities without notice" and requests for unplanned work to be done "now" without any thought of the effects.
[+] [-] mannykannot|6 years ago|reply
That is not to say that sprints do not serve a purpose -- several, in fact...
[+] [-] gowld|6 years ago|reply
[+] [-] bauerd|6 years ago|reply
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
[+] [-] kerkeslager|6 years ago|reply
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.
[+] [-] mikekchar|6 years ago|reply
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.
[+] [-] latchkey|6 years ago|reply
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.
[+] [-] mattlondon|6 years ago|reply
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.
[+] [-] alasdair_|6 years ago|reply
[+] [-] meerita|6 years ago|reply
[+] [-] tootie|6 years ago|reply
[+] [-] himynameisdom|6 years ago|reply
[+] [-] slumdev|6 years ago|reply
So you're doing Scrum with a 1-week sprint?
[+] [-] mikekchar|6 years ago|reply
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.
[+] [-] thomk|6 years ago|reply
[+] [-] keyP|6 years ago|reply
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.
[+] [-] vbtemp|6 years ago|reply
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.
[+] [-] NotATroll|6 years ago|reply
> 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.
That just sounds like Agile...
Like, legit just sounds like the Agile Manifesto.
Honestly, if anything is likely to be the issue. It's Scrum. Scrum has the cargo cult. Agile just seems to get drug through the mud by everyone that implements some authoritarian variant of Scrum.
But again, not exactly a proponent of Agile here anyway.
[+] [-] heimidal|6 years ago|reply
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.
[+] [-] tootie|6 years ago|reply
[+] [-] neonate|6 years ago|reply
[+] [-] slumdev|6 years ago|reply
If you have 10 hours a week of mandatory meetings and are asked to make projections about features and deadlines 6-12-18 months into the future, you are not Agile.
[+] [-] commandlinefan|6 years ago|reply
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.
[+] [-] clumsysmurf|6 years ago|reply
[+] [-] bluGill|6 years ago|reply
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.
[+] [-] commandlinefan|6 years ago|reply
Yes, we know that’s what you think. We keep trying to explain to you that you’re living in a fantasy world where software development can be predicted accurately in significantly less time than it takes to just do the work. I understand why you WANT that to be true, but wanting something to be true doesn’t make it true, to the frustration of MBAs all over the world.
[+] [-] gowld|6 years ago|reply
[+] [-] Spooky23|6 years ago|reply
Given unlimited time, a team will ship more labor hours, that’s it. Constraints matter to getting shit done, and time is the most precious constraint.
[+] [-] perlgeek|6 years ago|reply
A deadline without the information of its importance is pretty useless, unless you happen to be in an organization where all deadlines are there for good reasons.
[+] [-] tootie|6 years ago|reply
[+] [-] specialist|6 years ago|reply
Honoring deadlines also makes you predictable.
I once managed a handful of products for manufacturing. Our customers planned their down time, upgrades, etc around our releases. Defects, delays cost our customers real money.
[+] [-] sudeepj|6 years ago|reply
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.
[+] [-] jake_morrison|6 years ago|reply
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|6 years ago|reply
then every level of management between the devs up to the CEO could be replaced with a spreadsheet.
[+] [-] 29athrowaway|6 years ago|reply
[+] [-] winrid|6 years ago|reply
[+] [-] ec109685|6 years ago|reply
[+] [-] _y5hn|6 years ago|reply
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.
[+] [-] viach|6 years ago|reply
After working with React for some tine I'm not so sure the good old Mvc is a bad thing, not always at least.
[+] [-] thrownaway954|6 years ago|reply
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.
[+] [-] Arrezz|6 years ago|reply
[+] [-] commandlinefan|6 years ago|reply
[+] [-] ChrisMarshallNY|6 years ago|reply
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.
[+] [-] terryf|6 years ago|reply
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.
[+] [-] saas_sam|6 years ago|reply