TL;DL
Ignore all existing literature and experts' previous experience.
Simple.
Agile Lite: Agile without all the burnout
21–30 of 292 posts
Re: Agile Lite: Agile without all the burnout
#22As a developer, seeing another developer suggest that they just take a vacation and leave the project leads and stakeholders to talk about what should be done in a month is really weird. That will not lead to the absence of a death march - it is a recipe for a death march. Not only will you not have an accurate assessment of the tasks but they will not be ordered correctly, and likely way overscoped for the timeframe…
I agree. The team (which includes developers) should be the ones pulling issues into the sprint. Leads and stakeholders can prioritize on their own, but again developers need some say in that process because technical issues my drive some prioritization.
I get the concept, but a week off seems a bit extreme and a hard sell. The team should already be working in some slack time in the sprint. The reason for slack time is that it gives a bit of a cushion if something runs over, and it keeps people from burning out. The other big upside for those on the outside is it helps build confidence that when a ticket is pulled into a sprint it almost always get completed.
Re: Agile Lite: Agile without all the burnout
#23Agile burnout means that there are to many items in the sprint, and that your estimation points / priority is not right. Nobody needs to burn out when you do a good estimation planning that fits into a 40 Hour workweek. Every hour above that is less productive and will work towards a burnout.
Re: Agile Lite: Agile without all the burnout
#24If 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 people incorrectly focus on sprint commitments. If Scrum is so commonly misinterpreted, it is flawed.
https://www.linkedin.com/pulse/scrum-makes-you-dumb-daniel-j...
Re: Agile Lite: Agile without all the burnout
#25Interesting 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.
Same here: it's make-believe work.
Re: Agile Lite: Agile without all the burnout
#26How 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,…
Apply the five whys. Why do you have a critical bug in the production release? Is is environment-specific? Did the released code not match requirements? Or were the requirements themselves wrong?
It's not "What do you do about critical bugs?", it's "How do you stop having critical bugs so they don't disrupt your development process?" If criticals in production are a regular part of your life, then you're doing something wrong as an organization.
But to answer the question itself... if you have a critical bug that requires enough development resources to prevent completing the iteration successfully, then the iteration is ruined. End it right there and start over with a fresh planning session. Yes, everyone will howl. Pain is your body telling you something is wrong.
Re: Agile Lite: Agile without all the burnout
#27The key thing people miss about agile (and project management in general) is that you have to tune the process to the situation. If you look at the PMBOK (Project Management Book Of Knowledge) it is really a comprehensive list of all the things you might have to think about while running a project. All of them are relevant to every project (e.g. hiring, communicating with the public) but some need a lot of attention…
It's ironic to me that even this "Lite" version of Agile (Scrum really) clearly puts process over people and conversations. I think it's great to have a starting point of a known process and tools, but we should have much more focus on adjusting to the concrete problem, the people and larger organization.
It's ridiculous to me that this proposal is set to reduce burnout, yet we still seem to commit on what gets done and by whom by the end of a time period that has the asinine title "sprint". What we are doing inherently deals with new and unknown, we usually aren't building, cookie cutter, prefab homes. What we are doing is certainly not a sprint, it's not even a marathon. Nomenclature like that creates a culture of heroes and cowboy codes who will burn themselves out. Hard rules like "can't change or add to the backlog" don't serve anybody. Nobody wins of the ship keeps moving in the wrong direction or stops. Let's just have a conversation! People should work together as a team and communication is paramount to a successful team. Let's not process our way around that and solve that problem!
Re: Agile Lite: Agile without all the burnout
#28I would not suggest a full week off, a lot of people would not have anything to do in 1 week every 2 other weeks.
Instead give everyone an extra day off, a 3 day long weekend. It's easier to have a recurring appointment that way, like exercise or take a theater class or whatever.
I've been working 4 days a week for the past 3 years and I'm not going back to 40h/week.
Re: Agile Lite: Agile without all the burnout
#29If 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…
Scrum is a framework to achieve "agility" and people forget that. The point is agility, not scrum.
Re: Agile Lite: Agile without all the burnout
#30The key thing people miss about agile (and project management in general) is that you have to tune the process to the situation. If you look at the PMBOK (Project Management Book Of Knowledge) it is really a comprehensive list of all the things you might have to think about while running a project. All of them are relevant to every project (e.g. hiring, communicating with the public) but some need a lot of attention…
This.
That is why the retrospective meeting is at the heart of agile. A truly "agile light" setup would be:
Every other week, do a retrospective.
That's it!
On the retro, ask yourself 3 questions (or work with these 3 themes):
1. Is the way we are working helping us, and the rest of the organization, make the right decisions and reach our goals in an efficient way? If not, what needs to change?
2. Is our understanding of the customer (or whatever system we are trying to improve) correct or are we basing our decisions on the wrong assumptions? If so, what do we need to learn?
3. Do we have a clear picture of where we are going and what we want to achieve and how that is aligned with the goals of the organization? If not, how do we course correct or make our progress towards our goals clearer?
There you have it: the retrospective and the 3 dimensions of agile.