Two week sprints, while not mandatory, became sort of unwritten rule and for me is one of the worst aspects because the amount of overhead and interruption versus uninterrupted work routine is a really bad ratio. Out of 10 days of work, two of them are kind of bizarre special days. Even if the reviews and planning cerimonies take only one hour each, those two days have a different vibe.
Other problem is that doing any kind of deep work in a two week sprints is highly risky. You don't want to get to the end of the sprint with anything 90% done, because it doesn't matter, you're a failure. And when you have other things to do beyond crunching tickets, anything that would take more than a couple of uninterrupted days to be done become highly risky, because the deadline is there next week looking at you.
You have 10 days of work, two of which go to planning and retro. Now you have 8.
But, is there any kind of testing process before the release? Almost no one has CD. CI, sure, but CD? Almost never. So if you assume a few days for QA if you have it, now you have 5 days to work. Only, the pointing was done with "T-shirt sizes" without really knowing how to do the work, and you're dealing with code created by this very process, so it is sloppy code, built in a pressure cooker, and you have to understand what the last person did before you can extend it. You'd like to make it better, but then you'll look bad compared to anyone who doesn't roll something over to the next sprint and ships whatever hacks work, however vile.
Good luck!
My solution is to ignore the deadline and do what's right and explain why, as I go. This will only work with great product folks, not mediocre ones.
Agreed. I dislike working on Scrum teams, but I will if they are at least trying to do it well. Even so, at this point I refuse to work on a team that does 2 week sprints. It just doesn't work as well as 3 week sprints, for the reasons you outlined. So if a team has chosen that timeline, then they are going through the motions of Scrum because of "how it should be done", not because they have been reacting to their own results and retros.
I think there's a deeper issue to identify here: this model means that you and your team are 2 or less weeks from "failure" AT ALL TIMES. There's a psychic cost associated with that that doesn't really facilitate creative work.
It's crazy that the term "sprint" stuck as a way to describe a development cycle. The last thing I want to do after a sprint is another sprint.
in running, what do you do after you sprint? you rest, not sprint again. yet in this tortured metaphor we keep sprinting and then sprinting again and again. where's the cool down walk, where's the stretch and refuel, where's the hydration?
Scrum, as it is practiced, is all the shitty parts of water fall without any of the work being put in on the business side.
Candidly what every org is missing: accounting. IN a very literal sense. How much time did we spend on a feature, what was the cost. How much does it cost to run the feature? How much do people use the feature? Are we gaining or loosing clients because of it? Stuff someone from accounting into every dev team and make them live and die by the numbers.
A lot of features for resumes will die quick deaths.
Heck. I came here to make essentially the same comment.
I miss the 90s when we did XP.
Another complaint I have about Scrum is its structure assumes you have a good idea of what you're trying to do. Agile was supposed to reduce the cost of design changes.
Also... is there anyone who uses Scrum who doesn't use Jira? At this point Scrum is essentially the same as saying "Our organization uses Jira. No one in my organization knows how to configure it because we don't want to pay to send the guy who manages it part time to training. And when we paid for the consultant, they asked all sorts of questions like 'how are your projects laid out?' and we said 'uh... we hired you to tell us how we should do that' and they said 'you need to know how your projects are laid out' and we said 'heck, batman, we don't even know what the hell we're really building because we're waaay early in the requirements gathering and design' and they said 'how cute, call me when you know what you're doing' and we said 'yeah... i think we can randomly click buttons on the Jira interface without your help' and our VP said 'we need to monetize our synergy by leveraging our learnings and develop asks for cross departmental interfaces' and i said 'absolutely, Bob, I'll just be over here writing a distributed map reduce function in Erlang' and my management chain said 'CI/CD is hard, let's just do GitFlow and hire interns to randomly type YAML files we upload to AWS' and at this time I tried to wake up but it was not a dream."
Which is to say... Scrum adds structure to the things that are easy to add structure to and seems to avoid having people think about the problems. You ABSOLUTELY can do Scrum without it devolving into a crap-fest, but it's not easy and you wind up using other tools, often without telling your management chain.
One of the best decisions my org made was to hire a dedicated Scrum Master. She configures all our projects if we want her to and she knows exactly the problems to avoid, the right questions to ask about how she should configure things, how to set things up so it simplifies our monthly project budget reporting meetings, and generally keeps us honest during standups (you guys have really low velocity; are you being interrupted a lot?).
Possibly, the second best decision was to give individual projects the option to use the Scrum Master or not, and leave that decision up to the team lead, including whether or not Kanban might be a better choice for that particular team.
I'm not anti-Scrum, I'm anti-people-doing-stupid-crap-and-saying-it's-Scrum. Sounds like you have a decent environment with people who sort of know what they're doing. Are you hiring?
> is there anyone who uses Scrum who doesn't use Jira?
Yes, there are quite a few shops that use scrum without using Jira.
However, I'm not aware of a shop using Jira that isn't using scrum. This is useful to suss out job opportunities at companies who use scrum but don't want to advertise it. If they mention Jira, I know it's a scrum shop (important to me because I want to avoid scrum shops.)
Funny you mention that. I was going to say "oh no. you can do Kanban with Jira," but then I remembered that every place I've seen that "does Kanban" is really doing some local spiral-waterfall-esque process, but using the Kanban board on Jira. And even those are using Kanban without telling their management chain because their management chain would freak out because they can't spell Kanban and after going to "Scrum Camp for Managers," they at least know how to spell Scrmu. (very clearly this is not all managers. I've had the pleasure of working with several people who really know what they're doing. But I think it's all to often you find a stunned management chain who's trying to make sense of Scrum.)
I should have been clearer as to what my point was: Just 'cause you're using the tool (Jira) does not mean you're automagically using the process (Scrum).
And maybe a related side-point: Scrum (like Agile) is a way of thinking about software development. Not everyone gets that. That might be the value of a good Scrum-Master. I've yet to see a good Scrum-Master in the wild. Most of the ones I've encountered are just dudes who tweak Jira settings half the day and use the other half of the day poking at Jira's SQL schema so they can fix config errors they made before they learned how the current version of Jira works. Or... in other words... if you're only filling out Jira tickets and only doing the ceremonies, then you're leaving half of Scrum's value on the table. Too many people do this.
> Just 'cause you're using the tool (Jira) does not mean you're automagically using the process (Scrum).
Absolutely. No tool can successfully make the process. Its job is to make the process easier.
> That might be the value of a good Scrum-Master. I've yet to see a good Scrum-Master in the wild.
Let me share a secret. I'm a trained and certified Scrum Master. You're spot on about it being a way of approaching things more than anything else. Software development is in large part an exercise in complexity management, and the Agile approach is fundamentally a very useful way of conceptualizing how to manage complexity at a very high level of abstraction.
But as practiced, I've soured on it quite a lot. The ideal is... ahem... ideal, but what we tend to see is kind of a funhouse mirror version of it that, at best, isn't helping. Different flavors of Agile are better (Kanban) or worse (Scrum) about this, but it affects all to one degree or another.
I was also at Amazon. We used a slightly modified version of scrum in that at least my team wasn't afraid to push back on ceremonies we didn't think we needed. Sprint planning? virtually always. Sometimes without the planning poker deck. Daily standups? virtually always. Retrospectives? not as often as you might think.
But... was decision making authority devolved to the team, SDM or TAM? ABSOLUTELY NOT. Our code was nothing but a series of queries to config settings and simple math. And even then it took weeks to get a decision on how things should work so we could tweak the config settings used in code that was now difficult to understand. Refactoring? pish! Unit tests? who wants to test every class? (i.e. - management didn't understand what unit tests or TDD were.)
My experience with Amazon was we toed the line for the easy bits of Scrum (ceremonies, etc) but the stuff that seems to matter where wildly different between teams.
If someone asked me "Does Amazon use Scrum?" I would say "in theory, but not really in practice."
In 2016 when we all moved to the new issue tracking system, I sort of wished we could use Jira. For most of that year my team put Todos and Issues in the GIT repo along with the code because we were tired of losing days of info in the system as they kept reverting to known good versions and losing issue tracking data (because the format of the data was dependent on new code that was just reverted.)
Though I do know that parts of amazon (AWS, Studios, etc.) were able to avoid the majority of the problems. I had hoped when Andy took over the whole shebang, things would get better. But after poking my head in last month, things as the bit-A seem to have gotten a bit worse: interns and SDE II's still do all the coding (one of the reasons i left; i'm not an intern and i like coding), but no-one on the team I was called in to help still hadn't read any of the TDD books and just assumed a unit test was a test you wrote to test a single class, because a class is a unit.
But let me stop bitching about a company I don't work at anymore and say I don't disagree with you but it brings up a point I should have mentioned: "Scrum" probably means different things in different teams. Big companies have a lot of teams that might all say they're doing "Scrum", but they're doing it in a very different way. Some will ignore the intangible aspects of Scrum and Agile, and only use the tools (like Jira). Others will be adamant that every ceremony must be performed at exactly the right time. Most will try to do the best they can even though product management has their heads so far up... hold on... i should be nice... i have worked with product managers that are excellent, i just wish there were more of them.
Yeah. Amazon is a big place with a lot of teams. They're probably all doing a version of scrum. And they're not using Jira. So we have an existence proof that it happens with at least big companies.
Scrum becomes the process that warps everything else about developing software at the organization. It is easily the strongest influence on how devs do their work day to day in most jobs I have had. And that influence is building quotas into every day, week, and sprint.
I have seen (and often done myself) all of the following X items to avoid Y consequences in Scrum.
- Not written unit tests to get a ticket merged under the sprint timeline. We eventually turned them off at one org as a hindrance to merging tickets. Seriously, our unit test runner failed and to keep the sprint on track we disabled the tests. And to keep the project on track, they were never repaired. Scrum demands the sprint always provide value and as value is only what is provided to the user, no tests.
- Inflated points totals and conspired with others to inflate points totals so management is convinced pace is improving.
I waited for my preferred and less diligent QA to be free to get a ticket done, so I am not interrogated holding up the burndown chart.
- Put unfinished functionality into the code as an error and merging it so that it would come back as a bug report, allowing the ticket size to be inflated for the same work.
- Skipping obscure edge cases found later if they would take more time, to avoid a lecture about the importance of detailed grooming. One job got to the point of specifying which files and functions needed to be changed for higher precision.
- Finished a task in the morning and then waited until the next day to pick up a new ticket because points is tied to days and you don't want the Scrum master asking why something is delayed in the burndown chart because you really only had half a day from when you assigned it to yourself.
The central failing of Scrum is that it is built on:
> Commitment, Focus, Openness, Respect, and Courage
And 1,3, and 5 in particular are either about different things for different people, or simply are absent because of the reality of a corporate hierarchy (i.e. it is always in your interest to suck up and seem reliable while hiding failures).
Sprints. I much prefer Kanban because it's just a list of priorities. You pick a task from the top and keep working, and the PMs keep the list sorted.
I hate sprints. It really feels like they're forcing us to come up with rough deadlines for arbitrary work, then treat those deadlines like a contract. We're playing ourselves.
I also hate all the ceremony around planning sprints. I'd much rather have a constantly sorted backlog and let the manager types focus on keeping the top tickets clear and actionable.
As much as there could be a fix, there is already a fix: Kanban and the existing 5-point agile manifesto (which trademark Scrum violates).
And to stave of possibly detrimental short-termism a culture of brain-storming systematic solutions to any significant problem (technical or HR) that has had a history of occurring more than once.
Work talk discussions should constantly revolve around tradeoffs instead of the word "deadline".
+1 to doing away with daily status meetings if unproductive.
Daily status updates are counter-productive, they create unwarranted pressure that leads to devs trying 'get it done' rather than trying to 'get it right'. In the long run, I don't think it helps with quality.
Beyond that, you're asking a bunch of (probably) introverts to have a social meeting every. single. morning. That couldn't possibly cause issues with job satisfaction could it?
I did scrum for the first three or so years of my career. In my latest role we don't, and it's a way, way better daily routine.
I don’t understand your comment: if you develop software as a team, it seems important to communicate and to know what the others in your team are working on?
Also, I really don’t see it as ‘social’ meeting, to me it’s a focused technical meeting about the work that is going on.
Yes to communicating with each other and knowing what you're working on, no to doing it every morning. Once a week, every two weeks, or once a month is fine. Any integral communication that can't be handled by the recurring meeting, can be handled ad-hoc as you go.
But people who have only done capital A agile and scrum are so buried in the philosophy that they don't understand that there are far better ways to do things.
I'm not sure how that's supposed works if most team members are burning through 14 tasks or 10 tasks or 5 tasks in a two week period. If your tasks are two week chunks, then you're doing something else completely different.
Over a 40 year career I've done all kinds of methodologies. If you understand that there are far better ways to do things, I'm all ears.
The big advantage to agile/scrum methodologies in my opinion: dramatically improved predictability. Total elimination of drama. Efficient management of expectations outside of the development group. Never having to do a death march ever again.
Only if you have not established a healthy async communication culture in your org. I'd say needing daily syncs to onboard people is a red flag that your remote org is not doing enough written communication.
Having a 1:1 with everyone on your team when you start works better. Admittedly, few teams take the time to do that. But doing so sets up a remote culture where people will talk to each other outside of scheduled calls. Because remote daily syncs often generate thoughts of, "Nah, I won't communicate now... I'll wait for the call". And that both slows down communications and bogs down the daily calls.
So I'll stand by the statement that if daily sync is your solution, you are missing part of the puzzle.
Daily sync can be on chat instead of meeting. For new remote personel meetings, explicitly state and have those specifically for the benefit of new remote workers. E.g., tell the team you will be doing daily status as a team for a week for the benefit of the new person.
Sounds like your daily standups were far more dramatic than they need to be.
I completed this task (or not). I'm working on this task. Any other discussions take place outside the meeting. Short. Sweet. No pressure. No drama required.
Scrum brings out some bad in software dev, but the worst in product management. It makes the schedule more important than the work, and the meetings more important than the communication.
Fix it with Kanban. Or at least the Kanban-flavored way of working where you set top priorities, keep lines of communication open, and just do what matters.
All processes can be screwed up if your leaders try hard enough, but Scrum is almost never the answer.
There's nothing wrong with making the schedule more important than the work, as long as you make it clear to product managers that they have to trade off work to meet a schedule. Or trade off quality, I suppose. But I am perhaps lucky enough to have never worked with a product manager that wanted a piece of shit when offered the choice.
The advantage to scrum when dealing with product management: an evolving prediction of what features you get, and when you'll get them. If you're neglecting the part where your product manager decides which features he can do without in order to meet his schedule, you're missing a vital part of the process.
That being said, I get your point with respect to sprints. There's something irrational about dividing work into sprints. But having done both, I prefer sprints. I'm honestly hard-pressed to say why. Maybe something to do with the psychological effect of feeling that you've accomplished something and done it well every two weeks, instead of once a year.
It may be true that one of the key traits of a software developer is low need for external motivation. But having done it both ways, there is something rather pleasant about getting those 30 second moments of satisfaction at having performed your craft well once every two weeks, instead of once every major product release.
In Kanban, you get that prediction of when features will be delivered by looking at the speed with which cards (on average) move across the board. If the average card takes 3 days, and you have 4 team members, and Feature card X is Y number of places down the board... do the math to know the timing. (And yes, that average takes some time before it is consistent, but so does the velocity in Scrum)
It takes some getting used to, but in the end the PM not only has the information of when features can get delivered, they have more control because all they need to do to change a feature's timing is drag it higher on the board. No meetings, no fuss, just drag and be done.
I think PMs who declare they need Scrum for timing purposes have never explored the equivalent timings in Kanban. If they prefer Scrum, that is fine... but claiming that Kanban can't time features is incorrect.
Why is Scrum special and needed to be fixed? The question is making an assumption. The point of agile is for the team to self-organize for effectiveness. My question would be where does Scrum fit into that, and how is a "one size fits all" hammer, agile?
For my current team, I like either sync or async (in Slack) standups that basically say if anyone's blocked or could use some extra eyes, and what's next in their sights. For a team project board, I prefer Kanban style without estimates--I've never seen velocity tracking used to any purposeful effect. If you want a team to build good features fast, don't bother them with "process theatre", instead ask the team lead/PM the questions and they should either have a good sense or be able to find out soon by having human discussions with the team.
I've had great success with velocity tracking. In my experience, once you have a team that's calibrated and humming along nicely, velocity tracking gives you an absolutely spooky ability to predict where the product is going to be two or three months time in the future.
Is it perfect? Of course not. But it's far more accurate than any scheduling methodology I've ever used over a long career.
I can't speak to why it didn't work for you. But I have seen it fail when an outside managers refused to allow proper calibration. Or when the same outside manager refused to make appropriate schedule or feature tradeoffs. In that particular case, velocity tracking predicted total disaster with 100% accuracy.
It seemed like a round about way of getting the team to come up with as good an estimate as to where the project would be in two or three months without it. And where it totally falls down is when you don't have data for the kind of work that's coming up.
It's a minimum trust technique. It assumes people can't talk to each other. Standups force people to communicate. Retros force teams to communicate. Demos are there to force people to prove that it's done.
The fix is... just trust? You can do standups async, in text. Or better still, expect devs to move tickets accordingly.
We moved to monthly retros. They're a good fighting ground - people will argue about how we do deployment, QA, etc. We often argue on scrum and processes too. These are useful to do frequently early on and then reduce later. Sometimes we use them when something is slipping.
You can have demos just to showcase new features, without having to demo the API or do it live. Live wastes a lot of time because things suddenly don't work or people show uninteresting parts like loading or navigating all the way from the home screen.
This is one of the biggest issues I've seen in Scrum setups. I've seen the pressure cooker standup where it's like going into battle, to less hostile ones where but you are still doing progress updates.
I've found a senior dev or team lead doing the Scrum Master role is a lot nicer since they are naturally on the developers side and can empathize with them when the unknowns start to surface.
I've had this at my latest position for a while and it's been incredibly healthy. The team is incentivized to actually work together when someone has a blocker or stuck on something. It also turns into a team spirit boost because we can shoot the shit while people hop in instead of worrying about posturing for management.
I rather like the idea of "days (hours) to complete assuming nothing goes wrong". With the explicitly given understanding that we all understand that these estimates are necessarily fictional.
Pros:
- It provides a common reference for everyone in the hope that developers might at least be consistently misestimating.
- It provides an easy justification for burndown multipliers, for those external sorts of people that object to burndown multipliers. "The burndown multiplier is a calibrated measurement of how imperfect scheduling estimates are (see The Mythical Man Month). Now go away and stop imposing unnecessary drama on my development team."
- It provides cover to those who assigned initial story points from being needlessly stressed over differences between estimated and actual effort (if you have one of those dreadful people who don't get it involved in your process).
the best I've seen is just treating them as roughly day-equivalents.
the problem with pointing is that a lot of tickets are really really trivial and the main expenditure is attention, not effort. and on the other hand, the cards that are big enough to warrant measurement are often chuck full of unknown unknowns.
Scrum works rather well in small, young, customer-less projects if it is being properly implemented and followed. The problem is that it doesn't scale well, Scrum struggles with bigger teams and multi teams projects.
I worked on a project (I do consulting) for a company that used scrum. The experience nearly gave me a nervous breakdown. The constant estimation and standup meetings were a total waste of time. I felt trapped unable to work on several tasks at once which is my normal MO.
I do like Kanban and use this for my current project. I will do estimation at some point .. but maybe not. My time is valuable and should be spent on working on the issues I have and not on estimation.
I have a proper backlog which contains tasks which are ready and are well described. I do have stakeholders with which I regularly communicate and modify the backlog.
So I do like parts of agile, just not the scrum methodology that I have been exposed to so far.
I just realized a new thing what i dislike about scrum. That is this argument people bring up:
“Scrum works … if it is being properly implemented and followed.”
Sure that is with almost everything. In addition if you need an army of scrum coaches to implement scrum and you see many failures in the industry isn’t it time to rethink the process how we create software?
Maybe scrum isn’t the solution but just a stepping stone that came after waterfall.
MVP bugs me sometimes - because oftentimes it is all you end up with. Yeah, it's minimally viable, but wouldn't it be nice to build something with bells and whistles and actually delights users?
It gives manager types a way to pretend talking is working while inverting accountability which is prerequisite for any process they're willing to adopt.
Scrum (or Agile, I can’t tell the difference really) kills morale and arguably performance too. It is mostly makework, and leads to more posturing and buzzword usage, which the enterprise already has plenty of. Hard pass from me. Also, sorry if you’re a Scrum or Agile person, but I’ve found that to be a largely bozo position.
Other problem is that doing any kind of deep work in a two week sprints is highly risky. You don't want to get to the end of the sprint with anything 90% done, because it doesn't matter, you're a failure. And when you have other things to do beyond crunching tickets, anything that would take more than a couple of uninterrupted days to be done become highly risky, because the deadline is there next week looking at you.