9 ms·

Sprints are where all of the issues with agile really come from. Constant arbitrary, meaningless deadlines that serve no purpose but create rushes, tech debt, m

Sprints are where all of the issues with agile really come from. Constant arbitrary, meaningless deadlines that serve no purpose but create rushes, tech debt, missed “commitments” that serve as a meaningless metric to use against teams while made commitments give no benefit. Everything around sprints to try to avoid the negatives results in huge wastes of time in meetings attempting to plan better rather than actually getting work done. Sprint are the root cause. Just use Kanban and you eliminate most of your problems.

edem 8y ago
_This_. I've been advocating Kanban for years. Why try to adhere to rules which you don't need at all instead of having a non-restrictive framework which is adaptable?
mbesto 8y ago
Fair, but sprints are effectively what have forced a lot of software dev organizations into actually thinking about making tasks bite-sized....which was one of the problems (both conceptually and logistically) about waterfall.
- TheOtherHobbes 8y ago
  The lack of feedback breaks classic waterfall. You get a plan, and the plan is assumed to be correct. Of course it never is. As mistakes are revealed, unexpected challenges appear, and requirements are updated or clarified, the plan unravels instead of adapting. The only real benefit of Agile is that it should - in theory - allow the plan to be modified, so projects can be steered towards a target instead of being treated as fire-and-forget. (And miss.) Task granularity should not be a specific benefit - it should fall naturally out of competent goal-based planning in whatever paradigm is being used.
  - walshemj 8y ago
    I've never see a waterfall process that did not have feed back.
- octorian 8y ago
  But not all tasks can be made bite-sized. Or more specifically, sometimes the bite-sized pieces aren't "complete enough" to be a valid unit of work to be nicely wrapped up and finished during a sprint. What happens as a result, is that more major tasks never get sufficient priority to actually happen. This can easily lead to an incremental "refuctoring" of the code base, where you have a lot of individually-nice bite-sized tasks that, in aggregate, turn the source tree into a total mess.
umvi 8y ago
In defense of sprints, not everyone is the same. Deadlines for me are a strong motivation to get things done, whereas "no deadline, just do it at your own pace until it's done" will cause me to procrastinate and get it done much more slowly. There is no silver bullet for software development process. It takes hard work and flexibility to optimize your team's work flow.
- yebyen 8y ago
  I've been reading "It Doesn't Have to be Crazy at Work" and they have a chapter about this. Deadlines are great! Estimates are terrible, and humans are terrible at estimating. Scope needs to be elastic to accommodate this fact of life. If the project is not done in the 6 weeks you set aside for it, just ship something anyways and move on. It was only worth 6 weeks when you planned on getting it done in 6 weeks, so why spend more? Go ahead and plan another sprint if it turns out what you were able to build in the time allocated wasn't enough, and you really need more. (Put it up against the other opportunities you have, and give them all a fair chance at those finite development resources, something else might also turn out to be more important.) Just don't spend forever and drag out the deadline, throwing off the timeline for whatever you had planned to do next, because you needed more time for the thing that underestimated how big it was, so it wasn't really possible to do that whole thing in only 6 weeks. The release that is reduced in scope might be totally insufficient, or, it might be just what your users needed! The knife also cuts both ways – if you're willing to accept that project scope can change in either direction, you can occasionally deliver things early too. I really like everything about this book.
  - TheOtherHobbes 8y ago
    If you set aside 6 weeks and it takes 12, you suck at estimating. Not only are you likely to ship a broken product, but you also have no way of making intelligent business decisions about possible projects. Project A will bring in $X. You estimate 6 weeks. It takes 12. Project B will bring in $Y. You estimate 6 weeks. It takes 7. If X is similar to Y and you bet on the wrong horse, you've dented and/or sunk your cash flow for no reason. Saying "Humans suck at estimating" is nonsense. It's a skill that can easily be improved - usually at the cost of some up front planning - and there are plenty of resources to help you with that. The real problem with Agile is that it gives management an excuse to do no estimation at all. Some alpha-wannabe manager bangs their fist on a desk and says "I want this in three weeks". Instead of saying "You're insane" teams are pressured into trying to make up for someone else's laziness and lack of contact with reality.
