51–60 of 462 posts
I feel like in a lot places the ultimate purpose of sprints is to let executives think they can see data that represents the amount of work getting done down to a fine level.
Earlier quoted context omitted.
What in Scrum is about keeping managers happy?
Some things that come to mind: - burn-down / velocity charts - retrospectives - poker sessions - daily stand-ups - user stories and related tickets (eg in JIRA) There’s probably more ... Perhaps these things are not necessarily meant to make managers happy, though managers do seem to like this stuff. As a dev, I prefer a more fluid approach without all the rituals. In the start-up I joined a couple of months ago, we…
When I started at my current job, I naively looked at the bugs and tasks assigned to me, and started picking and fixing the highest priority tickets.
Then I was informed, "Oh no, that's not how we do things here. Don't look at the priority, just work on what is assigned to you in the current sprint."
I had never heard of sprints before.
More recently, I had a conversation with my manager and asked, "Do we really need sprints? I've been in this business a long time. 10, 20, 30 years ago we didn't have sprints and somehow still managed to produce great software."
The reply was "But if we didn't have sprints, how could we possibly measure the team's productivity and individual productivity?"
I knew I wouldn't win this debate, so I politely let it drop. I just wanted to sow some seeds of doubt.
In all fairness, my manager is a very reasonable person. But when this devotion to sprints is ingrained in the entire company, it is hard to question it or get away from it.
At least we don't do daily standups!
Earlier quoted context omitted.
What in Scrum is about keeping managers happy?
Some things that come to mind: - burn-down / velocity charts - retrospectives - poker sessions - daily stand-ups - user stories and related tickets (eg in JIRA) There’s probably more ... Perhaps these things are not necessarily meant to make managers happy, though managers do seem to like this stuff. As a dev, I prefer a more fluid approach without all the rituals. In the start-up I joined a couple of months ago, we…
- burn-down / velocity charts: Teams use this at standups to make sure their sprint isn't drifting. That's why a burn-down should be tracked in hours and not points. With points, the data isn't actionable in a reasonable amount of time. The the team sees a problem, they might make use of a pre-determined emergency procedure to address it.
- retrospectives: Yeah most retrospectives are horrible. Retros should be like post rocket test - examine your telemetry deltas to see what changed (edge cases, governance,compliance, desgn, etc.) These conversations are not forced, but good teams always repeat the same data analysis unless they intentionally change it.
- poker sessions: Yeah this is totally misunderstood. Pointing stories is about snap reactions to comparing difficulties and complexity, and that's it, move on. Teams will tighten up estimates when they do an implementation plan in sprint planning. So they don't sweat estimates.
- daily stand-ups: The whole team is responsible for the sprint backlog, nothing is assigned, everything is volunteered. So if you're working on something that is going south, or you have some extra capacity, let your team know about it. The team will work together to scale capacity to get things done, which is how they can disappear on Friday afternoons.
- user stories and related tickets (eg in JIRA): Well yeah, Jira sucks. So do all the other major backlog tools. Jira gets addins, but the fundamental approach to backlog development hasn't changed in a decade. (I'm working on a soln from scratch, btw).
Also, user stories are meant to be work-items with enough signal so they can be executed with certainty in a sprint. So that means a lot of refinement to the left of the story must occur to get rid of the noise (epics to features to stories to tasks). Once a team says a story meets their definition of ready, that story can be scheduled for a (timely) sprint. Team members may be doing hard-core story refinement because of some technical hurdles, so their time outside of development during sprint can be pinned down with the team's capacity plan. BTW, capacity plans and implementation plans belong solely to the team. They're nobody else's business, including managers to CEOs.
Earlier quoted context omitted.
Daily stand-ups, the main benefit of which is that managers (EMs/PMs) get daily updates on status. Sprints themselves which promise that a certain amount of work will always get done, without any free time being wasted. A lot of the ceremonies in general are mostly helpful to the EM/PM. How many things that you're doing are actually improving how you get work done? Especially when you consider how much time is spent…
This may sound like a no true Scotsman argument, when our company was trained by one of the scrum founders about 18 years ago, they were very clear that the daily standup was only for the team members, and the scrum master. (The scrum master could be a team member, and rotate btw). Managers were not allowed or invited to these. The only thing product managers and engineering managers would participate in and give fee…
One of my least favorite standups was even worse than a ceremony for the manager: The manager and the Product representative were there in every single one, but they didn't actually pay any attention: Another 20+ minutes of "parking lot" would be added after the 5-10 minute process as they asked the team all the random questions they thought they needed, in which they also proved that they weren't actually paying attention to the actual updates, or the tickets, or anything. In practice, a sequence of 1:1 meetings where everyone was stuck watching, because after inquisition to one person, it'd come after another.
In practice, I don't think I've seen scrum run without a manager in standup, ever.
nobody has ever done "waterfall", it's a strawman created to explain why traditional project management doesn't work in software development. The fact that the article starts with "in the good old days of waterfall" takes away every expectation that I'll read anything intelligent in the article, I believe this post doesn't deserve your time and definitely doesn't deserve mine.
I've learned to hate software process. If you have team sizes set sanely and empower devs to do what they need to do in order to accomplish the goal, they'll be fine without the management overhead of arbitrarily imposed productivity flow. Agile et al, along with 99% of the features in ticketing systems, exist to make managers feel like they are justifying their paycheck. If you are a manager and this makes you angry…
But what does it mean to "empower devs". Do you give them requirements and say I'll check in on deadline day in 6 months? Presumably you would still use iterations to track progress, Epics/Features to break down requirements, some kind of estimation to track if you're ahead/behind schedule? I certainly wouldn't go back to Waterfall days, but I suspect many current devs never experienced that.
If you don’t trust your team to be productive for 2 weeks without communication something is deeply wrong. Individuals should be in constant communication, but few things need to be said to everyone. Scrum style management may be useful for highly dysfunctional teams, but it frequently adds a great deal of unnecessary overhead.
Earlier quoted context omitted.
> Daily stand-ups, the main benefit of which is that managers (EMs/PMs) get daily updates on status. The scrum guide fairly explicitly states that managers should not attend or be part of stand-ups unless they're actively involved in the work as part of the development team.
That's hard to imagine. In big tech it's the team manager who decides that standups should happen and when (maybe this is an expectation from higher-ups). He always joins unless running late.
Then it's not a SCRUM process at all. Case solved.
Earlier quoted context omitted.
Some things that come to mind: - burn-down / velocity charts - retrospectives - poker sessions - daily stand-ups - user stories and related tickets (eg in JIRA) There’s probably more ... Perhaps these things are not necessarily meant to make managers happy, though managers do seem to like this stuff. As a dev, I prefer a more fluid approach without all the rituals. In the start-up I joined a couple of months ago, we…
And sprints! When I started at my current job, I naively looked at the bugs and tasks assigned to me, and started picking and fixing the highest priority tickets. Then I was informed, "Oh no, that's not how we do things here. Don't look at the priority, just work on what is assigned to you in the current sprint." I had never heard of sprints before. More recently, I had a conversation with my manager and asked, "Do w…
I once found that a system was getting a little expensive. As, AWS was billing us a million a month expensive. I figured this out, and came up with a plan that would cut it down to 80 thousand by spending 4 days: You know, a mild, 11 million a year of savings. Management insisted that the work had to go through scheduling, and intake, a process that would involve zero developers looking at anything, but would delay doing the task a month and a half.
And no, nothing the team was working on came even remotely close to that ROI. Following the process just cost an extra 1.5 million dollars.