51–60 of 292 posts
Interesting idea. All I've experienced so far was "Agile Enterprise Edition" - cargo-culting all the agile terms, wasting developer time in overly-long standups, yet having a fixed, set-in-stone schedule and delivery plan. Hilarious.
> Issues may not be added to the sprint I don't see this happening, even if that's a good rule, because issues come up that take higher priority than existing issues.
I noticed that as well. That'll be pushed back against, and the leadership is going to decided that they must respond to SOME issues to appear responsive, and let's be honest, it's going to have to happen regardless of project ideology. There'll be some silly rule put in place that only priority "X" issues get looked at mid sprint, and suddenly every issue is going to be priority "X", and now someone gets to spend th…
The engineer's response to unplanned work should be "Go talk to my manager", and the manager's response must be "Wait til next iteration". If the team can't defend its own boundaries, it's hosed, period.
Why is the board not up to date? Because we just talked about all of that an hour ago and doing all of that over again is infuriating. What is the status of ticket x? Either wait until the next day’s status report/standup or start writing down notes you can reference. While you’re at it, just go ahead and put those notes in the comments on the board... oh wait.
How do you deal with a sudden bug in released version then? Or even bugs in the curent dev branch? All developers time is allocated to new features, there are no openings – so all the bugs are moved to the next spring automatically and we release with criticals? Edit: everyeone's answering with very good advice on how to handle it, but my intention was not to ask for advice for any situation I encountered personally,…
Non-trivial, non-urgent bugs can go to the backlog for the next sprint(s).
Non-trivial, urgent bugs replace go into the current sprint, with planned dev. being kicked down to the next sprint.
Earlier quoted context omitted.
I noticed that as well. That'll be pushed back against, and the leadership is going to decided that they must respond to SOME issues to appear responsive, and let's be honest, it's going to have to happen regardless of project ideology. There'll be some silly rule put in place that only priority "X" issues get looked at mid sprint, and suddenly every issue is going to be priority "X", and now someone gets to spend th…
Decent iterations cannot be done without immediate management playing defense, period. As long as anyone is allowed to interrupt the iteration, then iterations are just going through the motions and won't solve any actual problems - because the problem is a lack of control. The engineer's response to unplanned work should be "Go talk to my manager", and the manager's response must be "Wait til next iteration". If the…
I don't understand why the "sprint length" is this set-in-stone thing. "We do 3 week sprints, we never deviate". That's not very agile. Sometimes you've got very well-defined requirements on a large project and you could go heads-down for 3 weeks on something. Other times, you've got a good "phase 1" that would take 1 week to implement; so let's implement that, then plan the next sprint. Or you might want to take a sprint to just write more tests, upgrade dependencies, etc. Plan it, take a week, then lets resync.
The interlude week is used to decompress and give engineers time to plan their own schedules. They can work on whatever they want; they create the plan, create the tickets, and execute. Ideally it should have some thread of connectivity with the team's overall mission, even if only slightly. Leadership uses this time to plan the next sprint. There's a natural "bulk up" on meetings during this week that were avoided over the sprint itself.
Specifically: the planning and retros happen during this week. Most teams I've worked on put the Retro on the final day of the sprint. At one place it was at like 11am. This is crazy! Combine that with a typical Friday drop in productivity and you've just written off the entire last day! During a 2 week sprint, that's a full TEN PERCENT of the sprint. Instead, schedule the retro on Monday morning during the interlude, and full team planning on Friday before the sprint.
Often those interlude weeks end with work that's best classified as either "hackathon-style" (this is cool, not sure if we can use it right now but lets bank the code and revisit) or "infrastructure" (we've wanted this done for a long time, but it never got priority, we've finally done it, awesome). Burntout engineers will naturally schedule themselves less to do or easier things, like dependency upgrades; this is a great signal to management that something is up and we should talk about it.
Changing culture is really, really, really, really hard. Unless the company is tiny, I recommend looking for a better fit instead.
If you're getting burnout doing agile, you're doing agile wrong. Don't do sprints. Have a continuous backlog. Don't do overtime. Don't make estimates. Always do the simplest thing. Only ever do the most important thing, as defined by the stakeholder. I've written and talked about this at great length. The fact people suggest agile gives you burnout reinforces my experience that Scrum is largely misinterpreted and peo…
The business wants to know how much feature X is going to cost and when they can expect it. They need to know that, because they need to decide if it's worth it in the first place, or because they need to plan follow-up actions for when the feature will be done. If the developer doesn't make estimates, you're just forcing other people to make their own estimates, that they'll hold you to.
Do your best to break tasks up so that all tasks are the same size. Then work on tasks. You'll find a stable average of tasks per amount of time and that will let you forecast how long things will take, how much they'll cost, etc.
That's how you figure out when things will be done.
If you're getting burnout doing agile, you're doing agile wrong. Don't do sprints. Have a continuous backlog. Don't do overtime. Don't make estimates. Always do the simplest thing. Only ever do the most important thing, as defined by the stakeholder. I've written and talked about this at great length. The fact people suggest agile gives you burnout reinforces my experience that Scrum is largely misinterpreted and peo…
The business wants to know how much feature X is going to cost and when they can expect it. They need to know that, because they need to decide if it's worth it in the first place, or because they need to plan follow-up actions for when the feature will be done. If the developer doesn't make estimates, you're just forcing other people to make their own estimates, that they'll hold you to.