One change I'd suggest: drop the use of the term "sprint". Prefer "iteration" instead. Talking about "sprints" is a bad metaphor, and the metaphors we use do shape the way we think and act to some extent. IMHO, along with the "gap week" between iterations (which I vehemently agree with), this is part of avoiding the conditions that lead to burnout... if you're sprinting, sprinting, sprinting, all the time, bad things are going to happen. Not everything you do needs to be at balls-out, breakneck, full-sprint speed.
Agile Lite: Agile without all the burnout
61–70 of 292 posts
Re: Agile Lite: Agile without all the burnout
#62Working with agile for the last half-year.
while it does make people agile, i.e. stir things up with daily stand-ups etc, it also causes more chaos on the technical side.
anyone can pick up any stories, after a while there is nobody that is an expert in any domain, everyone knows a little about everything but nobody knows any subject deeper, no more domain expert. Now bugs took forever to debug, the whole group is constantly in panic mode and burnt out.
to make things worse, document is neglected due to agile's own philosophy and due to the daily chaos, and it makes development much much slower.
In short, agile gets everyone going and looking busy, but the product can never deliver because nobody knows enough to fix hard issues. Many of them are senior developers, the old model seems working better, a bit slower and quieter but products are out of the door with good quality.
Agile is bad from my experience so far, our product is embedded system that can't really be sprinted like those fancy front-end UI projects and such. Agile does not fit us well.
Re: Agile Lite: Agile without all the burnout
#63One of my biggest pet peeves is the pointlessness of standups. I have never worked anywhere where they did not immediately become a status update, which is (in theory) what the board is for. 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 star…
I was once a project manager on a team that does daily standups. What eventually happened was that the team would usually re-iterate what I say, or vice versa. It made me question what was the point of doing standups.
Re: Agile Lite: Agile without all the burnout
#64I prefer a structure of: variable length sprints + optional 1 week interlude. 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…
The two week sprint is for management. So that all the stakeholders only have to travel to "the pit" once every other week for a sprint review. It is vital that every team finishes the sprint at the exact same time. If teams are out of sync the stakeholders have to visit once a week or more.
Given how important all these managers are to the organization, they need to be unloaded with trivial tasks such as playing with their phone during a sprint "review" (which is actually a demo).
Re: Agile Lite: Agile without all the burnout
#65If 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…
I agree with most of it minus the "Don't make esitmates" part. Without making some sort of estimate things just don't work.
I guess maybe it could work assuming you fully control a single product. Everywhere I have worked we need the estimates simply for coordination of all the moving parts.
Re: Agile Lite: Agile without all the burnout
#66Seems like Waterfall with extra steps
Re: Agile Lite: Agile without all the burnout
#67If 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…
> people incorrectly focus on sprint commitments.
I think it's often the over approach from the manager/PM side: they will be looking for a methodology to have estimates and team commitment, and Scrum will be an option.
There is an awful lot of PMs who will candidly explain that they don't really care about the methodology, they just need stuff to get done and know when.
Re: Agile Lite: Agile without all the burnout
#68If 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…
I agree with most of it minus the "Don't make esitmates" part. Without making some sort of estimate things just don't work. I guess maybe it could work assuming you fully control a single product. Everywhere I have worked we need the estimates simply for coordination of all the moving parts.
I think by estimates they might mean deadlines. It’s well worth asking, as an engineer several questions like: “How complicated is this? What are all the moving parts? Whose going to need to be involved to get this out the door?”
But it’s counter productive sometimes to say “ I think feature X will be completed by Y” and then that estimate turns into a deadline.
Re: Agile Lite: Agile without all the burnout
#69Earlier quoted context omitted.
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.
Nobody should make estimates. They're always wrong. 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.
That is bull.
Some tasks have a high degree of uncertainty. Others don't.
Back when I was using a ruby-on-rails style framework (in PHP) I would frequently get 20 hours of work estimated properly down to 15 minutes when it came to adding simple features to a web application.
If on the other hand you are trying to figure out the gap between what the documentation says should work and what actually works, that is hard to estimate.
Re: Agile Lite: Agile without all the burnout
#70Earlier quoted context omitted.
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.
Nobody should make estimates. They're always wrong. 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.
That act of breaking up and organizing tasks of the same size, that's what estimation is. This feature has these tasks, historically we complete these tasks in this time, so here's a hard minimum for a completion date (which implies cost). Slap on an appropriate fudge factor for dealing with other teams, testing and burn in, and general error bounds as needed.
You've described scrum, what you're doing is scrum.