Scrum is causing me stress

Question

We very recently switch to scrum, from something more like a waterfall process. For what it's worth I don't have very strong feelings about any particular development process, but if it becomes clear that it's helpful for overall organization and team output I'm all for it.

We have 2 week sprints and tickets that we move through columns (design, implementing, review, etc.). We also have a daily standup where our manager screen shares and we go down the list and just check in with everyone. Standard procedure as far as I'm aware.

I strongly dislike this particular aspect. Especially since our work has been entirely remote for months due to COVID, my work output has varied a lot day to day. There are days I realistically get almost no work done. There are other days I get more done than I ever did with all the in-office distractions. So while I totally understand the value of examining work on, say a bi-monthly cadence, I don't feel looking at my day-to-do work is a useful metric.

WFH has gone on long enough that I know I'm producing enough useful work to not need to worry about my total output. I really hate being asked if I'm "stuck" or "need help" on an item though because it was valued at 3 story points and I've been "implementing" it for 2 days. Conversely there are times now when I finish work early and am purposefully slow to update the board to make it appear like I'm working at an even pace. Basically I try to make it look like I'm moving about an item per day regardless of how that's reflected in reality. Note that I took on a heavier load story point wise, and I am confident I'll have it all finished by the end of the sprint.

All that being considered, I think this is a problem with me and not with the process. I don't know how to model this in my head in such a way that I don't feel pressured to maintain the appearance of a consistent level of work. I think it's counterproductive for me to game the sprint board, but I also don't want to leave it idle for 2-3 days and then suddenly move 3 items over in one day.

Is this normal? How can I adapt to the process if so? If not, what I suggest we do differently?

Answer 1

We also have a daily standup where our manager screen shares and we go down the list and just check in with everyone. Standard procedure as far as I'm aware.

The scrum master should know ahead of time exactly which issues people are working on. Going through the issues is Stupid Ordinary Practice (SOP). The information that the scrum master should want is who is having problems, who is doing better than expected, and who is looking ahead.

Your team is doing it wrong. The approach your team is taking turns what should be a five to ten minute meeting that everyone on the team appreciates into a half hour or longer meeting that everyone on the team dreads.

I really hate being asked if I'm "stuck" or "need help" on an item though because it was valued at 3 story points and I've been "implementing" it for 2 days.

Every programmer gets stuck at some point in implementing something that perhaps should be easy. Unless this happens with regularity, there is absolutely nothing wrong with being stuck. Every manager makes mistakes at some point in estimating how long a task will take. Unless this happens with regularity, there is nothing wrong with making these mistakes. Two key points of these daily standups are to find the sticking points and to find where initial estimates were wrong. An even more important point is learning to improve on those initial estimates.

Conversely there are times now when I finish work early and am purposefully slow to update the board to make it appear like I'm working at an even pace. Basically I try to make it look like I'm moving about an item per day regardless of how that's reflected in reality.

NO! Do not do this. This is the road to mediocrity.

Task estimators make mistakes in their initial estimates. Sometimes their initial estimates are overly aggressive, but other times they are overly pessimistic. (I'm tempted to write that they always make mistakes. They hope their mistakes average out to being more or less correct.) The only way their estimates can improve is with feedback. You can help improve their estimation accuracy by reporting that you finished early. When you do so, look for something else on the issue list, perhaps some old technical debt issue, that you can attack.

Answer 2

You have one core misunderstanding:

So while I totally understand the value of examining work on, say a bi-monthly cadence, I don't feel looking at my day-to-do work is a useful metric.

The purpose of the daily is NOT to examine your work efficiency! It is not meant to find out whether you are a good worker or whether you are slacking off. It's purpose is simply to identify topics that are stuck, that blow out of estimations, that might require additional resources or help from the outside. Taking longer than estimated can be an indicator that a topic is more complex than thought (and thus a risk to the project) or that the manager needs to unblock you, e.g. by clarifying something with an external department etc. That's also exactly the purpose of questions like

I'm "stuck" or "need help" on an item

They are simply meant to clarify whether the low level indication that something takes longer, is actually a sign of a larger problem or just that a minor fluctuation (e.g. in productivity or estimation accuracy etc. which both is fine!).

Conversely there are times now when I finish work early and am purposefully slow to update the board to make it appear like I'm working at an even pace.

You are trying to game a metric that isn't there. (Or shouldn't be, unless your whole team got the wrong idea of why you do daily standups...). While this is somewhat working against the system, it's not breaking it, as long as you don't hide topics that you really are stuck on such that collective team action actually would make sense but cannot happen because they don't know about the problem.

