I think agile has always suggested modifying to fit the team - so then do we need an agile light, or just critical thinkers doing whatever agile provides actual value?
And the industry pretty much modified agile in a way that gets the most work out of people, regardless of fit. So yeah, sometimes we do need something that's written as a "manifesto" to remind people what agile actually was supposed to be.
But when your adaption consists of using your existing methodology with some agile concepts, but no retrospect on the methodology itself, you're not agile by definition.
What this "Agile Lite" puts right in the center is to split up your goals such that you can make meaningful work in a 3 week window, and track it asynchronously. Managers are free to have an overall plan for release in 12 months, as long as it's split up into units of work at most 1 day long.
What I think I read from your comment is that if you couldn't get this to work in the "Old" agile, you will fail with this as well, and I agree.
Personally I think that asking how teams do agile differently and how team members change agile practices can be a good gut check to see what agile is like at a company. If some teams do scrum and some do kanban or some teams have daily standups and others don't, then agile is probably more developer driven. But if the answer is something small, like the time of the daily scrum then agile's probably management driven.
As 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, and you get no chance to say no. Technical minds / engineers in the room early and often is critical to success - otherwise you’re just told what to do instead of architecting it the “right” way.
Communicate when you need to but try it all for a sprint or two (really, Standup is a hardship? You may not be doing it quite right), then drop after the team finds a rhythm.
Edit; after reading the author’s other works the burnout seems to be centered on a big push from stakeholders to accelerate and keep going so a sprint is seen as a reset - kinda like a new day dawning in a news room. You can plan-in your work to avoid this and still continue to make progress but it does take some discussions with leadership, or at least a clear justification about why this week is exploratory instead of hands-on. Done it many times. I would not suggest changing the whole method just to accomplish this, however - a process fix for a problem like this won’t necessarily help.
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.
Agile has never been about predicting what you will do during a spent and then having slack or crunch time. Agile is about ranking your work by priority and dependency, setting meaningful milestones, and then adjusting your estimates frequently to avoid false promises and react to changes in the environment. If you don't finish planned work in a sprint, that is a planning success because after only a brief 2-4 week delay you actually know your performance against estimate and got clear information about how much you can do in a month, and a better chance at estimating what you can deliver next month.
> If you don't finish planned work in a sprint, that is a planning success...
In practice, most companies don't do this. They mark it as a failure and put it in red on the the big screen for all to see. Too many reds and there's disciplinary action.
I'm not sure the author is advocating for no developer presence during the planning period.
> The first week of each month is spent with project leads and stakeholders defining the upcoming sprint
At the very least, I'd suggest that developer leads or engineering managers are stakeholders and therefore involved. They should be liaising with their development team (also stakeholders) during the planning phase.
Perhaps this sentence is overstated:
> It is an intentionally light week and many people may simply take the time off to paint or surf or whatever.
People should perhaps take SOME time off to relax, but likely not the whole week.
I agree. I didnt read that as an invitation to take 5 days off every month, therefore advocating 60 additional holidays in a year.
I saw it more as an opportunity to catch up on "other stuff". Maybe a tool you wanted to work on to make your work life easier, or leave a little early to wrap up taxes, or do some PoCs etc. to see whether a refactoring idea you have is actually feasible or not.
Yes, this is more along the lines of what I'm talking about. I'm advocating common sense over religious adherence. Do what works for you.
I am saying there's a lot of burnout in the tech industry and it's at least partly a process problem.
Maybe it's just me and I'm "doing it wrong", but I think it speaks to the issue that the suggestion of "taking it easy a week out of every month" is met with cries of "This is madness! It will never work!"
You may want to look at some of the arguments for "slack" in agile. Other agilists have thought about this from various angles, from scheduling it via WIP limits in kanban to dedicated 1-2 days at the end of a sprint. You're not "painting or surfing or whatever." At the same time, you can't capitalize that, and capitalization drives a large portion of IT.
Edit: I misread this to mean “all devs take a week off” instead of “a light week in collaboration on some backlog stuff” - that makes total sense.
I also misread the "first week" stuff to mean that you leave the room and take a week off.
Having a light week while this is happening makes sense. It ends up being light anyway while the transitions happen. Apologies for the misread.
As for madness - I was not at all implying the suggestion was madness, and different things work for different teams / projects. I personally find standups are super helpful so I wouldn't want to get rid of them. That regular cadence it creates is very helpful in making sure we all stick our heads up and incorporate what's going on around us. If your teams are doing this already without the regular touch-points, that's awesome, but I find that with most teams that is a learned thing that takes a lot of time, and regular scheduled places to update are important to success.
I read it as a proposal to declare 36 weeks a year off-limits for days off, because, you know, there are those well-defined special weeks where vacation days are supposed to be spent.
Ah! My initial read on this was “devs take the week off and the project leads and stakeholders do the work.” The “with” did some work that I interpreted differently. That makes sense.
It says that the sprint planning takes about 45 minutes.
What I take that this means, is that there is a backlog with stories and tasks which was created and refined by the dev team. These stories include specifications, estimates and more.
So what the project leads actually do, is to decide which of these backlog items will get into the sprint. That's all.
Yep. If everyone’s updating issues in the ITS, it’s easy to plan a sprint. Priorities are mostly already assigned and the sprint planning meeting should be more of a sanity check.
Engineers are only out of the loop insofar as they have fewer meetings where they’re sitting around waiting for their turn to speak. If they want to weigh in, they should, and nobody is stopping them.
So is the burnout because you’re just grinding all the time on tightly defined stories and you feel like there is no room to slow down? Legitimately curious and I appreciate you writing this up and putting it out there.
It's not even tightly defined stories, it's just teams working too much with no downtime, no time to slow down and catch your breath. There are always more things to do than time to do them, so unless lines are drawn the default is perpetual overwork.
Many seem to freak out at the concept of working less. Yet the 40 hour work week was considered radical at one point. Googles 80% time is by most accounts not a real thing, but it's a start. I'm at 75% time here. Then there's 996 if you want to go the opposite direction.
Sure, if this dialog is happening the whole time that makes sense, but burnout also seems like something that would be dealt with using the backlog - make time for exploration, test spikes, learning, etc. If all this work is well defined already and the backlog is owned by the devs, that seems like a solved problem. If, however the devs are actually spending a boatload of time refining stories before planning then sure, take a week off while others talk about it, but that has a bit of a smell to it also in terms of a happy medium.
If the overall message is “slow down sometimes” then I agree 100%.
Pah, I've not seen Agile cause burnout at all. Far from it, the way sprints become long slow walks and stories move from one sprint to the next, at the altar of 'Agile' and not 'Delivery', developers appear to be under way less pressure than in older forms of project management. With, you know, deadlines...
Well, sort of by definition, if you're doing "agile" and it's causing burnout, you're not "doing it right", but that seems to be the crux of the problem - every place I've ever worked that has tried to adopt a mindset of actual agility has almost immediately fallen back into the authoritarian command-and-control centralized decision management style that dictators prefer: "tell me everything that you're going to do and exactly how long it's going to take and then I'll argue with you that it shouldn't take that long and blame you when it takes longer".
The 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 for some projects and others don't.
I've worked on "A.I." projects where the sprint involves running a batch job that might take two days if it all works right. If it doesn't work right you might have to retry a few times.
When I was in charge of that batch job I would start it as soon as possible, sometimes with a week and a half to spare. Whenever somebody else was in charge of it they would start it with half a day or a day to run and we would blow the end of the sprint.
I blame the continuous stream of "urgent but not important" communicates generated by agile for that.
The timeboxing of planning is also a very bad idea. I worked at a place where we had a timebox of 2 hours for planning but really after that we were nowhere near a realistic plan for the sprint and it would take another 2 or 3 days of knock-down, drag-out meetings that would leave us all exhausted to understand what we had to do. After that the work was mostly downhill, at least the way I saw it, but one of the other team members would consistently burn the midnight oil at the end.
Often agile "teams" have a "normalization of deviance" situation where they have to do one thing (or say they are doing one thing) so they can say they are sticking to the process, but actually do something entirely different to get the job done.
>Often agile "teams" have a "normalization of deviance" situation where they have to do one thing (or say they are doing one thing) so they can say they are sticking to the process, but actually do something entirely different to get the job done.
You’ve succinctly defined the problem in a very profound way. A verbal punch to the gut for sure.
> I worked at a place where we had a timebox of 2 hours for planning but really after that we were nowhere near a realistic plan for the sprint and it would take another 2 or 3 days of knock-down, drag-out meetings that would leave us all exhausted to understand what we had to do.
Wow! Sounds like decision-making processes needed tweaking even aside from Agile practice.
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!
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.
I would say that retrospectives are the biggest waste in agile in my experience.
For one thing, retrospectives often come at a time when everyone has been busting ass for a long time and they just want to go home. If you put it off till next week then it seems like another distraction.
Like the planning meetings, the timebox for a retrospective is often wrong. In some cases things went smoothly and there is a little to say. That is where you should be. In some places you budgeted 45 minutes but there really is a day worth of material.
On top of that in many (most?) firms there is no sense of psychological safety. Often the real message is that the process is 99% bull but you can't say that in a meeting which is claimed to be about continuous improvement but is really about how to rearrange the deck chairs on the titanic.
In his book "Good to Great", Jim Collins points out the use of the word "alignment" is a bad smell. In a healthy organization there is alignment, naturally, built into it. If you feel like you have to paint alignment onto it after the fact you are just causing more misalignment.
In some cases things went smoothly and there is a little to say.
Has been my experience (on good teams.) After a while, you tend to gel pretty well and don't need to spend that much time introspecting. The issues raised are either generally intractable organizational problems (that'll never get fixed), or fairly minor, and on several teams I noticed that retrospectives tended to feel pretty similar after a while (To the credit of the team, at that point we were like "we probably don't need retrospectives every sprint.")
> when everyone has been busting ass for a long time and they just want to go home
This sounds like a smell. You should not be busting ass and have everyone feel like they just want to go home at the end of the sprint. You should be working productively every day without burning out. Perhaps the team is forced to make too many commitments? Kind of sounds like it from your other comments.
Judging by my retros, I think other dev teams trying this will rapidly find that the answer to all 3 questions can be “no, but there’s nothing we can do about it!” Past a certain company size/amount of bureaucracy, simple agile seems nigh-on impossible.
Good points. I would rather have these answered in planning, rather than a retrospective. If these questions need to be asked after every week of work, that's a sign that the retrospectives are not helping much.
>The timeboxing of planning is also a very bad idea. I worked at a place where we had a timebox of 2 hours for planning but really after that we were nowhere near a realistic plan for the sprint and it would take another 2 or 3 days of knock-down, drag-out meetings that would leave us all exhausted to understand what we had to do. After that the work was mostly downhill, at least the way I saw it, but one of the other team members would consistently burn the midnight oil at the end.
If your backlog is properly groomed and you have sufficient time for planning and the team has the last word on how much it tries to take in, then it works beautifully.
If my team was to have that problem, it would come up during the retro, we would add a few more hours for the planning event, hold more or longer grooming sessions, refuse to plan work which we can not yet estimate because the requirements are not clear, etc.
And btw, your "implementation of Scrum" wasn't working properly; probably because you weren't living up to the Agile principles.
Telling your developers to bugger off for 1 week every month will never work out. They still need to be at the office, but they can pursue learning, help with planning (this is critical), or focus on other development tasks they actually want to make.
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, but rather as a criticism of published document. It's written as if it covered all the bases, but it doesn't cover bugs.
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.
> If criticals in production are a regular part of your life, then you're doing something wrong as an organization.
I believe that may be slightly idealistic - a test case doesn't get covered by the stakeholders and suddenly once the solution is in, it suddenly pops up its ugly head. It takes a ton of self-awareness and resources for a project to know its every use before it gets to the end user.
I've seen this handled a few different ways. What you do is going to depend on the size of your team and your current business context. Like the rest of engineering, there are few hard and fast rules, you have to weigh the trade-offs.
One approach is to prioritize all bugs before all features. This is the Joel Spolsky approach. In a typical sprint-based environment, this basically means that available work effort is allocated to bugs, and only remaining work effort is allocated to new features. The Google SRE model (as I understand it) tries to moderate this by basically saying the team has some flexibility in work allocation between bugs/features unless certain SLOs are missed. When that happens, you go full Spolsky.
But that doesn't really address the "what if a critical bug comes up mid-sprint". To address that, you basically adopt an on-call support model. Each sprint, one (or more, or a half, etc.) are assigned to be the support person. They triage any issues or bugs and address them as best as possible. It really helps if there is a rotation, just like your operations on-call rotation. In fact, it's best if you view this as the "escalation level" from your operational on-call rotation. You can provide a similar resource for marketing or other kinds of events as necessary. The benefit is that you have an up-front acknowledgement of the level of investment needed for responsiveness, as well as being able to provide folks with periods of interruption vs. periods of deep work, and share that burden.
Lastly, I think it's really important to separate "release" from "sprint completion", especially in a SaaS environment. If you build your CI/CD and release processes around releasing at the end of the sprint, you end up building a very inflexible infrastructure. It's much better if you can release often, as work is completed. So, if you have a small feature ticket and you tackle it early in the sprint, ship it right away. If a bug comes up, release the fix as soon as it's available. I've been on too many teams where you have an inflexible release process tied to the sprint. When something comes up, it interrupts the whole flow to get something done. So, "end of sprint" != "big release".
Yes, small releases are a huge part of making this work. "We can't do short iterations because iterations are so much work!" is the core of resistance. Something's going to go wrong, and we have this heavy bloated religious "deployment" ceremony with ten people on a call for six hours and how on Earth could we do that once a week? Yeah. We can't do short iterations because of all the crap we do because we do long iterations.
I'm always paraphrasing Kent Beck... if you can't write your requirements on a card, you need to use a smaller card.
If we can all agree that "shipping" is a feature[1] and that "shipping faster" is a competitive advantage, then "shipping fast" is probably one of the first features we should invest in as a team, from leadership to private chef.
If it takes 10 people and six hours to accomplish the release of even the smallest of features, then it sounds like there's a bug with your "ship fast" feature and the team should invest some or all of its resources in fixing that. You probably can't do it over night, but you gotta chip away at it over time at the very least.
If you are looking for justification backed up by real world numbers, I highly recommend the book "Accelerate" by Nicole Forsgren, et.al.[2]
Yeah, I know. And I've read the book. But I work in enterprise devops. This is the reality of many, many teams. Which means there's a lot of unnecessary process that needs to get tossed and a lot of automation that needs to be built in order to do short iterations and get out of the 3-6 month window.
Have you considered giving it as a gift to your peers and leadership? I really think it's a great read and resource for anyone trying to sell organizational change.
I wonder if any of those "automation needs" could be turned into startup ideas?
I actually tried a startup in the monitoring space, but sadly failed (it was great fun losing $100k or so, tho... well worth the experience!). But the automation needs problem is more a consultancy thing than a product thing. There are lots of products. Teams buy them, with the best of intentions. Lots of management wants to believe they can buy their way out of the hard problems of not having any discipline. Sigh.
Here's how to handle the situation you are in right now:
1. Work with the team to identify what item in the current sprint will be delayed.
2. The EM and Scrum Master should communicate the delayed issue to their leadership.
3. Identify any long-term objective that will be delayed and communicate that as well.
If there's a question about why a delay will occur be honest: either the critical issue affecting customers gets fixed now, or the new thing customers don't yet have gets attention.
Going forward, allocate 1 day per person in each sprint as capacity to address bugs. Do this explicitly if you have mature leadership who understand how development works, or implicitly by padding other estimates if you haven't. Addressing bugs should be an implied task every sprint. When there are no important and urgent bugs, that capacity should be used to address tech debt instead.
This is good advice, but I'm already doing something along these lines and my point is that this is not covered by the OP at all. My question was not intended as asking for advice for my personal situation - it was a criticism of published document.
That's a good idea. Consulting firms have really overcomplicated Agile a lot. I've been displeased to meet bloated implementations these last years.
My only point is that, at least in the companies I've worked for so far, a practical Agile implementation must provide some device for making a "pressure" over the team to avoid too many items ending up carried to next sprint.
Of course there are lots of legitimate situations where an item doesn't fit in the sprint and this should be acknowledged, providing inputs for the estimation of the next sprint and making those estimations more accurate. However, in my opinion, it should also be clear to everyone that those slippages have consequences and everybody should be employing their best efforts.
I don't consider this a deficiency in the article though, since Agile in itself seems to be optimistic about teams by its very nature.
I believe this is going to get me some downvotes, but this is unfortunately the reality I live in and if I were going to devise an Agile implementation for my team I would take this into account.
Sorry, there is no "faster" button. The only lever you have is cutting scope as you go. Fixed scope just makes no sense.
Otherwise you get one of three outcomes:
1. We underestimated how much we can get done. People now start gold playing stuff and wasting time that would be better spent on future backlog items.
2. You estimated just right and are done Friday at 5pm. Obviously this doesn't happen frequently.
3. You overestimate and now something's gotta give. People will start cutting corners or putting in over hours as a punishment for being bad at estimation. This is not sustainable.
We need to get away from the fixed scope mentality with which Scrum had poisened the Agile pool. If we cannot trust or developers to do the best work they can and wanting to be proud of their work, the organization has entirely different problems.
Experience shows that this is not the way things work.
Real-world team members present varying levels of maturity and, therefore, commitment levels to the aimed results.
Some will work at their natural pace and deliver the thing, provided the estimates were accurate; some will relax and leverage the fact that it's always OK to say that there was not enough time; some will work hard at the beginning and get contaminated over time; and so on.
It is sad to work without a 100% mutual trust, but we have to be realistic. Building trust takes time.
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 the time they would have spent fixing the issue going "Ok, is this really a priority 'X' issue?" and fighting with whoever raised it.
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 team can't defend its own boundaries, it's hosed, period.
I've never know immediate management to understand the business nor the system as well as the ones with boots on the ground. I've yet to see a situation where the manager doesn't end up coming out of his office and asking someone on the team "so, what's this mean?"
It's not management's job to understand details of the code (and it's probably a problem if they do). And it's not their problem to understand the business perfectly (and it's probably a problem if they do). It's their job to facilitate getting work done. That means helping their developers work as effectively as possible. And in most cases, that means keeping customers from end-running around whatever work management process is in place. If you're doing agile, the manager's job is to protect the iteration, and shield the developers from politics and pressure so they can work well.
I often use a bread-baking analogy here. Making software is like baking bread. This iteration, we get some flour, water, yeast, and salt, mix them together, knead, rise, and bake. And if someone comes in five minutes before baking is done and says "Can't you just add some raisins now? It's just a handful of raisins, it's not much work". No. It means starting over.
The problem I've seen with this approach is when issues cross org boundaries and have externalities.
Say the event subsystem is shared or is under control of another group. They do maintenance, and the app doesn't restart and stays down because it had bad retry logic and won't retry after the connection is closed. Stupid bug, easy fix.
You're now hobbling that other group from doing their work, and depending on the discipline of the app team to fix it, and that bug may stay in the backlog a long time. Meanwhile, it's going to come up in a handful of meetings with a handful of people as it gets estimated, prioritized, assigned, touched again and again...
Coming to someone after diagnosing and helping them recover from a problem, only to be told "we're busy, come back three weeks from now" sucks.
This is another time to ask uncomfortable questions. Why are issues coming up in the middle of the iteration that "take higher priority"? Why can't they wait?
Is it a production bug? If it is, can it wait? Just because it's a production bug doesn't mean it must be addressed outside the normal iteration cycle. Criticality should matter.
If it's not a production bug...
Is it a missed critical requirement? WHY??? How did the entire team miss something that must be done right now? That's a major process failure.
If it's not a missed critical requirement...
Is it someone with great power just disrupting your iterations for their pet project? Do you have multiple customers who are competing for your team as a resource, and not hashing priorities out together in iteration planning?
Following from that...
Are they directly in your chain of command? Is it your superior changing horses in midstream, or your customer? Because you can tell customers no. Even if they scream and shout and say they're gonna tell Mom. The customer is not always right. Learn to say no.
And if you still feel like you have no authority and no control over your work...
I don't even think it's a good rule because if something critical/high priority comes up it could be because of planning or it could be because of multiple external forces and or a bug.
Maybe it's a good general workflow but as a hard rule it seems rather silly... but I would love to work somewhere where there wasn't a flipflop on priorities every week or so :)
Many projects have often predictable periods of intense testing and bugfixing without new feature development.
On the other hand, distinguishing between "the product doesn't do X properly" and "the product doesn't do X yet" isn't necessarily important or meaningful.
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.
Not quite. Agile, when done right, by small-to-medium teams, can be effective. However, whenever a big corporation tries to jump on the agile bandwagon, it turns into nightmare fuel.
The TL;DR of this is "work less (hours), avoid burnout."
But this prescription needs a few more paragraphs of caveats that describe the company, team, product and other factors that affect whether this strategy is viable. The simple answer is "do what works for your situation" but that's light on useful information. If you can make Agile or Agile Light or Waterfall work for your team, go ahead. If your team cannot wait 7 weeks for a production issue to be fixed because "we don't add issues to sprints" then you might not be able to work with this system.
When I saw 3 weeks on/1 week off, I was actually thinking of a sort of reverse - 3 weeks of active development with a final week of catching up on QA and bug fixes discovered in the sprint, as well as retrospectives, grooming and sprint planning (though, presumably, a dedicated product owner would get most of that work done concurrently with ongoing development.) You don't end up with an actual week off work but it is a lighter week.
The main issues I've seen with Agile were not burnout related, but simply having an incorrect or weakened team structure. Not enough testers, insufficient engagement of a product owner, overloaded manager/scrum master/architect. It kind of goes without saying that if you try to follow Agile but you omit key team members, the existing team members are then more likely to be overloaded to pick up the slack, quality will go down, and the smoothness of the sprint cycle will decrease.
Agile 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.
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 people incorrectly focus on sprint commitments. If Scrum is so commonly misinterpreted, it is flawed.
And agility in this case being Business Agility: the business being able to change course, not being hold hostage to a years long plan which cannot be changed.
Agility has nothing to do with software development, and everything with business.
I tend to view scrum, kanban, XP and also the more traditional tools like V-model as tool boxes - or maybe some kind of pre-configured framework. They combine agile or other project management tools in order to solve problems the team or stake holders of the team have.
However, this doesn't mean you can't take out and exchange parts. Some teams work profiles fit well with set sprints with a stable set of tasks. Others, like ops work with few people, doesn't due to incalculable factors like incident management. Prioritization might need different mechanics depending on the position and the responsibilities of the team.
It's all a big grab bag of tools to create some working workflow for a team.
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.
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.
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.
Points are a team-internal measure of a task. You can after the fact convert points to time, and then after a few sprints (when you have a fairly stable average velocity) then you can convert points to hours and do a forecast/estimation.
// In my mind you forecast the date of completion, but you estimate the amount of work. It's probably just mindless semantics, after all saying you can estimate the date of completion sounds just as natural, but saying you can forecast the amount of work sounds a bit unnatural.
This is the perfect recipe for never delivering anything. Without release dates developers will continue building and gold plating and building and gold plating. Create your tasks, estimate your tasks, put a date out there, and hit the date. If the product has bugs, unfinished features, then so be it. Users understand flaws. They don't understand missed dates.
That's interesting as in my experience is exactly the other way about. It's the experienced developers that try to gold plate to avoid the issues that they had in the last project or two projects ago, whereas the juniors ship code quickly but unfortunately often incomplete and certainly lacking a reasonable amount of test coverage
I don't think the parent poster was saying that the learning itself was bad.
I think the gold plating they're referring to is a form of over-correcting. The learning itself is good, and correcting prior issues is good. But over-correcting and over-learning can be problematic and can lead to gold plating.
I don't think there's any easy indication of the line between the right-amount of correction and over-correction, but I don't think it's unreasonable to state that one can over-correct based on prior experiences.
The second-system effect is definitely real and is a trap most developers will fall into. I think gold plating introduces liability and it would be better to ship early. I am, however, conflating my own behavior and anecdotal observations to paint broad strokes.
Estimates are always wrong only if they are concrete estimates as if they were certain.
If, instead, they are 90% ranges (I am 90% sure that this will be done between x and y) then it is much easier to estimate accurately. It is also easier to spot bullshit (if the spread doesn't go up as your time to completion moves further from now, it is probably a bullshit estimate).
I really love the method from The Clean Coder, where you make best/median/worst estimates for tasks and then add them up to a mean and standard deviation. This helps capture the truth of “we don’t know how long it’s going to take, but it’s likely between x and y”.
Where this still falls apart, for me, is knowing how many hours per day I’ll be able to spend on each project. I have multiple clients, and things come up. This method has gotten me very good at the budget aspect of project estimation, but the scheduling aspect still slips some (it’s rare that more hours in a day become available)
Only issue being that the estimates one gets from poorly planned sprints are probably less reliable than just asking the devs how long the project will take and going with it.
Good estimates come from watching people deliver over time and scientifically comparing empirical performance to subjective estimates, not asking them to predict. Joel Spolsky has a great blog post on Painless Software Schedules.
There is nothing scientific about this method in my opinion. You do not make consistent reproducible experiments, you do not control for anything, you haven't even formed a null hypothesis etc.
> The business wants to know how much feature X is going to cost and when they can expect it.
Of course they do. We all want things that are impossible to have. I want to know the AAPL stock price in 6 months.
The traditional way to manage this impossibility is that engineering lies about it (they have to lie, because they can't know either), and once people are lying to each other, trust is unlikely to arise.
The agile concept of "velocity" is the best way I know of managing this. It's not very good, and it's often a victim of Goodhart's law.
And velocity should be an internal team measurement not shared with outsiders because (Goodhart's Law) when management says "Let's increase our velocity" and the team and developers are GRADED/PROMOTED on their velocity then you'll get point/estimate inflation which will hurt you more in the long run since the inflated estimates actually now allow for the work to fill the time (Parkinson's law).
What's the usual processing speed of a software engineer when it comes to reading through and understanding design & specification?
We found that usually either the documentation/specification/requirements are too fine grained (and then they then change all the time, but then there's no real effort/bandwidth to do change management on the specs), or they are not detailed enough, which makes the estimation process a useless guessing game on what might they mean by this or that.
See, I would expect the engineers to pipe up and explain that. It takes collaboration to get it right, and it takes the engineers setting expectations properly for what they need to estimate accurately.
It’s a collaborative effort, not a one-way street, as with most things.
It's not impossible to estimate roughly how long something will take.
If you consistently get it wrong, either:
1. You're not breaking down the work into small enough chunks to properly think about how long it will take
2. You are probably consistently under (or rarely over) estimating and should be able to fix that. For me, I have to triple my estimates, it always takes 3 times longer than I think it would
To claim estimating is "impossible", when many of us do it absolutely fine, is ludicrous.
Separately, there's scope creep, but that's another matter and again can be managed (e.g. "if you want X extra functionality for the same cost, you're going to have to drop feature Y, which will take roughly the same time").
50% off is understandable ? Where can I find such forgiving clients? My clients lawyers would eat me alive if I would start to bill them in such manner. They dont want to hear about uncertainty - they are buying professionals and this kind of estimations looks to them like we dont know what we are doing.
Sure we all know this, but for business people with money this looks fishy.
This xkcd sums up the problem perfectly:
https://xkcd.com/1425/
How non technical person can tell the difference between task inherent uncertainty and Your incopetence? They cant that's why they will buy Your competition that will claim there is no uncertainty.
Initial estimation (over many sprints, with either a greenfield project or with a new dev team) is always very hard, almost a completely foolish attempt.
After the first few sprints the uncertainty reduces.
And after the team gains experience with the system (business domain + codebase + infrastructure - if applicable), they are much better at scoring tickets (SCRUM poker), which then can be converted back to time from points.
Directly estimating time (asking for time estimate from programmers) is just something that never works (or if it does, then it means the programmers does the following adjustment internally), as humans get into the confusion of constantly having to recalculate their intuitive feeling of required time based on how long actually that took the last time they felt that.
I've seen Agile™ estimation break down when the task is either
1. something nobody has done before (or has no close analog), or
2. is so interconnected that it can't be broken down.
The former is just a matter of hiring more experienced engineers _or_ allocating exploratory/prototyping time. Still high uncertainty but these kinds of tasks become rarer over a time.
For the latter, the common refrain is "break it down" but there certainly exists a relatively common type of work that must be completed all at once. And I find it increases as the complexity or popularity of the product increases, so with time. Therefore perhaps the metaphor of building becomes less appropriate, and surgery paints a more accurate picture.
Builders can construct a house, then add a garage, go work on another house, then return and add a guest bedroom, then remodel the kitchen, all with relatively minimal pausing or switching cost. But once a patient is put under and opened up, the surgeon really should work on finishing up that one patient before moving on to the next one. And for some weird reason we tend to prefer one big surgery to multiple small "atomic" ones.
> Builders can construct a house, then add a garage, go work on another house, then return and add a guest bedroom, then remodel the kitchen, all with relatively minimal pausing or switching cost.
Have you worked with contractors? This is so so so so not true.
> And if you do, that time is essentially wasted - something that shouldn't be billable.
If I develop a feature for company A, then reuse it for company B, isn't A footing the bill for B? I mean, we all do that, but I think it's worth thinking about.
It might be billable to comp B (they got the value add), but internally that should not have high cost (in hours, resources) attached.
Ed: that is to say the time
is wasted - but might very well be able to charge a premium on the experience. In my original comment I was mostly talking about making feature x for customer a, then making feature y for customer a. Where x and y are pretty much the same.
That's the problem. In theory every bridge is the same. Yet you need to plan each one of them.
Similarly every run of the mill business-as-usual boring-as-fuck CRUD corporate internal "app" is the same, yet they still need a lot of work, and they are still hard to "estimate".
> 1. You're not breaking down the work into small enough chunks to properly think about how long it will take
This usually means prototyping, which means actual coding, which means you couldn't do it as you already had to give your estimation. To put it another way, places who require estimates for planning want them during planning and don't allow time for doing this. On the up side, when they do let you take the time to prototype they take your prototype and put it right into production because then the estimate is 0.
> 2. You are probably consistently under (or rarely over) estimating and should be able to fix that. For me, I have to triple my estimates, it always takes 3 times longer than I think it would
This is a common trick but it really just means you are not really estimating, but guessing that it will take less than this amount of time. This would be more apparent if you gave an estimation range, what you actually estimated to your estimate times the 3X padding.
> 1. You're not breaking down the work into small enough chunks to properly think about how long it will take
This is exactly what waterfall was. It pre-planned all the small tasks beforehand and required stopping the world and replanning everything when something changed.
Agile was an attempt to move away from that and create a feedback loop where you do some limited work, learn something from it, and then do another thing after you've internalized what you learned. (Original "sprints" were a coordination mechanism between departments that was applied in the automotive industry: there was lots of dead space in-between them). The whole point was the iteration was small enough that it didn't actually matter if your estimate was correct or not.
This bastardization where Agile has become synonymous with estimation accuracy is completely against its original spirit. People have started to care about estimates because Software Project Managers wouldn't have a job if there wasn't a need for heavy-handed planning sessions.
I think the estimation accuracy is not the main point nowadays, but instead the simple fact that the viability/rentability of every project matters, and even if there's an up front pile of money to spend (quarterly/yearly budget), there are probably multiple competing ideas on what to spend these - and of course these usually consist of and involve software and its development.
Of course this is why having a low-fluctuating empowered team (project ownership, refactors, etc) can usually deliver changes faster and with lower cost and with greater consistency, than every time doing a new project (which might involve new people who never saw the stack, nor the business domain) to modify something on a system.
> To claim estimating is "impossible", when many of us do it absolutely fine, is ludicrous.
How do you do it? I mean, how do you know when you reached the necessary granularity? And even if you know, sometimes it just means more questions that the client might not be able to answer at that time. Do you come up with a worst and best case and carry that delta up the breakdown hierarchy of components? Are you able to do this for every kind of task that can come up in a project? (From frontend design to backend implementation and third party system integration and infrastructure setup and then product deployment.)
> The traditional way to manage this impossibility is that engineering lies about it (they have to lie, because they can't know either)
Honest estimates with uncertainty are not lies, and not having certainty doesn't prevent estimation.
But, yes, people seem to often decide that being uncertain justifies self-serving lies instead of honesty (and sometimes the environment encourages that by punishing honest estimates.)
Theoretically. Practicaly they don't do that kind of planning and high estimate leads to pressure to lower it down (or making you feel ashamed for it being to big etc), which most developers will do, because developers tend to sux at negotiation.
That's where it breaks down. If you strip the Scrum-Industrial Complex nonsense away, one of the basic concepts of Scrum planning is that the business gets to define the stories, and the developers get to assign the points (or whatever mechanism is being used to estimate). Business sets the scope, technical sets the resource requirements.
If developers can't hold the line on estimates, they're toast. Nothing will ever get done on time or under budget, because the organization is focused on basic dishonesty about what work can actually get done. Which means people are being rewarded for the wrong things. Measure by estimate accuracy rather than promises made, and you'll see a lot more honesty in estimation.
Another bit of wisdom I got from Kent Beck is that there are three basic controls to every project... schedule, scope, and resources. You can only control two of them. And resources are generally fixed at the beginning of the project(1), so most projects are either scope-bound (we must have all these features), or schedule-bound (we must hit this hard date). If you're feature-bound, estimation failure means you'll be late. If you're schedule-bound, estimation failure means you'll be incomplete.
This can be a very hard pill for the business to swallow. They want it all, and they want a predictable schedule. But Beck's triangle is akin to thermodynamics. Do you want the volume, or the pressure, or the temperature? When fixing devops-related and agile-related process problems, I often hear "But we're a schedule-driven company!" when they have a scope-driven problem like process transformation.
1. As The Mythical Man-Month pointed out almost 50 years ago, adding resources to a late project makes it even later.
> If you're schedule-bound, estimation failure means you'll be incomplete.
Schedule-Bound development (or Deadline Driven Development) can actually work well with minimal estimation as long as you are truly building MVP (minimum viable product), you have to ruthlessly slash features and only build the core features that are going to deliver the most bang for the buck.
There is a fourth control of course which comes into play when nothing else will give room: quality. You can take many shortcuts to deliver in time, full scope, with the resources available. But the result will be buggy and/or unmaintainable.
Surprising amount of companies choose this path, I guess most without realizing it.
Quality is basically inherent in scope. Is testing the product in scope? Yes, then it will take up precious resources (time). Do you want to test it on every platform? Yes, even more time. (And of course the same goes for code review, writing unit tests, planning, writing and discussing a design document, etc.)
If it's optional, they need to know to make a decision to include or exclude it.
If it's not optional for the project, but the project itself is optional, they need to know to make a decision to kill or keep the project.
If it's not optional to the project , and the project is not optional to the business, they need to know to decide whether they keep or fold the business.
In any case, if they might choose to keep the business, project, and feature, they need to know because they have to budget for the cost if they do so.
So, essentially, business always needs to know the cost.
I think this is totally reasonable at certain times. E.g how long will it take to add feature x with scope y to our existing product is a decent thing to estimate (and estimate only) for stakeholders to prioritise appropriately.
I think most problems people have with estimates is when they are applied to things too large, or too small, to reasonably estimate. E.g How long will it take to build this product from scratch with a laundry list of features. Or more commonly, to micromanage. Why does anyone care whether this task will take 2 days as opposed to 3? That’s not meanginful information unless you’re mistakently expecting the individual user story estimates to add up to a reliable assembly line of work.
I’m happy to estimate when it has some business purpose. If not, it’s meaningless busy work or worse.
> They need to know that, because they need to decide if it's worth it in the first place
If this is the case, they should also be able to state the threshold above which the item would be "not worth it", and I would assume this is significantly easier to figure out than it takes developers to build a decent estimate.
From a developer point-of-view, the first high-level estimate is then much, much simpler: "Is it going to take more or less than $not_worth_it to build?"
If the answer is "more", then it gets dropped -- at least in its current state. It could be re-scoped later as a new item with a smaller MVP, for example.
If the answer is "less", then the developer can put in the time to get a proper estimate. I think there might also be an argument that if the backlog is properly ranked the detailed estimate also becomes pointless -- just work on it until it's done. No one should be doing detailed estimates on items that are more than a few weeks/sprints away in the first place.
Disclaimer: I've only recently been thinking about this abstractly, and have not yet tested this in practice, though I'd love to have this discussion with anyone that has.
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.
Maybe you could rephrase it to "Don't make estimates before work is well underway". The main problem with estimates is that they are usually just wild guesses and pretty useless. But once you've got going on something, have had time to think it through and test your ideas, you can usually give at least a very rough estimate at that point.
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.
Would you prefer the centralized planning model of waterfall? Of course none of these systems are perfect, but it's been a major step in a better direction for everyone involved.
What i would prefer, is to take a step back and look at all major interest partys involved, who will deform the development process. If management puts to much pressure on, a good process would give tech and the customer more chances to counter said pressure, to avoid tech debt and badly implemented features.
I want a process that reacts to the situation, in favour of the product, in favour of longterm goals - who actively resists people who try to gamble it for whatever reason. Agile is not that.
"Agile" is a set of principles and values as defined in the Manifesto for Agile Software Development. If how you work contrary to those principles, then you simply are not "Agile", no matter if you call it that.
"Agile" will never fix bad management, nor will anything else for that matter.
That is technically be true, but I've worked at four shops that have implemented Agile methodologies and it hasn't been true for any of them, nor for most of the engineers I personally know but don't work with. I do personally know one person who works on a team that this is true, but he's the only one.
This may be doing Agile wrong, but if something can be so easily done wrong that it's common, I count that as serious flaw in the methodology.
I'd push back on calling Agile a methodology. [The Agile Manifesto](http://agilemanifesto.org) a set of ideals, that's all. These ideals often run afoul of conventional wisdom in traditional management/business/sales circles, so we end up with a set of procedures masquerading as "Agile" in order to not upset prevailing sensibilities.
>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.
The problem with this is that the stakeholder might not understand what simple means. It happens here all the time.
We get "simple" requests for verbiage changes, but after reviewing the story, the verbiage request isn't universal. It only applies to certain offerings, and the stakeholders only want the verbiage the be applied after a certain step in the application. This is still a relatively simple change, but when factoring in all the other "simple" requests that involve complex logic, changing displayed text becomes relatively complex.
We do sprints because it's our time box to see how close we are to hitting the mark. A sprint isn't a hard deadline in which the team must kill themselves to get everything finished. It's an arbitrary passage of time for setting goal to keep on track with what is going to be released. If you have something that's releasing two months into the future, it's easy to say that you can still make time although your first two weeks were riddled with unexpected complications and stoppages. A sprint forces us to focus on what should have already been completed to re-prioritize if necessary. And you can't feasibly do that without an estimation.
The two biggest problems with estimations are underestimating and treating estimations as promises. It's hard to estimate. So the best course of action is to make stories as small as possible. Probably smaller than someone would consider rational. If not, at least have the stories divided into individual tasks or chunks. Then once you have estimations, treat them as goals rather than deadlines. Use your sprint review as a time to honestly reflect on why the estimation was missed. Then, and this is critical to successfully estimating in the future, use the notes of reflection to make better estimates.
> The problem with this is that the stakeholder might not understand what simple means. It happens here all the time.
"Do the simplest thing" means don't overengineer, not necessarily that the feature won't be complex. You only code up what helps fulfill that particular story's definition of "done."
As for complex features. when my stakeholder asks for some big complex change it's almost always decomposable into much simpler stories. Maybe those have to be hidden behind feature flags until the whole epic is done, but they're shippable individually. Doing that decomposition up front helps demonstrate the complexity to the stakeholder and takes some pressure off of me. It also makes them feel secure because they have more granular insight into progress; that they're not sending me off on some Lewis & Clark expedition.
Said another way, estimates are not promises. Don't crunch to meet them. I think it should be phrased as "no deadlines".
The whole sprint structure is so you're constantly adjusting your plans and estimations at some predictable time. Without a sprint you can end up with randomization.
I've noticed some managers and project managers love to emphasize the that sprint plans are "commitments". "OK, is this what we're committing to for this sprint? Is everyone comfortable committing to this?". LOL. OK. Maybe that guilts the young bloods into doing free overtime or something. But no.
It's like when car salesmen try to get you to name a number you'd definitely buy the car for and sign it on some not-at-all-binding-or-official piece of paper, like that means something, before they go back and "ask their boss if they can make it work". Psychological trickery bullshit.
It's a very similar psychological trick. I've even heard project managers I like and who I think are generally very good do it. I think it's just part of their language now, and some may not realize they're doing anything kinda shitty. But it's something straight out of Cialdini's Persuasion, and unsubtle enough that even I can tell what it is.
"Do you feel comfortable committing to these stories?" Always a question.
Committing. If you don't make it for any reason not obviously caused by "outside blockers" you're morally responsible—and maybe even then. What are you, some kind of liar? Quite a step from an estimate. Kind of harsher than a deadline, even, which are oh-so-rarely as "deadly" as the name implies. But people close enough to Scrumish processes to get in the meetings but far enough away not to be writing code or testing things or putting out designs sure seem to like that word. Commit.
You have to do estimates, it's how a business works. Not knowing when something will be delivered is too much to ask a company to deal with.
Also, "always do the simplest thing" is one of those phrases that can be twisted and morphed to support literally anything, which makes the phrase useless. It feels good to hear and say, but the reality is it doesn't help you out of a jam.
Sprints are exactly what you're describing, except with accountability built in. That shouldn't scare people, but it does, and that is what causes burnout. Fixing the fear around accountability is how you fix burnout, not eliminating the thing that your boss can use to justify your job.
The number one reason agile projects fail in my experience has absolutely nothing to do with planning session, sprint cadence or estimation. It's because the client was not properly prepared to accept iterative delivery or play their part as product owner. I see a lot of team organize themselves around a well-groomed backlog and set their priorities only to have clients come in and ask for deadlines and fixed scopes and all the other stuff that is anathema to agile. If you client is able to set priorities effectively and allow a slower, quality-driven model then everything else becomes just so much easier.
I just read a marvelous book called Handmade, by a fine furniture woodworker, and something he says over and over is "Go slow to go fast". The sales pitch to the business for a well-controlled agile process is that it maximizes productivity. Shifting priorities and poor planning undermine the productivity of the development team.
Ironically, such clients also seem to expect that whatever additions/changes they dream up should be able to be folded in to the plan willy-nilly. Whereas if they accepted an iterative process that would come naturally, without constant re-negotiation or ill will.
They can! That's exactly the point of agile and is how you get them onboard. When clients want a feature that is weird or complicated or whatever, the answer is never "no" the answer is "sure, now tell us where it fits in the priority list".
>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.
you just described doing agile wrong...
You're advocating for a version of agile lite, not agile.
Or alternative, agile is different to everyone you talk to and your agile isn't the same as someone elses agile.
Take your pick, but sprints, estimations, not only doing 1 thing/most important things are basic tenants of agile as most people see it.
If you can accurately estimate how long a software task will take, you should have already made a reusable component or automation to generate that code.
Estimates are meaningless. I've seen PhDs waste endless hours faffing with estimate-calculating spreadsheets.
Fundamentally, the universe is unpredictable. Chaotic and complex systems require their starting conditions to be measured to an infinite level of precision to be predictable. The Heisenberg principle means this is, as far as physics can tell, impossible.
On a more practical macro level, a complex adaptive system becomes unpredictable once three feedback loops are present (the three body problem is related).
Modern computer systems are unpredictable because we cannot predict the interplay between levels of abstraction.
It does not matter how smart you are. Unless you have perfect knowledge of all levels of abstraction in the system below you, even in a macroscopic sense you cannot predict the future. Precise estimates will be inaccurate.
Confidence ranges and superprobabilities are of some use. Discrete and precise estimates are an utter waste of time at best, and are dangerous and misleading at worst.
EDIT
Written on a mobile waiting for plane take-off, hence lack of citations. For more on complex adaptive systems, I recommend the works of Murray Gell-Mann and the research output of the Santa Fe Institute, particularly Scott E. Page.
Another way to put it: If you know how long something will take in advance, you have a solution in mind. It is unlikely that this solution is (A) the best one and (B) the one you will actually implement. It would be stupid to ignore information you learned along the way. If you could actually predict the future you should invest in the lottery, not in software.
EDIT: Of course there are projects where you actually know exactly what to do. Happens a lot in consulting. That has nothing to do with Agile though.
I 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.
My mind doesn't take 12 weeks off a year on a schedule dictated by management, and it certainly doesn't take the remaining 40 weeks on on a schedule dictated by management. I'll work a lot better doing 6 hours of work a day every week than 8 hours of work with no slack for three weeks straight.
Everyone has their own vision of what agile and/or scrum should be. Every company, manager and developer has their own special and unique recipe. There are as many flavours and variants as there are rules for playing a game of pool across the world.
Personally my main takeaway from the whole agile world is "people over process".
Sort out your communication, trust, and how you work together first. Then start looking at whether you want to work with agile, XP, scrum, kanban or some other recipe.
As others have noted, I think it's important to note the difference between Agile and Scrum. Agile is a mindset, Scrum is a framework that encapsulates a lot of Agile tenants. The ideas of a sprint or backlog or cards are purely Scrum. Agile says nothing about using these items to satisfy customers (the highest priority per the Agile Manifesto). That said, Agile principles intentionally include a note about promoting sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
TL;DR So long as you are constantly mindful of Agile tenants, there's already built in awareness around burnout and sustainable practices.
I believe this happened because enterprises and dusty orgs wanted all the benefits of Agile without touching any of the real problems that make their orgs suck. Like communication issues and unrealistic expectations. This lead to first Scrum and now Safe.
It seems like you could solve this problem in an even more dev-friendly way by sticking to one of the most fundamental principles in scrum (and possibly others): Don't schedule 100% of your developers' time, and definitely don't fill them up to 100% on coding work. Not even close. Devs are supposed to work at a sustainable pace.
A sustainable pace leaves plenty of time for kicking your feet up on the desk in order to think about things. It leaves plenty of time for chatting with one's teammates to make sure ideas are fully baked before implementing them. It leaves plenty of time for trying out new ideas.
And, importantly, it leaves the time for doing this relatively unstructured. Because the dev team is a bunch of working professionals who should be free (and trusted) to figure out for themselves when they need to take a pause from cranking through tickets in order to do other stuff. A "3 weeks on, 1 week off" approach doesn't get you this.
I think that the spot where the car always ends up upside down in a ditch on agile implementations is a misunderstanding of the basic idea behind velocity. It isn't a KPI that you're supposed to maximize. It's a feedback mechanism that the product owner uses to manage the pacing of some of their own work, in order to make sure that the pipeline neither empties out nor becomes jammed full of work.
If the PO is doing that job correctly, then they would be making tough decisions about what is and is not reasonably doable in a given timeframe, and providing backpressure to stakeholders when they're asking for too much. If they're instead accepting every single feature request, and dealing with the resulting backlog logjam by continually pressuring the dev team to work faster and faster (and more and more sloppily), then, no sense in mincing words about it, they're doing a bad job as a product manager. And the dev team is well within their rights to push back against them on that.
Which, incidentally, is what the orthodox Scrum formulation is trying to do when it disallows the PO from deciding how many items (or story points, or whatever) to pull into the sprint. That's supposed to be based solely on the dev team's own opinion of what's a reasonable amount of work to take on.
>It seems like you could solve this problem in an even more dev-friendly way by sticking to one of the most fundamental principles in scrum (and possibly others): Don't schedule 100% of your developers' time, and definitely don't fill them up to 100% on coding work. Not even close. Devs are supposed to work at a sustainable pace.
This sounds great until you work someplace where you need to allocate 7.5 hours every day to a billable project.
If you don't allocate 7.5 hours you are asked what you were doing the rest of the day...
I've seen where someone won't have a conversation at work because they can't allocate a project to 10 mins chatting with work colleagues.
Or when you get asked a coding question from a junior and so you help them, but then need to get their project code they were working on so you can allocate that 10 minute chatting /giving advice to that project.
Or helping a junior with something they are stuck on, management sees and questions why two devs are sitting at one machine...
I think the author has made the mistake of "what works best for me is what works best for everyone". It's easy to make. Likely, they had many bad teams that used "agile" as an excuse for poor management systems, leading to burnout. Then, they found a system that worked really well for them in their project and said "aha! everyone who isn't doing it this way must be experiencing what I experienced before I did this!".
Look, the point of Agile is that the team builds the process that works best for them within the parameters of the work that needs doing. If you're burning out because of your process not working, change the process.
For most teams I've been on, a month-long sprint is too much. Once my team switched from 2-weeks to 3-weeks, and in that situation it was pretty good. But on other teams, requirements and priorities shifted frequently, and sometimes 2 weeks felt too long. This same "well that might work" pattern applies to most of this document's recommendations, in my view.
But kudos to the author for finding a system that works for them in their current situation.
There are three parts involved in any project. The product, the process and the people. As it currently stands scrum does not make any provision to address the people. Hence management uses this void to turn scrum into scrum butt and turn the devs into jira ticket processing machines which are pushed until they break.
Until the big names in the industry accept that error and address that, I guess there will be no hope for most people doing dev work.
Most companies on themselves don't have any incentive to address this fact because the commoditization of programmers benefits them and because they aren't in a position to understand the long term consequences of this (or don't care)
One 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 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.
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.
The point of standups is to help teams to learn to communicate and to steer the team to a habit of working on the most important things. Once that's a behavior, standups can be less frequent or dropped all together. This is especially useful for new teams or when the team changes.
No, the point of standups is to go around in a circle and make sure that everyone has everything they need to keep working (that there are no “blockers” in the parlance of agile). That’s why they’re called standups - you’re supposed to stand so that everyone gets annoyed if it takes more than a handful of minutes.
If you’re discussing what you did yesterday, what you’re going to do today, when you think x is going to be completed, what is blocking you (other than that so-and-so owes you such-and-such), or anything else other than nodding that you’re good you’re missing the point and that’s where the slippery slope of pointlessness begins.
But if something is blocking you, you should not wait for the standup to bring it up, what a strange way of working is that. Just ask someone who can help you. That's one thing that works well in my company.
Still people also want standups, basically to hear what others are doing and feel like a team.
And so we circle back around to the pointlessness of all meetings.
If it is as-needed to hash out an idea or determine the best way to fix something or to scope and point... that’s fine.
If it’s every day, twice a week, every MWF, etc. there is absolutely no way it’s actually necessary every one of those times and everyone is going to eventually defer to human nature and wait for the meeting to bring things up.
Part of that is natural and well intentioned - I’ve got the meeting in an hour, I won’t bother them yet, I’ll wait for it.
Part of that is natural and self-defeatist - if we already discussed everything then what will we discuss in the meeting?
The actual solution is to get rid of the meeting. The real solution is to just wait and discuss it all there. It’s like why I don’t call my mother the day before I go over to have dinner with her - we’re going to cover it all in the phone call and it’s going to be awkward silence while we eat.
And finally, if a standup is the best way you’ve found to make everyone feel like a team... there is no hope. That’s a really, really crappy way to make people feel included. Though that is what passes for team building at more places than not...
I find a good replacement for a traditional agile standup is a board based one. Rather than going through each person where it feels like you're being put on the spot individually, you go through each card on the board and ask what needs to happen for it to move to the next step. 90% of the time it's going to be one person putting their hand up and saying "I'm working on it" then you move on, and the other 10% of the time you might actually have a productive conversation in a meeting, which IMO never happens in a standard stand-up.
I'm surprised more companies haven't moved to this model. I don't really give a fuck what Jim is working on today, I just care whether his card that I have a dependency on is ready or not, or if we need to collaborate on it in some way. If the team is finding they don't know what's going on, or the board isn't being kept up to date, then this style stand-up will actually help with that, rather than just blowing 15 of my most productive minutes listening to everyone spin some bullshit story about how much work they crammed into 8 hours yesterday and why it didn't perfectly align with what they projected in standup the day before.
The thing is that we are ~11 people working on ~20 projects (the largest has about 2-5 people working on it at any moment, the smallest is worked on a couple of times per year, all the rest is in between). So without keeping each other informed there is a lot that goes unnoticed just because your work doesn't depend on it.
Going through all tickets would take a lot longer than having an update of all people so I don't think that will be popular, but I like to look at the tickets that aren't assigned to anybody yet at the end of most standups so that we don't lose sight of them.
The point of standup isn't to report status or get unblocked. Even in a large team or for x-team blockage, you can just talk to the PM.
The point is to keep social pressure on weak performers.
One of the main points of Agile (as implemented) is to push the team to perform. Otherwise natural habits of slack creep in. One or 2 people failing to deliver destroys all the good work of the strong performers. This is the real reason for standups.
My take on that is that any standup attended by project manager is not a Scrum standup anymore, it's a status update. What I've seen in few companies is that after such morning meeting with PM, the development team, would hold their own, smaller scale meeting, the real stand-up :)
One pathological case I've seen is the Scrum meeting that would run for an hour, because it was attended by 25 people, every day.
I 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 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.
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).
291 comments
[ 3.2 ms ] story [ 314 ms ] threadBut when your adaption consists of using your existing methodology with some agile concepts, but no retrospect on the methodology itself, you're not agile by definition.
What this "Agile Lite" puts right in the center is to split up your goals such that you can make meaningful work in a 3 week window, and track it asynchronously. Managers are free to have an overall plan for release in 12 months, as long as it's split up into units of work at most 1 day long.
What I think I read from your comment is that if you couldn't get this to work in the "Old" agile, you will fail with this as well, and I agree.
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, and you get no chance to say no. Technical minds / engineers in the room early and often is critical to success - otherwise you’re just told what to do instead of architecting it the “right” way.
Communicate when you need to but try it all for a sprint or two (really, Standup is a hardship? You may not be doing it quite right), then drop after the team finds a rhythm.
Edit; after reading the author’s other works the burnout seems to be centered on a big push from stakeholders to accelerate and keep going so a sprint is seen as a reset - kinda like a new day dawning in a news room. You can plan-in your work to avoid this and still continue to make progress but it does take some discussions with leadership, or at least a clear justification about why this week is exploratory instead of hands-on. Done it many times. I would not suggest changing the whole method just to accomplish this, however - a process fix for a problem like this won’t necessarily help.
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.
Agile has never been about predicting what you will do during a spent and then having slack or crunch time. Agile is about ranking your work by priority and dependency, setting meaningful milestones, and then adjusting your estimates frequently to avoid false promises and react to changes in the environment. If you don't finish planned work in a sprint, that is a planning success because after only a brief 2-4 week delay you actually know your performance against estimate and got clear information about how much you can do in a month, and a better chance at estimating what you can deliver next month.
In practice, most companies don't do this. They mark it as a failure and put it in red on the the big screen for all to see. Too many reds and there's disciplinary action.
> The first week of each month is spent with project leads and stakeholders defining the upcoming sprint
At the very least, I'd suggest that developer leads or engineering managers are stakeholders and therefore involved. They should be liaising with their development team (also stakeholders) during the planning phase.
Perhaps this sentence is overstated:
> It is an intentionally light week and many people may simply take the time off to paint or surf or whatever.
People should perhaps take SOME time off to relax, but likely not the whole week.
I saw it more as an opportunity to catch up on "other stuff". Maybe a tool you wanted to work on to make your work life easier, or leave a little early to wrap up taxes, or do some PoCs etc. to see whether a refactoring idea you have is actually feasible or not.
I am saying there's a lot of burnout in the tech industry and it's at least partly a process problem.
Maybe it's just me and I'm "doing it wrong", but I think it speaks to the issue that the suggestion of "taking it easy a week out of every month" is met with cries of "This is madness! It will never work!"
I also misread the "first week" stuff to mean that you leave the room and take a week off.
Having a light week while this is happening makes sense. It ends up being light anyway while the transitions happen. Apologies for the misread.
As for madness - I was not at all implying the suggestion was madness, and different things work for different teams / projects. I personally find standups are super helpful so I wouldn't want to get rid of them. That regular cadence it creates is very helpful in making sure we all stick our heads up and incorporate what's going on around us. If your teams are doing this already without the regular touch-points, that's awesome, but I find that with most teams that is a learned thing that takes a lot of time, and regular scheduled places to update are important to success.
So what the project leads actually do, is to decide which of these backlog items will get into the sprint. That's all.
Engineers are only out of the loop insofar as they have fewer meetings where they’re sitting around waiting for their turn to speak. If they want to weigh in, they should, and nobody is stopping them.
Many seem to freak out at the concept of working less. Yet the 40 hour work week was considered radical at one point. Googles 80% time is by most accounts not a real thing, but it's a start. I'm at 75% time here. Then there's 996 if you want to go the opposite direction.
If the overall message is “slow down sometimes” then I agree 100%.
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 for some projects and others don't.
I've worked on "A.I." projects where the sprint involves running a batch job that might take two days if it all works right. If it doesn't work right you might have to retry a few times.
When I was in charge of that batch job I would start it as soon as possible, sometimes with a week and a half to spare. Whenever somebody else was in charge of it they would start it with half a day or a day to run and we would blow the end of the sprint.
I blame the continuous stream of "urgent but not important" communicates generated by agile for that.
The timeboxing of planning is also a very bad idea. I worked at a place where we had a timebox of 2 hours for planning but really after that we were nowhere near a realistic plan for the sprint and it would take another 2 or 3 days of knock-down, drag-out meetings that would leave us all exhausted to understand what we had to do. After that the work was mostly downhill, at least the way I saw it, but one of the other team members would consistently burn the midnight oil at the end.
Often agile "teams" have a "normalization of deviance" situation where they have to do one thing (or say they are doing one thing) so they can say they are sticking to the process, but actually do something entirely different to get the job done.
That's sad.
You’ve succinctly defined the problem in a very profound way. A verbal punch to the gut for sure.
Wow! Sounds like decision-making processes needed tweaking even aside from Agile practice.
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!
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.
For one thing, retrospectives often come at a time when everyone has been busting ass for a long time and they just want to go home. If you put it off till next week then it seems like another distraction.
Like the planning meetings, the timebox for a retrospective is often wrong. In some cases things went smoothly and there is a little to say. That is where you should be. In some places you budgeted 45 minutes but there really is a day worth of material.
On top of that in many (most?) firms there is no sense of psychological safety. Often the real message is that the process is 99% bull but you can't say that in a meeting which is claimed to be about continuous improvement but is really about how to rearrange the deck chairs on the titanic.
In his book "Good to Great", Jim Collins points out the use of the word "alignment" is a bad smell. In a healthy organization there is alignment, naturally, built into it. If you feel like you have to paint alignment onto it after the fact you are just causing more misalignment.
Has been my experience (on good teams.) After a while, you tend to gel pretty well and don't need to spend that much time introspecting. The issues raised are either generally intractable organizational problems (that'll never get fixed), or fairly minor, and on several teams I noticed that retrospectives tended to feel pretty similar after a while (To the credit of the team, at that point we were like "we probably don't need retrospectives every sprint.")
This sounds like a smell. You should not be busting ass and have everyone feel like they just want to go home at the end of the sprint. You should be working productively every day without burning out. Perhaps the team is forced to make too many commitments? Kind of sounds like it from your other comments.
If your backlog is properly groomed and you have sufficient time for planning and the team has the last word on how much it tries to take in, then it works beautifully.
If my team was to have that problem, it would come up during the retro, we would add a few more hours for the planning event, hold more or longer grooming sessions, refuse to plan work which we can not yet estimate because the requirements are not clear, etc.
And btw, your "implementation of Scrum" wasn't working properly; probably because you weren't living up to the Agile principles.
C-bro wants predictability.
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, but rather as a criticism of published document. It's written as if it covered all the bases, but it doesn't cover bugs.
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.
I believe that may be slightly idealistic - a test case doesn't get covered by the stakeholders and suddenly once the solution is in, it suddenly pops up its ugly head. It takes a ton of self-awareness and resources for a project to know its every use before it gets to the end user.
And if you're seeing critical bugs that wreck iterations on a regular basis, we're back to my point - you're not planning very well.
One approach is to prioritize all bugs before all features. This is the Joel Spolsky approach. In a typical sprint-based environment, this basically means that available work effort is allocated to bugs, and only remaining work effort is allocated to new features. The Google SRE model (as I understand it) tries to moderate this by basically saying the team has some flexibility in work allocation between bugs/features unless certain SLOs are missed. When that happens, you go full Spolsky.
But that doesn't really address the "what if a critical bug comes up mid-sprint". To address that, you basically adopt an on-call support model. Each sprint, one (or more, or a half, etc.) are assigned to be the support person. They triage any issues or bugs and address them as best as possible. It really helps if there is a rotation, just like your operations on-call rotation. In fact, it's best if you view this as the "escalation level" from your operational on-call rotation. You can provide a similar resource for marketing or other kinds of events as necessary. The benefit is that you have an up-front acknowledgement of the level of investment needed for responsiveness, as well as being able to provide folks with periods of interruption vs. periods of deep work, and share that burden.
Lastly, I think it's really important to separate "release" from "sprint completion", especially in a SaaS environment. If you build your CI/CD and release processes around releasing at the end of the sprint, you end up building a very inflexible infrastructure. It's much better if you can release often, as work is completed. So, if you have a small feature ticket and you tackle it early in the sprint, ship it right away. If a bug comes up, release the fix as soon as it's available. I've been on too many teams where you have an inflexible release process tied to the sprint. When something comes up, it interrupts the whole flow to get something done. So, "end of sprint" != "big release".
I'm always paraphrasing Kent Beck... if you can't write your requirements on a card, you need to use a smaller card.
If it takes 10 people and six hours to accomplish the release of even the smallest of features, then it sounds like there's a bug with your "ship fast" feature and the team should invest some or all of its resources in fixing that. You probably can't do it over night, but you gotta chip away at it over time at the very least.
If you are looking for justification backed up by real world numbers, I highly recommend the book "Accelerate" by Nicole Forsgren, et.al.[2]
[1] https://a16z.com/2014/04/16/shipping-is-a-feature-some-guidi...
[2] https://www.amazon.com/Accelerate-Software-Performing-Techno...
Have you considered giving it as a gift to your peers and leadership? I really think it's a great read and resource for anyone trying to sell organizational change.
I wonder if any of those "automation needs" could be turned into startup ideas?
I actually tried a startup in the monitoring space, but sadly failed (it was great fun losing $100k or so, tho... well worth the experience!). But the automation needs problem is more a consultancy thing than a product thing. There are lots of products. Teams buy them, with the best of intentions. Lots of management wants to believe they can buy their way out of the hard problems of not having any discipline. Sigh.
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.
1. Work with the team to identify what item in the current sprint will be delayed.
2. The EM and Scrum Master should communicate the delayed issue to their leadership.
3. Identify any long-term objective that will be delayed and communicate that as well.
If there's a question about why a delay will occur be honest: either the critical issue affecting customers gets fixed now, or the new thing customers don't yet have gets attention.
Going forward, allocate 1 day per person in each sprint as capacity to address bugs. Do this explicitly if you have mature leadership who understand how development works, or implicitly by padding other estimates if you haven't. Addressing bugs should be an implied task every sprint. When there are no important and urgent bugs, that capacity should be used to address tech debt instead.
My only point is that, at least in the companies I've worked for so far, a practical Agile implementation must provide some device for making a "pressure" over the team to avoid too many items ending up carried to next sprint.
Of course there are lots of legitimate situations where an item doesn't fit in the sprint and this should be acknowledged, providing inputs for the estimation of the next sprint and making those estimations more accurate. However, in my opinion, it should also be clear to everyone that those slippages have consequences and everybody should be employing their best efforts.
I don't consider this a deficiency in the article though, since Agile in itself seems to be optimistic about teams by its very nature.
I believe this is going to get me some downvotes, but this is unfortunately the reality I live in and if I were going to devise an Agile implementation for my team I would take this into account.
We need to get away from the fixed scope mentality with which Scrum had poisened the Agile pool. If we cannot trust or developers to do the best work they can and wanting to be proud of their work, the organization has entirely different problems.
Real-world team members present varying levels of maturity and, therefore, commitment levels to the aimed results.
Some will work at their natural pace and deliver the thing, provided the estimates were accurate; some will relax and leverage the fact that it's always OK to say that there was not enough time; some will work hard at the beginning and get contaminated over time; and so on.
It is sad to work without a 100% mutual trust, but we have to be realistic. Building trust takes time.
I don't see this happening, even if that's a good rule, because issues come up that take higher priority than existing issues.
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.
I often use a bread-baking analogy here. Making software is like baking bread. This iteration, we get some flour, water, yeast, and salt, mix them together, knead, rise, and bake. And if someone comes in five minutes before baking is done and says "Can't you just add some raisins now? It's just a handful of raisins, it's not much work". No. It means starting over.
Say the event subsystem is shared or is under control of another group. They do maintenance, and the app doesn't restart and stays down because it had bad retry logic and won't retry after the connection is closed. Stupid bug, easy fix.
You're now hobbling that other group from doing their work, and depending on the discipline of the app team to fix it, and that bug may stay in the backlog a long time. Meanwhile, it's going to come up in a handful of meetings with a handful of people as it gets estimated, prioritized, assigned, touched again and again...
Coming to someone after diagnosing and helping them recover from a problem, only to be told "we're busy, come back three weeks from now" sucks.
Is it a production bug? If it is, can it wait? Just because it's a production bug doesn't mean it must be addressed outside the normal iteration cycle. Criticality should matter.
If it's not a production bug...
Is it a missed critical requirement? WHY??? How did the entire team miss something that must be done right now? That's a major process failure.
If it's not a missed critical requirement...
Is it someone with great power just disrupting your iterations for their pet project? Do you have multiple customers who are competing for your team as a resource, and not hashing priorities out together in iteration planning?
Following from that...
Are they directly in your chain of command? Is it your superior changing horses in midstream, or your customer? Because you can tell customers no. Even if they scream and shout and say they're gonna tell Mom. The customer is not always right. Learn to say no.
And if you still feel like you have no authority and no control over your work...
Quit.
Maybe it's a good general workflow but as a hard rule it seems rather silly... but I would love to work somewhere where there wasn't a flipflop on priorities every week or so :)
On the other hand, distinguishing between "the product doesn't do X properly" and "the product doesn't do X yet" isn't necessarily important or meaningful.
But this prescription needs a few more paragraphs of caveats that describe the company, team, product and other factors that affect whether this strategy is viable. The simple answer is "do what works for your situation" but that's light on useful information. If you can make Agile or Agile Light or Waterfall work for your team, go ahead. If your team cannot wait 7 weeks for a production issue to be fixed because "we don't add issues to sprints" then you might not be able to work with this system.
When I saw 3 weeks on/1 week off, I was actually thinking of a sort of reverse - 3 weeks of active development with a final week of catching up on QA and bug fixes discovered in the sprint, as well as retrospectives, grooming and sprint planning (though, presumably, a dedicated product owner would get most of that work done concurrently with ongoing development.) You don't end up with an actual week off work but it is a lighter week.
The main issues I've seen with Agile were not burnout related, but simply having an incorrect or weakened team structure. Not enough testers, insufficient engagement of a product owner, overloaded manager/scrum master/architect. It kind of goes without saying that if you try to follow Agile but you omit key team members, the existing team members are then more likely to be overloaded to pick up the slack, quality will go down, and the smoothness of the sprint cycle will decrease.
Ignore all existing literature and experts' previous experience.
Simple.
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...
https://youtu.be/k9duArRuSjQ
Agility has nothing to do with software development, and everything with business.
Agility is a way to deal with the fact that the idea of what "valuable" is changes constantly.
However, this doesn't mean you can't take out and exchange parts. Some teams work profiles fit well with set sprints with a stable set of tasks. Others, like ops work with few people, doesn't due to incalculable factors like incident management. Prioritization might need different mechanics depending on the position and the responsibilities of the team.
It's all a big grab bag of tools to create some working workflow for a team.
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.
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.
You've described scrum, what you're doing is scrum.
It’s like points aren’t hours, but if I estimate (er, forecast) how many hours it will take, its pretty easy to turn that into points, and vice versa.
I suppose it’s like one of those, “There is no word for it in English, but it essentially means...”
// In my mind you forecast the date of completion, but you estimate the amount of work. It's probably just mindless semantics, after all saying you can estimate the date of completion sounds just as natural, but saying you can forecast the amount of work sounds a bit unnatural.
Literally learning from the past and applying it to the present is “gold plating”?
I’m stunned.
I think the gold plating they're referring to is a form of over-correcting. The learning itself is good, and correcting prior issues is good. But over-correcting and over-learning can be problematic and can lead to gold plating.
I don't think there's any easy indication of the line between the right-amount of correction and over-correction, but I don't think it's unreasonable to state that one can over-correct based on prior experiences.
If, instead, they are 90% ranges (I am 90% sure that this will be done between x and y) then it is much easier to estimate accurately. It is also easier to spot bullshit (if the spread doesn't go up as your time to completion moves further from now, it is probably a bullshit estimate).
Where this still falls apart, for me, is knowing how many hours per day I’ll be able to spend on each project. I have multiple clients, and things come up. This method has gotten me very good at the budget aspect of project estimation, but the scheduling aspect still slips some (it’s rare that more hours in a day become available)
That is estimation, in the Scrum sense.
Of course they do. We all want things that are impossible to have. I want to know the AAPL stock price in 6 months.
The traditional way to manage this impossibility is that engineering lies about it (they have to lie, because they can't know either), and once people are lying to each other, trust is unlikely to arise.
The agile concept of "velocity" is the best way I know of managing this. It's not very good, and it's often a victim of Goodhart's law.
Also, avoiding scope creep is paramount.
We found that usually either the documentation/specification/requirements are too fine grained (and then they then change all the time, but then there's no real effort/bandwidth to do change management on the specs), or they are not detailed enough, which makes the estimation process a useless guessing game on what might they mean by this or that.
It’s a collaborative effort, not a one-way street, as with most things.
If you consistently get it wrong, either:
1. You're not breaking down the work into small enough chunks to properly think about how long it will take
2. You are probably consistently under (or rarely over) estimating and should be able to fix that. For me, I have to triple my estimates, it always takes 3 times longer than I think it would
To claim estimating is "impossible", when many of us do it absolutely fine, is ludicrous.
Separately, there's scope creep, but that's another matter and again can be managed (e.g. "if you want X extra functionality for the same cost, you're going to have to drop feature Y, which will take roughly the same time").
Estimation is hard. Accurate estimation is even harder. Doing it in the face of noon stationary scope is a fools game.
Who is in charge of estimating how long it will take to correctly break down a problem into accurately estimable sizes?
If something costs 15k instead of 10k, that's understandable, if you estimated 10k and it ultimately costs 1.5 million to develop, obviously not.
How non technical person can tell the difference between task inherent uncertainty and Your incopetence? They cant that's why they will buy Your competition that will claim there is no uncertainty.
After the first few sprints the uncertainty reduces.
And after the team gains experience with the system (business domain + codebase + infrastructure - if applicable), they are much better at scoring tickets (SCRUM poker), which then can be converted back to time from points.
Directly estimating time (asking for time estimate from programmers) is just something that never works (or if it does, then it means the programmers does the following adjustment internally), as humans get into the confusion of constantly having to recalculate their intuitive feeling of required time based on how long actually that took the last time they felt that.
The former is just a matter of hiring more experienced engineers _or_ allocating exploratory/prototyping time. Still high uncertainty but these kinds of tasks become rarer over a time.
For the latter, the common refrain is "break it down" but there certainly exists a relatively common type of work that must be completed all at once. And I find it increases as the complexity or popularity of the product increases, so with time. Therefore perhaps the metaphor of building becomes less appropriate, and surgery paints a more accurate picture.
Builders can construct a house, then add a garage, go work on another house, then return and add a guest bedroom, then remodel the kitchen, all with relatively minimal pausing or switching cost. But once a patient is put under and opened up, the surgeon really should work on finishing up that one patient before moving on to the next one. And for some weird reason we tend to prefer one big surgery to multiple small "atomic" ones.
Have you worked with contractors? This is so so so so not true.
But the thing is, in software engineering - if you ever need to do again, something you have done before, it should be just a copy away.
So you'll never spend time on something you've done before. And if you do, that time is essentially wasted - something that shouldn't be billable.
Now that's the ideal, obviously - reality is a bit more nuanced.
If I develop a feature for company A, then reuse it for company B, isn't A footing the bill for B? I mean, we all do that, but I think it's worth thinking about.
Ed: that is to say the time is wasted - but might very well be able to charge a premium on the experience. In my original comment I was mostly talking about making feature x for customer a, then making feature y for customer a. Where x and y are pretty much the same.
Similarly every run of the mill business-as-usual boring-as-fuck CRUD corporate internal "app" is the same, yet they still need a lot of work, and they are still hard to "estimate".
This usually means prototyping, which means actual coding, which means you couldn't do it as you already had to give your estimation. To put it another way, places who require estimates for planning want them during planning and don't allow time for doing this. On the up side, when they do let you take the time to prototype they take your prototype and put it right into production because then the estimate is 0.
> 2. You are probably consistently under (or rarely over) estimating and should be able to fix that. For me, I have to triple my estimates, it always takes 3 times longer than I think it would
This is a common trick but it really just means you are not really estimating, but guessing that it will take less than this amount of time. This would be more apparent if you gave an estimation range, what you actually estimated to your estimate times the 3X padding.
> 1. You're not breaking down the work into small enough chunks to properly think about how long it will take
This is exactly what waterfall was. It pre-planned all the small tasks beforehand and required stopping the world and replanning everything when something changed.
Agile was an attempt to move away from that and create a feedback loop where you do some limited work, learn something from it, and then do another thing after you've internalized what you learned. (Original "sprints" were a coordination mechanism between departments that was applied in the automotive industry: there was lots of dead space in-between them). The whole point was the iteration was small enough that it didn't actually matter if your estimate was correct or not.
This bastardization where Agile has become synonymous with estimation accuracy is completely against its original spirit. People have started to care about estimates because Software Project Managers wouldn't have a job if there wasn't a need for heavy-handed planning sessions.
Of course this is why having a low-fluctuating empowered team (project ownership, refactors, etc) can usually deliver changes faster and with lower cost and with greater consistency, than every time doing a new project (which might involve new people who never saw the stack, nor the business domain) to modify something on a system.
How do you do it? I mean, how do you know when you reached the necessary granularity? And even if you know, sometimes it just means more questions that the client might not be able to answer at that time. Do you come up with a worst and best case and carry that delta up the breakdown hierarchy of components? Are you able to do this for every kind of task that can come up in a project? (From frontend design to backend implementation and third party system integration and infrastructure setup and then product deployment.)
Honest estimates with uncertainty are not lies, and not having certainty doesn't prevent estimation.
But, yes, people seem to often decide that being uncertain justifies self-serving lies instead of honesty (and sometimes the environment encourages that by punishing honest estimates.)
If developers can't hold the line on estimates, they're toast. Nothing will ever get done on time or under budget, because the organization is focused on basic dishonesty about what work can actually get done. Which means people are being rewarded for the wrong things. Measure by estimate accuracy rather than promises made, and you'll see a lot more honesty in estimation.
This can be a very hard pill for the business to swallow. They want it all, and they want a predictable schedule. But Beck's triangle is akin to thermodynamics. Do you want the volume, or the pressure, or the temperature? When fixing devops-related and agile-related process problems, I often hear "But we're a schedule-driven company!" when they have a scope-driven problem like process transformation.
1. As The Mythical Man-Month pointed out almost 50 years ago, adding resources to a late project makes it even later.
Schedule-Bound development (or Deadline Driven Development) can actually work well with minimal estimation as long as you are truly building MVP (minimum viable product), you have to ruthlessly slash features and only build the core features that are going to deliver the most bang for the buck.
Not easily done.
Surprising amount of companies choose this path, I guess most without realizing it.
Thats only if that feature is optional. Often it isn't, and then it is pointless to estimate. Absolutely pointless.
If it's optional, they need to know to make a decision to include or exclude it.
If it's not optional for the project, but the project itself is optional, they need to know to make a decision to kill or keep the project.
If it's not optional to the project , and the project is not optional to the business, they need to know to decide whether they keep or fold the business.
In any case, if they might choose to keep the business, project, and feature, they need to know because they have to budget for the cost if they do so.
So, essentially, business always needs to know the cost.
I think most problems people have with estimates is when they are applied to things too large, or too small, to reasonably estimate. E.g How long will it take to build this product from scratch with a laundry list of features. Or more commonly, to micromanage. Why does anyone care whether this task will take 2 days as opposed to 3? That’s not meanginful information unless you’re mistakently expecting the individual user story estimates to add up to a reliable assembly line of work.
I’m happy to estimate when it has some business purpose. If not, it’s meaningless busy work or worse.
If this is the case, they should also be able to state the threshold above which the item would be "not worth it", and I would assume this is significantly easier to figure out than it takes developers to build a decent estimate.
From a developer point-of-view, the first high-level estimate is then much, much simpler: "Is it going to take more or less than $not_worth_it to build?"
If the answer is "more", then it gets dropped -- at least in its current state. It could be re-scoped later as a new item with a smaller MVP, for example.
If the answer is "less", then the developer can put in the time to get a proper estimate. I think there might also be an argument that if the backlog is properly ranked the detailed estimate also becomes pointless -- just work on it until it's done. No one should be doing detailed estimates on items that are more than a few weeks/sprints away in the first place.
Disclaimer: I've only recently been thinking about this abstractly, and have not yet tested this in practice, though I'd love to have this discussion with anyone that has.
Which is essentially just as inconvenient for the business to estimate as schedule is for developers.
They are more important in the organisation, so they don't, and instead insist on perfect estimates from the dev team.
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.
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.
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.
Can you clarify? If you meant "always search for the simplest solution" I agree. If you meant, "always do the easiest tasks" I don't.
I highly recommend this Rich Hickey talk (transcription):
https://github.com/matthiasn/talk-transcripts/blob/master/Hi...
I am not convinced that this is true.
I want a process that reacts to the situation, in favour of the product, in favour of longterm goals - who actively resists people who try to gamble it for whatever reason. Agile is not that.
"Agile" will never fix bad management, nor will anything else for that matter.
You don't have to make big promises when your client has ongoing clear visibility into your progress.
This may be doing Agile wrong, but if something can be so easily done wrong that it's common, I count that as serious flaw in the methodology.
The problem with this is that the stakeholder might not understand what simple means. It happens here all the time.
We get "simple" requests for verbiage changes, but after reviewing the story, the verbiage request isn't universal. It only applies to certain offerings, and the stakeholders only want the verbiage the be applied after a certain step in the application. This is still a relatively simple change, but when factoring in all the other "simple" requests that involve complex logic, changing displayed text becomes relatively complex.
We do sprints because it's our time box to see how close we are to hitting the mark. A sprint isn't a hard deadline in which the team must kill themselves to get everything finished. It's an arbitrary passage of time for setting goal to keep on track with what is going to be released. If you have something that's releasing two months into the future, it's easy to say that you can still make time although your first two weeks were riddled with unexpected complications and stoppages. A sprint forces us to focus on what should have already been completed to re-prioritize if necessary. And you can't feasibly do that without an estimation.
The two biggest problems with estimations are underestimating and treating estimations as promises. It's hard to estimate. So the best course of action is to make stories as small as possible. Probably smaller than someone would consider rational. If not, at least have the stories divided into individual tasks or chunks. Then once you have estimations, treat them as goals rather than deadlines. Use your sprint review as a time to honestly reflect on why the estimation was missed. Then, and this is critical to successfully estimating in the future, use the notes of reflection to make better estimates.
"Do the simplest thing" means don't overengineer, not necessarily that the feature won't be complex. You only code up what helps fulfill that particular story's definition of "done."
As for complex features. when my stakeholder asks for some big complex change it's almost always decomposable into much simpler stories. Maybe those have to be hidden behind feature flags until the whole epic is done, but they're shippable individually. Doing that decomposition up front helps demonstrate the complexity to the stakeholder and takes some pressure off of me. It also makes them feel secure because they have more granular insight into progress; that they're not sending me off on some Lewis & Clark expedition.
Very few managers / CEOs are going to let you get away with this.
Said another way, estimates are not promises. Don't crunch to meet them. I think it should be phrased as "no deadlines".
The whole sprint structure is so you're constantly adjusting your plans and estimations at some predictable time. Without a sprint you can end up with randomization.
It's like when car salesmen try to get you to name a number you'd definitely buy the car for and sign it on some not-at-all-binding-or-official piece of paper, like that means something, before they go back and "ask their boss if they can make it work". Psychological trickery bullshit.
"Do you feel comfortable committing to these stories?" Always a question.
Committing. If you don't make it for any reason not obviously caused by "outside blockers" you're morally responsible—and maybe even then. What are you, some kind of liar? Quite a step from an estimate. Kind of harsher than a deadline, even, which are oh-so-rarely as "deadly" as the name implies. But people close enough to Scrumish processes to get in the meetings but far enough away not to be writing code or testing things or putting out designs sure seem to like that word. Commit.
Also, "always do the simplest thing" is one of those phrases that can be twisted and morphed to support literally anything, which makes the phrase useless. It feels good to hear and say, but the reality is it doesn't help you out of a jam.
Sprints are exactly what you're describing, except with accountability built in. That shouldn't scare people, but it does, and that is what causes burnout. Fixing the fear around accountability is how you fix burnout, not eliminating the thing that your boss can use to justify your job.
It's a good mantra when under serious pressure.
Ed: see also: "practice makes permanent".
you just described doing agile wrong...
You're advocating for a version of agile lite, not agile.
Or alternative, agile is different to everyone you talk to and your agile isn't the same as someone elses agile.
Take your pick, but sprints, estimations, not only doing 1 thing/most important things are basic tenants of agile as most people see it.
If you can accurately estimate how long a software task will take, you should have already made a reusable component or automation to generate that code.
Estimates are meaningless. I've seen PhDs waste endless hours faffing with estimate-calculating spreadsheets.
Fundamentally, the universe is unpredictable. Chaotic and complex systems require their starting conditions to be measured to an infinite level of precision to be predictable. The Heisenberg principle means this is, as far as physics can tell, impossible.
On a more practical macro level, a complex adaptive system becomes unpredictable once three feedback loops are present (the three body problem is related).
Modern computer systems are unpredictable because we cannot predict the interplay between levels of abstraction.
It does not matter how smart you are. Unless you have perfect knowledge of all levels of abstraction in the system below you, even in a macroscopic sense you cannot predict the future. Precise estimates will be inaccurate.
Confidence ranges and superprobabilities are of some use. Discrete and precise estimates are an utter waste of time at best, and are dangerous and misleading at worst.
EDIT
Written on a mobile waiting for plane take-off, hence lack of citations. For more on complex adaptive systems, I recommend the works of Murray Gell-Mann and the research output of the Santa Fe Institute, particularly Scott E. Page.
EDIT: Of course there are projects where you actually know exactly what to do. Happens a lot in consulting. That has nothing to do with Agile though.
Hear, hear!
Note: This would require a _really_ good product owner that does not merely focusses on features, but also on feasibility and 'fitness functions'.
The rest of that article had me cheering all the way.
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.
I love it. Our management would murder you in cold blood for merely mentioning it.
Personally my main takeaway from the whole agile world is "people over process".
Sort out your communication, trust, and how you work together first. Then start looking at whether you want to work with agile, XP, scrum, kanban or some other recipe.
TL;DR So long as you are constantly mindful of Agile tenants, there's already built in awareness around burnout and sustainable practices.
For reference: https://agilemanifesto.org, https://www.scrumguides.org/
A sustainable pace leaves plenty of time for kicking your feet up on the desk in order to think about things. It leaves plenty of time for chatting with one's teammates to make sure ideas are fully baked before implementing them. It leaves plenty of time for trying out new ideas.
And, importantly, it leaves the time for doing this relatively unstructured. Because the dev team is a bunch of working professionals who should be free (and trusted) to figure out for themselves when they need to take a pause from cranking through tickets in order to do other stuff. A "3 weeks on, 1 week off" approach doesn't get you this.
I think that the spot where the car always ends up upside down in a ditch on agile implementations is a misunderstanding of the basic idea behind velocity. It isn't a KPI that you're supposed to maximize. It's a feedback mechanism that the product owner uses to manage the pacing of some of their own work, in order to make sure that the pipeline neither empties out nor becomes jammed full of work.
If the PO is doing that job correctly, then they would be making tough decisions about what is and is not reasonably doable in a given timeframe, and providing backpressure to stakeholders when they're asking for too much. If they're instead accepting every single feature request, and dealing with the resulting backlog logjam by continually pressuring the dev team to work faster and faster (and more and more sloppily), then, no sense in mincing words about it, they're doing a bad job as a product manager. And the dev team is well within their rights to push back against them on that.
Which, incidentally, is what the orthodox Scrum formulation is trying to do when it disallows the PO from deciding how many items (or story points, or whatever) to pull into the sprint. That's supposed to be based solely on the dev team's own opinion of what's a reasonable amount of work to take on.
This sounds great until you work someplace where you need to allocate 7.5 hours every day to a billable project.
If you don't allocate 7.5 hours you are asked what you were doing the rest of the day...
I've seen where someone won't have a conversation at work because they can't allocate a project to 10 mins chatting with work colleagues.
Or when you get asked a coding question from a junior and so you help them, but then need to get their project code they were working on so you can allocate that 10 minute chatting /giving advice to that project.
Or helping a junior with something they are stuck on, management sees and questions why two devs are sitting at one machine...
Look, the point of Agile is that the team builds the process that works best for them within the parameters of the work that needs doing. If you're burning out because of your process not working, change the process.
For most teams I've been on, a month-long sprint is too much. Once my team switched from 2-weeks to 3-weeks, and in that situation it was pretty good. But on other teams, requirements and priorities shifted frequently, and sometimes 2 weeks felt too long. This same "well that might work" pattern applies to most of this document's recommendations, in my view.
But kudos to the author for finding a system that works for them in their current situation.
Until the big names in the industry accept that error and address that, I guess there will be no hope for most people doing dev work.
Most companies on themselves don't have any incentive to address this fact because the commoditization of programmers benefits them and because they aren't in a position to understand the long term consequences of this (or don't care)
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.
If you’re discussing what you did yesterday, what you’re going to do today, when you think x is going to be completed, what is blocking you (other than that so-and-so owes you such-and-such), or anything else other than nodding that you’re good you’re missing the point and that’s where the slippery slope of pointlessness begins.
Still people also want standups, basically to hear what others are doing and feel like a team.
If it is as-needed to hash out an idea or determine the best way to fix something or to scope and point... that’s fine.
If it’s every day, twice a week, every MWF, etc. there is absolutely no way it’s actually necessary every one of those times and everyone is going to eventually defer to human nature and wait for the meeting to bring things up.
Part of that is natural and well intentioned - I’ve got the meeting in an hour, I won’t bother them yet, I’ll wait for it.
Part of that is natural and self-defeatist - if we already discussed everything then what will we discuss in the meeting?
The actual solution is to get rid of the meeting. The real solution is to just wait and discuss it all there. It’s like why I don’t call my mother the day before I go over to have dinner with her - we’re going to cover it all in the phone call and it’s going to be awkward silence while we eat.
And finally, if a standup is the best way you’ve found to make everyone feel like a team... there is no hope. That’s a really, really crappy way to make people feel included. Though that is what passes for team building at more places than not...
I'm surprised more companies haven't moved to this model. I don't really give a fuck what Jim is working on today, I just care whether his card that I have a dependency on is ready or not, or if we need to collaborate on it in some way. If the team is finding they don't know what's going on, or the board isn't being kept up to date, then this style stand-up will actually help with that, rather than just blowing 15 of my most productive minutes listening to everyone spin some bullshit story about how much work they crammed into 8 hours yesterday and why it didn't perfectly align with what they projected in standup the day before.
Going through all tickets would take a lot longer than having an update of all people so I don't think that will be popular, but I like to look at the tickets that aren't assigned to anybody yet at the end of most standups so that we don't lose sight of them.
The point is to keep social pressure on weak performers.
One of the main points of Agile (as implemented) is to push the team to perform. Otherwise natural habits of slack creep in. One or 2 people failing to deliver destroys all the good work of the strong performers. This is the real reason for standups.
In an ideal world this isnt needed, but many people need public reminders or prodding to unblock.
One pathological case I've seen is the Scrum meeting that would run for an hour, because it was attended by 25 people, every day.
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.
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).