matthewmacleod 8y ago
Don’t run sprints if you don’t need them - that’s the answer. But honestly, I’m not sure what the problem is. I’ve found they they’re perfectly suitable at providing: - an opportunity to check in with a wider team and demonstrate features. - the chance for the development team to periodically review progress and identify any recurring issues. - the chance to plan upcoming work and identify any external tasks that need to be taken care of. Is the problem maybe that some organisations are over-using the “commitment” aspect as a metric? To my teams, “commitment” has generally meant “what we have agreed among ourselves we will be able to deliver in a unit period”. The metrics are purely internal, and useful for allowing us to see if we frequently over- or under-estimate how much work we can do; the sprint is really just the period of time across which we measure and refine.
- spiritcat 8y ago
  "The metrics are purely internal" bwhahaha, good one!
  - matthewmacleod 8y ago
    Well, I'm describing how my teams have worked, and it's true! I'd be even stronger on that point – not only should metrics probably not be available outside of the team, but they are even completely without meaning if they're used outside the context of the team. Maybe one of the biggest problems people experience with Scrum or Agile generally is the inappropriate use of metrics.
    - deleted 8y ago
      [deleted]
- freedomben 8y ago
  > Don’t run sprints if you don’t need them - that’s the answer. Except the people being forced into the sprint aren't the ones with power to opt out. It has always been my experience that there is a "product owner" or agile coach or some other title who makes the decision, and isn't one that has to live inside the system they create. So I agree with you in theory. Some people thrive in the sprint, others suffer and struggle. If everyone could opt in or out, it would be great. But in practice I've never seen the ability to opt out.