How can I adapt to the process if so?

You need to get into your head that the daily evaluation isn't about you. It is about the team and your common goals. It is about identifying problems that can derail your project and that you can solve collectively. And you may need to make sure that you and your team are on the same page on what the daily is for and that fluctuations in productivity are normal.

(One side-note: While fluctuations are normal, one should also keep an eye on how long productive and not(so) productive phases last. If they (especially the latter) start growing in length, that might necessitate some self-evaluation, i.e. especially self-organizing in home office, it is easy to slide down a slope of acquiring bad habits. )

Answer 3

I'm going to approach answering this from a different perspective than "You people are doing Scrum wrong." You are, but then most companies are, and saying it doesn't solve your problem.

You don't like to talk daily about what your are doing and prefer a Bi-Monthly meeting/talk about progress. That is perfectly logical from the perspective of someone who is anxious about how his performance is perceived.

However, if you switch your perspective, a task is two weeks in development and then is unfinished because of some impediment, e.g. you need data from someone external to the team. That's bad if no one knows about it and it never gets escalated to someone who could do something about it, and developers in general tend to be not very good at escalating things themselves. Worst case, you lost two weeks of development time on a time critical feature or you notice that a task that should take two days took the whole two weeks because of some simple misunderstanding.
Scrum tries to avoid that by having a short feedback cycle - the Scrum Daily. The earlier a problem is known, the earlier it can be escalated to someone who can do something about that problem. As others already said, the Daily is not to check up on whether you worked or not, it's to make sure problems are recognized as early as possible. The earlier a problem can be solved, the smoother and less stressful development will be overall.

You are afraid of saying "I haven't been making as much progress as expected," and it being interpreted as "I've been slacking off," which is reasonable and a common thought in a classic development environment. However, not making progress or progressing slower than expected is something that happens to everyone, sometimes for multiple days in a row. You shouldn't be afraid of saying it, since the other developers will be in the same situation at other times, and if they aren't saying it, they are lying.
In a well functioning team it can lead to another developer who had a few good days taking over some of your work if it's close to the end of the sprint, leaving you less stressed in the end, because you don't have to finish all your work alone.
If someone asks whether you need help, honestly answer with a "Yes, I'd be happy if someone could sit down with me to go over X/take over task Y" or "No, I'm confident I'll finish the tasks in this sprint."

It's important to not just look at the Scrum Artifacts (Daily, Retrospective, Review, Planning) but to look at the Scrum Values (FROCC: Focus, Respect, Openness, Courage, Commitment), which are what is needed to make Scrum work.

You need to have the courage and openness to tell the truth and the others need to respect it. If necessary, you have to spearhead the openness and courage (i.e. demonstrate commitment), so the other developers will talk about it when they are in the same situation. Yes, it can be embarrassing at first to talk about lack of success, but you'll get used to it over time.

Answer 4

Will keep my answer a bit shorter. My impression is that there is a wrong interpretation of estimates. To quote someone more experience in the Agile world, all estimates are 'wrong', that is they are not predictions and are not meant to be. A 3 point task may take twice as long as a 5 point task, the point of estimating is that it is not possible to predict the amount of time it will take todo a task (else you would just quote hours right?), due to the highly complex (and often problem solving) natural of the tasks being done.

In scrum estimates are used to try fill the bucket of work you have as a team for the sprint. When you first start using Agile those estimate are going to be the least accurate. By your 5th sprint you estimates should have improved, and the retrospective ceremony should be the time to reflect on tasks and their estimates to try and improve them.

I would advise not holding off moving things slowly to fill the estimates, but make a note as to why that task was shorter. Lastly is the very important note that it is used to help the over all team time management, not the individual. We all have strengths and weaknesses, and each team member will take a varied amount of time to do a task, what ever the estimate says. That is why planing poker when coming up with estimates (as a team) is often used to help get a sense of how many points a task is. Sometimes when there is a large difference between team members, the one who points it lowest get given the task (not a scrum practise but something I have seen happen).

Hope this is helpful, and good luck with adopting scrum. When done well it can work great, but like any system when implemented badly has painful pit falls!

Answer 5

The change over from waterfall to scrum can take a little while, in fact unless everyone in the team is experienced in scrum before the change its going to take a number of sprints before you settle in to a rhythm that works.

tickets that we move through columns (design, implementing, review, etc.)

This is Kanban, and here's the kicker, you can still make use of Kanban boards even if you practice waterfall. If you go back to waterfall, please if there is one thing that your retain from your Scrum experience, make it Kanban

