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.