4 ms·

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 t

• 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.
  • sonnyblarney 8y ago
    "And there is no reason you can’t simply forgo sprints entirely...and still check in, see how things are going, pivot, evaluate new information." Because 'checking in' on something doesn't create incentive to completion, or actual material outcomes. You can have 'the software developers doing stuff and meeting objectives on their terms' - or have deadline driven wherein business/software objectives are set and people move towards them. The problem with the objection to 'deadlines' is the fact that inherently software is not created for it's own aesthetic sake, or for it's cleanliness, or architectural integrity, or some arbitrary measure of quality. 'Time' is the key ingredient often missing from the architectural/development equation, because 'time is money' both in cost, and opportunity cost. 'Time' (which implies cost, ROI etc.) will likely be driven as a business impetus and has to be put into the equation in very serious terms. Many devs might complain about 'technical debt' or 'messy software' or 'some things that don't work' - but in reality, those situations may actually represent optimal business scenarios. It may not make sense at all to make certain systems perfect, or at least, in the short run or on first iteration. In other terms, the 'QoS' expected is I think always way higher on the dev side than real business terms may mandate. What devs view as 'a mess' may be a perfectly good condition. 'Building the wrong thing' is the #1 reason that companies fail, not 'technical debt'. If customer outcomes are generally good, revenues are increasing, then technical debt is normal, and it's a function of pragmatism at that point more than anything. Taking too long to build something, or taking a long time to build something that is 'the wrong thing', is almost guaranteed death. Finally ... I think milestones with deadlines are important also for the psychological and organizational factors. In NATO, for examples, all 'orders formats' are the same. Any NATO General, from Polish to American, gives a set of orders that are crudely similar to those given by section commanders to their privates. That's to enable operational efficiency. The 'most important' part of the orders are the mission objective with a timing. Literally it has to be said twice. I'm not kidding - while giving orders, the mission statement is verbally repeated. Always. This is because in the fog of war 'everything goes wrong', nothing goes according to plan, things break, people die, obstacles abound, opportunities arise (just like at a startup) - but if everyone involved knows what they need to do, then they can adapt and make it happen by hook or by crook. So 'the gap at grid reference 0000 1111 needs to be bridged by 0600h tomorrow so 6th calvary can cross with heavy tanks' is a mission. Everything else about the plan is secondary, everything could go wrong, but when individual sappers/soldiers, NCO's, junior officers all have that 'this spot has to be gapped by 0600 for heavy vehicles' ... then they can rally around it whatever happens. Obviously there are tradeoffs and obviously devs have to participate in the establishment of their own deadlines and objectives ... but in my view it has to be done, and it's healthy to break it down.
• jeffdavis 8y ago
  Breaking large tasks down is incredibly difficult, and often dismissed as though it were easy. In fact, that's really the main challenge in engineering. It's easy to think something is a step forward, work on it, then realize it's a bad idea later. If you know what the individual, bite-sized tasks really are, you are nearly done with the project.
  • sonnyblarney 8y ago
    " really the main challenge in engineering" It's a mostly a business problem. Not mostly an engineering problem. Cost, product issues, customer issues, support issues, IP issues, margins, positioning, partnerships, finance, M&A, staffing - these are all part of the equation. Eng is only one piece.