In a remote environment, SCRUM forces us to communicate more as a team and deliberately gives everyone the opportunity to be on the same page, both in terms of the goals of the sprint and in terms of the tasks that we are all working on. Yes we all have access to the kanban board, but we are probably filtering it to just those tasks assigned to ourselves. By changing our daily process to dedicate some time to get everyone together to go through our challenges and successes of the previous day it doesn't become an onerous task that we put off until it is convenient for everyone, we are still likely to remember most of the issues and worst case no one has moved forward more than 1 day worth of work before we find out someone else already solved that issue through a different task. Daily standups should be short, because in one day there is only so much work you can do.

SCRUM feels like micro-managing when moving across from WFH, we do need to be careful about getting hung up on individual tasks for the wrong reasons. As long as overall we are completing the sprints more or less on schedule, the rest will come out in the wash.

there are times now when I finish work early and am purposefully slow to update the board to make it appear like I'm working at an even pace.

RED FLAG! Do not do this, it is MORE important that you complete the Kanban board in real-time. Story points works two ways, initially we pick some arbitrary method of assigning points to tasks, what you almost always experience at the start is that we get that method wrong or our understanding of the task was insufficient at the time of planning the task. It is important at the end of the sprint to review the tasks that went under or over the expected time so that we can learn from that, don't be afraid of getting it wrong, as long as the tasks are up dated in real time, we can use this information as a team to make better planning decisions in the next sprint.

By not moving your task to the next stage as you complete it, you are effectively holding up your colleagues who need to review or test that work, YOU cannot do this yourself its about the team winning, not about your individual achievements.

I don't feel looking at my day-to-do work is a useful metric.

SPOT ON! Don't look at it day to day, the purpose of the sprint is that have identified a set of outcomes and the tasks required to achieve those outcomes, at the end of the sprint we reflect and evaluate BEFORE we move on to the next sprint.

If you want to game the sprint board, make it about quality not quantity, at the end of the sprint, what was your strike rate in terms of tasks you completed vs tasks that got rejected and also tasks assigned to you vs tasks assigned to your that were closed

By the end of the sprint you want to have completed a good percentage of the tasks assigned to you, all is good, but if too many tasks were assigned you have misinterpreted the effort required to complete those tasks. (or your capacity)

What looks bad on you is if at the end of the two weeks many of your tasks are left not closed. If you get heaps of tasks completed, but don't leave room for them to be reviewed and then closed your tasks as still incomplete. Its not about picking the tasks with the biggest story points to look good, its about picking a balance and getting them done. The larger story points should be spread out, so that one person doesn't burn out but also so we are not all dependent on individuals so we can complete our tasks.

The first thing that needs to go out the window is what your concept of what I can achieve in a day. Not just yours but everyone's... Even if you work the standard 9-5 (8 hr) day, when you factor in breaks, standup, documentation and management overheads... we need identify that less than 5 hours of that day can be used for effective work. Think about it , You lose 1 hour or more immediately to breaks, 1 to review of tasks, standup and preparation for it, 1 to distractions from our home lives or responding to or assisting colleagues. So don't think in terms of "that task should take me 4 hours, so I need to get 2 done today to be productive".

If you get more than 5 effective hours in, then well done to you, but have you interacted with the team enough? Did you get any code reviews in? Is it realistic to expect the same output from everyone?

The next thing that tends to go wrong is the story points and task estimates. As you've pointed out, its common at the start for everyone to be asking why you are still working on a story/requirement worth 3 points after two days. They'll be asking why you haven't raised an impediment or flagged the blocking tasks. Story points is a mechanism to specifically remove absolute time from the discussion, so you shouldn't use absolute time like '2 days' to evaluate it, instead story points is about identifying relative effort.

This can be hard to shake, if your SM is going to be heavy on time comparisons, then you should base task estimates on hours, not points. Points is still useful for requirements when having planning and priority discussions, but to commit to the SCRUM way and ease some of the anxieties of developers, it can be beneficial for some teams if you can find a way to not link estimates to absolute hours.

Daily standups, once everyone gets the gist of it should not take that long, you get a feel for what needs to be said about yesterday, and how to raise impediments. Its also not a time for discussing what is about to be achieved for this day, instead its about you identifying and committing to a minimum amount of tasks and calling out up front those tasks that need more time, either because you can already identify an impediment or dependent task that should be completed first.