deleted 8y ago
[deleted]
ken 8y ago
Last week, at the end of a work day, we started talking about what the schedule was going to be for Saturday (not a 6th work day -- we're not on a M-F schedule here). Someone asked "Is it a goal-based day or a time-based day?" And there was an answer ready! Fantastic. In 20 years, I've never heard anyone ask that in the software field. In software, I've always been expected to work as fast as possible at all times, and when we get near an (arbitrary) deadline, to stay late as needed. Software is full of young people, and people who have never managed any kind of team before. I have no problem working for someone younger than myself, but I do think that people should have experience managing some kind of team before they're thrown into the deep end. Software is much more complex than almost anything else we make, and it's no wonder that just figuring it out as we go along has yielded less than stellar results.
- acoard 8y ago
  I've often heard this (or a similar?) distinction as "man-hours" vs "calendar time"
  - thaumasiotes 8y ago
    ken doesn't describe what a "goal-based day" means, but I don't see how it could match the distinction between man-hours and calendar time. The difference between today and tomorrow is one day of calendar time. If you have a team of 3 people working 5 hours a day on a given project, then in one work day of calendar time 15 man-hours of work will be done on the project. Man-hours just aggregate calendar time contributed by multiple people (and ignore calendar days when no work occurs). But none of that has anything to do with goals.
- lkrubner 8y ago
  I've seen some young people who are very good managers, but I've also seen some absolute disasters. I've also seen some older folks who are absolute disasters. I shared a story about both kinds of manager in How To Destroy A Tech Startup In Three Easy Steps: https://www.amazon.com/Destroy-Tech-Startup-Easy-Steps/dp/0998997617/ https://www.amazon.com/Destroy-Tech-Startup-Easy-Steps/dp/09...
LoSboccacc 8y ago
> Sprint are the root cause. I disagree. there's nothing inherently wrong with short iterations or a predictable release window. trying to do agile with fixed budget, fixed requirements and a fixed timeline is the core issue. most of the problems with agile, including "devs having to do this much tasks or die" within each iteration, comes from trying agile on an inflexible plan.
- wirrbel 8y ago
  What's wrong is to have a team wide iteration xycle instead of iterating within features / use cases
  - pas 8y ago
    Why? Fixed team global sync points sound great to me. Fixed interval measurement windows also help with correct burndown estimates.
rooam-dev 8y ago
I came to a similar conclusion and prefer Kanban to Scrum. If there are not enough tasks you pull from backlog, if it's too much then they get finished in next sprint. Work never ends, so why the need for extra overhead to group it into 2 weeks? I always see it as a "marathon", constant sprinting is no good long term. However, Kanban works as long the team knows priorities and can choose between good and over kill solution, which is easier said than done. Working in a good pace without a deadline is challenging itself, since you think you have all the time in the world.
_hardwaregeek 8y ago
I hate the term "sprint". The word gives an impression of desperation and short term thinking. You don't sprint when you're running a marathon; it's not sustainable. It's a superficial complaint, but names do matter.
- matwood 8y ago
  Let's rename it to 'checkpoint' then. Even in a marathon a runner is checking their time to where they are every X miles. The runner then adjusts their pace if they have a goal time. In software a checkpoint should result in the same behavior.
- jrvarela56 8y ago
  Just change the name to 'iteration'. Removes the speed/intensity analogy and reinforces continuous improvement.
sonnyblarney 8y ago
I really disagree with this. Sprint objectives are by no means arbitrary or meaningless - or any more so than other deadlines - they have value to the extent they are intelligently formulated. Sprints have a very important operational dynamic, in that they set a fairly clear, achievable, short term goal. Software is always a pandora's box, and left to their own devices, a lot of devs could work on the smallest thing ... forever. We are all guilty of this. Long term milestones (i.e major product iteration) are hard to internalize, they are vague to each individual even if they have meaning at scale. Sprints provide the means for large things to be broken down into achievable pieces, which much more strongly enable small teams and individuals to focus on that specific outcomes. Maybe they shouldn't be called 'sprints' maybe just 'mini milestones' or something ... but they are useful. Or 'waypoints'. Getting lost in a sea of software is very easy ... so setting 'waypoints' I feel is very, very useful.
- bb88 8y ago
  > Sprints have a very important operational dynamic, in that they set a fairly clear, achievable, short term goal. Lately, the trend with those using Jira in large organizations is to just "carry-over" what's not done in the current sprint into the next. And so instead of talking about why something didn't get completed, and how to resolve it quickly (move it to someone else, change the way it's done, postpone it until something else makes it easier), the work snowballs, with even more work getting piled onto the sprint. That's because while the dev team is agile, management deadlines often won't budge. The other problem is dependency upon another process/service internal to the organization that is not on your sprint cycle. Typically they have other, different priorities, which don't match yours. So they may get around to it eventually, which might mean a week to a month typically. I think Kanban is in someways vastly superior in these cases. You can still do "waypoints" at say every two weeks to see how things are moving along, but at some point if your company isn't "agile" then it really makes no difference if your team is.
- brightball 8y ago
  Checking in is useful. The problem from sprints comes when each one is treated as a deadline instead of just a point to check in, evaluate new information, potentially pivot. When they are treated as deadlines, the problems come. And there is no reason you can simply forgo sprints entirely...and still check in, see how things are going, pivot, evaluate new information. To this point in my career, I’ve never seen sprints present when they didn’t go down the destructive path for teams.
majormajor 8y ago
"Planning better" is a hugely valuable thing, if you can pull it off. You'll end up with less pressure, happier stakeholders, and less frustration with your own output. Even in a purely selfish better-for-the-team way: an accurate plan and capacity projection (relatively - if you have bosses who expect perfection here, that'll bit you) makes a great input into decisions about headcount, hiring, and project allocation. If you can't plan well enough to know you need to ask for help, you're screwed. Agile as I've seen it in the wild is easy to twist into "plan more verbosely" instead of "plan better," though. The most recent way I've seen this manifest is coming into a team that planned out each ticket in great detail when it came to execution - gotta maximize that committed/completed ratio - but invested very little in making sure they were planning the right thing. Someone would ask for something, it would become a ticket. But whether or not that was the right thing short-/medium-/long-term? That's a conversation that didn't have anywhere to happen. Another is confusing "producing more estimation artifacts" (subtasks, hour allocation, etc) with "investing the right amount of time in planning." Going from a 30 second story point estimate to a 2 minute subtask breakdown in sprint planning isn't what it takes to make an accurate estimate for a project.
joseph8th 8y ago
Sounds like management is using sprints to enforce deadlines and releases. Our team uses them to improve our ability to estimate, which in turn requires us to think each set of technical requirements through and anticipate issues before we start pounding keyboards. We use them to structure our work, but decoupled them from releases. The Dev team owns the sprints, but the business owns releases. DevOps uses Kanban however, because it works better for them. That makes us more flexible. Agile. It's been a years-long process but I'm really happy with our "Agility" these days. Our sponsor is the VP of Tech and he gets it (used to be our QA lead). If we have rollover we talk briefly about estimating better but it's not the end of the world, because we actually have gotten better at estimating. Some sprints we nail it. Other times we miss, but management isn't using those metrics as a bludgeon so it actually helps us to work smarter.
sebazzz 8y ago
The problem is not agile, it is an all-alige approach. It is at least in our case. Sprints are feature-focused, which leaves little time for software development craftsmanship: reducing technical debt, updating outdated dependencies etc. To give some context: We have multiple pieces of software we build and maintain for multiple clients. When a client requests some features, they buy some sprints and we do the work and then it's done. During the life cycle of the software there is a maintenance contract for service and support and resolving bugs. This does not have much room for software craftsmanship either. This is just where I work,but I can't imagine we are the only one working like this. This is an implementation problem, not an methodical problem. One of the ultimate causes is that our org is project based, so no project, no work for that client. And the software quality suffers IMHO.
kamaal 8y ago
Also 'move fast, and break things'. Without understanding what you are supposed to do. You move a lot without going no where, with a lot of broken things.
mcv 8y ago
Sprints are often misused and misinterpreted. They are not hard deadlines. A deadline is when there's going to be a real problem when you don't make it. When a new campaign, shop, whatever opens, the corresponding website needs to be there. That's a deadline. A sprint goal is meant to provide focus. You've got something to work towards, but if you don't make it, you don't make it. Presumably there was a good reason you didn't make it. It's good to examine that reason to see if that reason can be taken away, or otherwise it can be taken into account in planning. But it's not the end of the world if you don't complete a sprint on time, and you should certainly not work late to complete the sprint. I've worked in very successful teams that never finished a sprint on time. I think that's totally fine. It's not about the deadline, it's about the focus.

edem 8y ago

_This_. I've been advocating Kanban for years. Why try to adhere to rules which you don't need at all instead of having a non-restrictive framework which is adaptable?

mbesto 8y ago

Fair, but sprints are effectively what have forced a lot of software dev organizations into actually thinking about making tasks bite-sized....which was one of the problems (both conceptually and logistically) about waterfall.

TheOtherHobbes 8y ago
The lack of feedback breaks classic waterfall. You get a plan, and the plan is assumed to be correct. Of course it never is. As mistakes are revealed, unexpected challenges appear, and requirements are updated or clarified, the plan unravels instead of adapting. The only real benefit of Agile is that it should - in theory - allow the plan to be modified, so projects can be steered towards a target instead of being treated as fire-and-forget. (And miss.) Task granularity should not be a specific benefit - it should fall naturally out of competent goal-based planning in whatever paradigm is being used.
- walshemj 8y ago
  I've never see a waterfall process that did not have feed back.
octorian 8y ago
But not all tasks can be made bite-sized. Or more specifically, sometimes the bite-sized pieces aren't "complete enough" to be a valid unit of work to be nicely wrapped up and finished during a sprint. What happens as a result, is that more major tasks never get sufficient priority to actually happen. This can easily lead to an incremental "refuctoring" of the code base, where you have a lot of individually-nice bite-sized tasks that, in aggregate, turn the source tree into a total mess.

umvi 8y ago

In defense of sprints, not everyone is the same. Deadlines for me are a strong motivation to get things done, whereas "no deadline, just do it at your own pace until it's done" will cause me to procrastinate and get it done much more slowly. There is no silver bullet for software development process. It takes hard work and flexibility to optimize your team's work flow.

yebyen 8y ago
I've been reading "It Doesn't Have to be Crazy at Work" and they have a chapter about this. Deadlines are great! Estimates are terrible, and humans are terrible at estimating. Scope needs to be elastic to accommodate this fact of life. If the project is not done in the 6 weeks you set aside for it, just ship something anyways and move on. It was only worth 6 weeks when you planned on getting it done in 6 weeks, so why spend more? Go ahead and plan another sprint if it turns out what you were able to build in the time allocated wasn't enough, and you really need more. (Put it up against the other opportunities you have, and give them all a fair chance at those finite development resources, something else might also turn out to be more important.) Just don't spend forever and drag out the deadline, throwing off the timeline for whatever you had planned to do next, because you needed more time for the thing that underestimated how big it was, so it wasn't really possible to do that whole thing in only 6 weeks. The release that is reduced in scope might be totally insufficient, or, it might be just what your users needed! The knife also cuts both ways – if you're willing to accept that project scope can change in either direction, you can occasionally deliver things early too. I really like everything about this book.
- TheOtherHobbes 8y ago
  If you set aside 6 weeks and it takes 12, you suck at estimating. Not only are you likely to ship a broken product, but you also have no way of making intelligent business decisions about possible projects. Project A will bring in $X. You estimate 6 weeks. It takes 12. Project B will bring in $Y. You estimate 6 weeks. It takes 7. If X is similar to Y and you bet on the wrong horse, you've dented and/or sunk your cash flow for no reason. Saying "Humans suck at estimating" is nonsense. It's a skill that can easily be improved - usually at the cost of some up front planning - and there are plenty of resources to help you with that. The real problem with Agile is that it gives management an excuse to do no estimation at all. Some alpha-wannabe manager bangs their fist on a desk and says "I want this in three weeks". Instead of saying "You're insane" teams are pressured into trying to make up for someone else's laziness and lack of contact with reality.

matthewmacleod 8y ago

Don’t run sprints if you don’t need them - that’s the answer. But honestly, I’m not sure what the problem is. I’ve found they they’re perfectly suitable at providing: - an opportunity to check in with a wider team and demonstrate features. - the chance for the development team to periodically review progress and identify any recurring issues. - the chance to plan upcoming work and identify any external tasks that need to be taken care of. Is the problem maybe that some organisations are over-using the “commitment” aspect as a metric? To my teams, “commitment” has generally meant “what we have agreed among ourselves we will be able to deliver in a unit period”. The metrics are purely internal, and useful for allowing us to see if we frequently over- or under-estimate how much work we can do; the sprint is really just the period of time across which we measure and refine.

spiritcat 8y ago
"The metrics are purely internal" bwhahaha, good one!
- matthewmacleod 8y ago
  Well, I'm describing how my teams have worked, and it's true! I'd be even stronger on that point – not only should metrics probably not be available outside of the team, but they are even completely without meaning if they're used outside the context of the team. Maybe one of the biggest problems people experience with Scrum or Agile generally is the inappropriate use of metrics.
  - deleted 8y ago
    [deleted]
freedomben 8y ago
> Don’t run sprints if you don’t need them - that’s the answer. Except the people being forced into the sprint aren't the ones with power to opt out. It has always been my experience that there is a "product owner" or agile coach or some other title who makes the decision, and isn't one that has to live inside the system they create. So I agree with you in theory. Some people thrive in the sprint, others suffer and struggle. If everyone could opt in or out, it would be great. But in practice I've never seen the ability to opt out.

deleted 8y ago

[deleted]

ken 8y ago

Last week, at the end of a work day, we started talking about what the schedule was going to be for Saturday (not a 6th work day -- we're not on a M-F schedule here). Someone asked "Is it a goal-based day or a time-based day?" And there was an answer ready! Fantastic. In 20 years, I've never heard anyone ask that in the software field. In software, I've always been expected to work as fast as possible at all times, and when we get near an (arbitrary) deadline, to stay late as needed. Software is full of young people, and people who have never managed any kind of team before. I have no problem working for someone younger than myself, but I do think that people should have experience managing some kind of team before they're thrown into the deep end. Software is much more complex than almost anything else we make, and it's no wonder that just figuring it out as we go along has yielded less than stellar results.

acoard 8y ago
I've often heard this (or a similar?) distinction as "man-hours" vs "calendar time"
- thaumasiotes 8y ago
  ken doesn't describe what a "goal-based day" means, but I don't see how it could match the distinction between man-hours and calendar time. The difference between today and tomorrow is one day of calendar time. If you have a team of 3 people working 5 hours a day on a given project, then in one work day of calendar time 15 man-hours of work will be done on the project. Man-hours just aggregate calendar time contributed by multiple people (and ignore calendar days when no work occurs). But none of that has anything to do with goals.
lkrubner 8y ago
I've seen some young people who are very good managers, but I've also seen some absolute disasters. I've also seen some older folks who are absolute disasters. I shared a story about both kinds of manager in How To Destroy A Tech Startup In Three Easy Steps: https://www.amazon.com/Destroy-Tech-Startup-Easy-Steps/dp/0998997617/ https://www.amazon.com/Destroy-Tech-Startup-Easy-Steps/dp/09...

LoSboccacc 8y ago

> Sprint are the root cause. I disagree. there's nothing inherently wrong with short iterations or a predictable release window. trying to do agile with fixed budget, fixed requirements and a fixed timeline is the core issue. most of the problems with agile, including "devs having to do this much tasks or die" within each iteration, comes from trying agile on an inflexible plan.

wirrbel 8y ago
What's wrong is to have a team wide iteration xycle instead of iterating within features / use cases
- pas 8y ago
  Why? Fixed team global sync points sound great to me. Fixed interval measurement windows also help with correct burndown estimates.

rooam-dev 8y ago

I came to a similar conclusion and prefer Kanban to Scrum. If there are not enough tasks you pull from backlog, if it's too much then they get finished in next sprint. Work never ends, so why the need for extra overhead to group it into 2 weeks? I always see it as a "marathon", constant sprinting is no good long term. However, Kanban works as long the team knows priorities and can choose between good and over kill solution, which is easier said than done. Working in a good pace without a deadline is challenging itself, since you think you have all the time in the world.

_hardwaregeek 8y ago

I hate the term "sprint". The word gives an impression of desperation and short term thinking. You don't sprint when you're running a marathon; it's not sustainable. It's a superficial complaint, but names do matter.

matwood 8y ago
Let's rename it to 'checkpoint' then. Even in a marathon a runner is checking their time to where they are every X miles. The runner then adjusts their pace if they have a goal time. In software a checkpoint should result in the same behavior.
jrvarela56 8y ago
Just change the name to 'iteration'. Removes the speed/intensity analogy and reinforces continuous improvement.

sonnyblarney 8y ago

I really disagree with this. Sprint objectives are by no means arbitrary or meaningless - or any more so than other deadlines - they have value to the extent they are intelligently formulated. Sprints have a very important operational dynamic, in that they set a fairly clear, achievable, short term goal. Software is always a pandora's box, and left to their own devices, a lot of devs could work on the smallest thing ... forever. We are all guilty of this. Long term milestones (i.e major product iteration) are hard to internalize, they are vague to each individual even if they have meaning at scale. Sprints provide the means for large things to be broken down into achievable pieces, which much more strongly enable small teams and individuals to focus on that specific outcomes. Maybe they shouldn't be called 'sprints' maybe just 'mini milestones' or something ... but they are useful. Or 'waypoints'. Getting lost in a sea of software is very easy ... so setting 'waypoints' I feel is very, very useful.

bb88 8y ago
> Sprints have a very important operational dynamic, in that they set a fairly clear, achievable, short term goal. Lately, the trend with those using Jira in large organizations is to just "carry-over" what's not done in the current sprint into the next. And so instead of talking about why something didn't get completed, and how to resolve it quickly (move it to someone else, change the way it's done, postpone it until something else makes it easier), the work snowballs, with even more work getting piled onto the sprint. That's because while the dev team is agile, management deadlines often won't budge. The other problem is dependency upon another process/service internal to the organization that is not on your sprint cycle. Typically they have other, different priorities, which don't match yours. So they may get around to it eventually, which might mean a week to a month typically. I think Kanban is in someways vastly superior in these cases. You can still do "waypoints" at say every two weeks to see how things are moving along, but at some point if your company isn't "agile" then it really makes no difference if your team is.
brightball 8y ago
Checking in is useful. The problem from sprints comes when each one is treated as a deadline instead of just a point to check in, evaluate new information, potentially pivot. When they are treated as deadlines, the problems come. And there is no reason you can simply forgo sprints entirely...and still check in, see how things are going, pivot, evaluate new information. To this point in my career, I’ve never seen sprints present when they didn’t go down the destructive path for teams.

majormajor 8y ago

"Planning better" is a hugely valuable thing, if you can pull it off. You'll end up with less pressure, happier stakeholders, and less frustration with your own output. Even in a purely selfish better-for-the-team way: an accurate plan and capacity projection (relatively - if you have bosses who expect perfection here, that'll bit you) makes a great input into decisions about headcount, hiring, and project allocation. If you can't plan well enough to know you need to ask for help, you're screwed. Agile as I've seen it in the wild is easy to twist into "plan more verbosely" instead of "plan better," though. The most recent way I've seen this manifest is coming into a team that planned out each ticket in great detail when it came to execution - gotta maximize that committed/completed ratio - but invested very little in making sure they were planning the right thing. Someone would ask for something, it would become a ticket. But whether or not that was the right thing short-/medium-/long-term? That's a conversation that didn't have anywhere to happen. Another is confusing "producing more estimation artifacts" (subtasks, hour allocation, etc) with "investing the right amount of time in planning." Going from a 30 second story point estimate to a 2 minute subtask breakdown in sprint planning isn't what it takes to make an accurate estimate for a project.

joseph8th 8y ago

Sounds like management is using sprints to enforce deadlines and releases. Our team uses them to improve our ability to estimate, which in turn requires us to think each set of technical requirements through and anticipate issues before we start pounding keyboards. We use them to structure our work, but decoupled them from releases. The Dev team owns the sprints, but the business owns releases. DevOps uses Kanban however, because it works better for them. That makes us more flexible. Agile. It's been a years-long process but I'm really happy with our "Agility" these days. Our sponsor is the VP of Tech and he gets it (used to be our QA lead). If we have rollover we talk briefly about estimating better but it's not the end of the world, because we actually have gotten better at estimating. Some sprints we nail it. Other times we miss, but management isn't using those metrics as a bludgeon so it actually helps us to work smarter.

sebazzz 8y ago

The problem is not agile, it is an all-alige approach. It is at least in our case. Sprints are feature-focused, which leaves little time for software development craftsmanship: reducing technical debt, updating outdated dependencies etc. To give some context: We have multiple pieces of software we build and maintain for multiple clients. When a client requests some features, they buy some sprints and we do the work and then it's done. During the life cycle of the software there is a maintenance contract for service and support and resolving bugs. This does not have much room for software craftsmanship either. This is just where I work,but I can't imagine we are the only one working like this. This is an implementation problem, not an methodical problem. One of the ultimate causes is that our org is project based, so no project, no work for that client. And the software quality suffers IMHO.

kamaal 8y ago

Also 'move fast, and break things'. Without understanding what you are supposed to do. You move a lot without going no where, with a lot of broken things.

mcv 8y ago

Sprints are often misused and misinterpreted. They are not hard deadlines. A deadline is when there's going to be a real problem when you don't make it. When a new campaign, shop, whatever opens, the corresponding website needs to be there. That's a deadline. A sprint goal is meant to provide focus. You've got something to work towards, but if you don't make it, you don't make it. Presumably there was a good reason you didn't make it. It's good to examine that reason to see if that reason can be taken away, or otherwise it can be taken into account in planning. But it's not the end of the world if you don't complete a sprint on time, and you should certainly not work late to complete the sprint. I've worked in very successful teams that never finished a sprint on time. I think that's totally fine. It's not about the deadline, it's about the focus.