6 ms·
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 fo
by 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 agoScrum 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 agoThe 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 agoPO 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.
- khalilravanna 7y agoI see both options being shot down here so what's one possible alternative that does work?
- loopz 7y agoWhat works depends heavily on the circumstances and the team (people first). What is to be accomplished: software delivery, operational quality and/or user/customer interactions? Are the responsibility boundaries clear or not? When overall structure is clearer, it is more straightforward to decide who are the best decisionmakers for the team.. What works for one team, might not for another. It's a good idea to have semi-stable teams as there is significant overhead creating temporary teams and disbanding them. When there's no true need of urgency or the deadlines are outright fake, kanban and maturity may make a good alternative to scrum/sprints. It may even allow for some flexibility how to allocate people and borrow temporarily from other teams. You don't want teams to silo down, which they do the minute they are formed to start healing the wounds. Teams will need clear responsibility boundaries to be able to make effective decisions, while also granted the slack, incentives and psychological safe learning environment that fuel the necessary and logically next steps.
- ratww 7y agoThere's a perfectly healthy middle ground where POs are the gateway to new tasks but don't isolate the developers from the rest of the organization, nor disregard developer input. And since we're talking about Scrum, PO and Developers (traditionally) supposed to sit together with stakeholders for Review meetings, gather feedback from them and provide input on the next tasks.
- strictfp 7y agoSprints 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.
- braythwayt 7y ago+1 Sprints also have the pleasant effect of forcing some coherence onto work. In the Old Days, teams might build software like a layer-cake: All the lowest layer, then the next layer, then the next, and so on to the top. So at the beginning, we’d be building infrastructure based on projections (a fancy word for “wild-ass guesses”) of what the subsequent layers would need. You can, in theory, do that in sprints, but with an emphasis on delivering “working software,” sprints would help devs and stakeholders pick very small end-to-end increments and build whatever was needed to make them work. This kept everyone focus on work that was known to be needed, and since you were building a complete increment, the team would be building the infrastructure at the same time it was designing and building the functionality relying on the infrastructure. This kind of thing has its own failure modes, of course, but it eliminated a number of catastrophic project failure modes without even getting into the value of delivering working software sooner and revising priorities based on feedback.
- hrktb 7y ago> This enables devs to get trusted by management I am curious about that “trust” part. In your model what happens when management doesn’t trust devs ? do devs trust management ?
- strictfp 7y agoHaving a steady stream of deliverables and seeing that the devs can deliver on their promises, enables management to shift from control to guidance. That's not to say that it always happens, but I've seen it work. Getting development done has traditionally been a game of getting developer attention. Scrum is one way of clarifying the contract between the stakeholder and the development team. I'm sure there are others too.
- pjc50 7y ago> 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.
- SideburnsOfDoom 7y agoYep, 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.
- gowld 7y agoSprint's don't have deadlines. That's the point of "agile". They have checkpoints.
- mannykannot 7y agoSprints are one of the ways that management, with the help of a cadre of consultants, took control of agile while nominally endorsing it. That is not to say that sprints do not serve a purpose -- several, in fact...