The Last thing that you realise is wrong when moving over from WFH, a Sprint should not be determined by a fixed amount of time. The outcome of a sprint should be some form of deliverable or measurable outcome in the application. Generally the sprint forms the basis of your release cycle, which is similar to WFH, except in SCRUM we try to set smaller, more achievable goals. It's called a sprint because we are all running with maximum output towards the same goal. You don't run for two weeks with maximum effort, that's a marathon, in fact in a marathon you try to find a rhythm that means you put in the least amount of effort to keep you going over a long time!

The other analogy with running and SCRUM, is that you do not show up to a running sprint race without a lot of preparation. Think about the prep that goes into an Olympian attempting a sub 10 second sprint, the ratio of hours of preparation and planning to that short sprint effort is crazy, for a sprint to work well in SCRUM requires that the tasks generally need to be a lot more detailed than we can get away with in WFH.

So while we can say "lets do Sprints in 2 week blocks" it is important to make sure we identify exactly what we think is reasonable to achieve and ship out in that 2 weeks. You are going to get this wrong the first time, because SCRUM requires us to fully test and review each task as we go, its not about "how much work can we do in 2 weeks" its about breaking up the work so we can answer "what tasks (no how many) do we need to fully complete to ship which (not how many) requirements in 2 weeks"

The most successful conversion to SCRUM for me has required a two step approach, you can't easily convert an existing waterfall backlog into one that will work well for SCRUM, it takes effort. I try to assign the requirements to the sprint that I think could reasonably be achieved by the end of it, these requirements are the goal we are all focused and sprinting towards. The first phase of the sprint we assign those requirements around the team, everyone spends the first day or two reviewing the existing tasks or breaking those task down into sub tasks and assigning or updating the story points. Then together we spend a day reviewing and planning out what we think can be achieved by the end of the sprint, and then assign the tasks so that it can be done. Next day we start the actual sprint. First Standup involves everyone calling out the tasks they will do for today. Dailies after that involve a quick review of yesterday, did we complete all tasks, what held us back, what impediments do we need to raise. The SM steps in to reassign a few tasks if needed, everyone calls out which tasks they are working on for today and the cycle continues...

• At the start I actually add an additional column to our board to differentiate the tasks that have been designated to be completed today, vs tasks being actively worked on. At the next daily we can see what is left in that column, or the active column and we can talk about it together as a team. During the daily, we all drag across any new tasks until our daily column has a reasonable load, everyone has a chance to ask anyone for clarification if they don't agree and then we all move on.

Individually, we tend to bite off more than we can chew, because we are having daily reviews we need to learn to take smaller bites (and to share the apple around). In this way if someone becomes sick or unavailable their impact overall on the process and our progress to the end of the Sprint should be more manageable, because they hold less units of partially completed work.

Finally, in transitioning to SCRUM, it is important where practical to involve everyone in most aspects, that way we develop an appreciation for those roles that over time we will be less involved in. Yes at the start, stand up takes more time than it probably should and there is a lot of time where you're not just doing code work, but its not time wasted, just necessary time spent because our individual contribution to the planning and the team is greater than just the code hours we put in and therefore greater than it was before with Waterfall.

Answer 6

Scrum is defined by the Scrum Guide, which says, among other things, the following about the daily scrum:

The Daily Scrum is a 15-minute time-boxed event for the Development Team

The Development Team uses the Daily Scrum to inspect progress toward the Sprint Goal and to inspect how progress is trending toward completing the work in the Sprint Backlog

The structure of the meeting is set by the Development Team and can be conducted in different ways if it focuses on progress toward the Sprint Goal

That is, how a scrum team tracks progress towards the sprint goal is up to the team. If you feel a different way of tracking progress is better, discuss this with the rest of your team during the next retrospective.

PS: I get the impression that the flexibility and team autonomy of scrum is news to your team. If so, I recommend that everyone attend a scrum training, or at least take the time to read the Scrum Guide. In my experience, the Scrum Team must understand Scrum to use it well.

Answer 7

This is a known problem with Scrum and it is because proof of "productivity" is far more valuable than actually achieving anything.

The most realistic way to think of Scrum is as a micromanagement framework, theoretically designed to extract code from a developer in the same way that a drum and a screaming overseer with regular quota check ins might be used in a industrial age factory.

In software engineering this doesnt achieve productivity but it certainly helps maintain the illusion of progress which is usually sufficient for the kinds of companies that think Scrum is an intelligent idea (you may notice that the Google's and Microsoft's think it is dumb).

I think it's counterproductive for me to game the sprint board

Gaming the sprint board is exactly what you should be doing. It is how I finally learned to succeed in Scrum software development. Sprint board politics and always having progress to report for standup are 90% of individual success in Scrum.