Lots of you have been on teams that operated very lean and required lots of self motivation. Lots of you have been on wasteful, overly complex teams that spend more time planning than actually working. Some of you have experienced both. Maybe it worked, maybe it didn't. I've seen both and I wanted to share my thoughts on achieving a good balance of process and minimalism along with strategies to deliver something meaningful at the end of your sprints.
Do You Know Where You Are?
After reflecting on some bad project experiences, I've realized it's crucial for teams to be able to recognize when they're on track and when they're not. It's important to "know where you are on the field". By that I mean, where you are relative to your goals. Are you on track? Are you behind? Every individual should be able to answer these questions and a team as a whole should be able to answer these as well.
I think there are at least two problems here. The first is that people often don't ask themselves this question to begin with: "Am I on track". Waiting for someone else to ask you this is a problem because it means your progress relative to your goals isn't on the top of your mind. This should be treated as a high priority topic. The second problem is that even when prompted with this question, many people don't have a good answer. That's bad because it means they have no framework to evaluate their progress. It's important to have a framework that can output an objective measure of your progress and your standing relative to your goals.
Tasks Are Not Goals
Okay, so if those things are really important, what do I actually do with them? What does that actually mean for organizing a sprint? It's important to boil down the essence of what should be done at the team level and what should be done at the individual level. And our starting point for this should always be goals.
Goals should be set at the team level. A goal is something like "feature X is in production at the end of the sprint" or "feature Y is in QA by the end of the sprint". It's always "what is true at the end of the sprint". This is an appropriate level of discussion for a team and a product manager. It's not too granular and doesn't require getting into the weeds of "how". Between everyone on your team, there should be a good consensus of whether or not it's enough work. Fixing one bug is rarely enough work for an engineer to do for two weeks. Adding 3 new features might be, depending on size. This is the right granularity for a team to discuss and we'll see how individuals should dive further soon.
Once every member of the team has agreed to a set of goals for the sprint, we are by and large done with the team planning component. It's up to the individual to convert "what" into "how" through some implementation plan. My best success has come from taking a goal and working backwards from there. I'm taking an aspiration and converting it into a series of milestones called tasks, working backwards to present day. Do I need to be in production by Friday? Better be in Stage by Wednesday to allow for testing. Stage by Wednesday? QA testing needs to be complete by Tuesday. And so on, until you reach today.
These milestones should be granular enough that they can describe a day, but don't need to be any more specific than that. It may help to take something like "be dev complete" and turn it into "build out all helpers classes" and "update service to use new helper classes" if you think it will take more than a day, but we'll get to that later. We'll take each task and assign it to a day. This has some added benefits of popping any dependencies that weren't initially obvious as well as helping you to be proactive in your requests to others. Maybe you need QA to test something on Wednesday, but it's not sufficient to ask them on Wednesday. They've already got lots on their plate. This strategy helps you recognize that you need to ask in advance and you'll have a task for Tuesday (maybe) to confirm QA availability.
By taking the time to go through this process, you may also find that any realistic allocation of work will exceed what is sustainable. In this case, the process helps us flag early on (like, day one) that we need to de-scope a deliverable or remove a less important one entirely. As we move through the sprint, it will also give us the earliest possible flags if we need to negotiate with business stakeholders on scope.
My preference at this point is to make a Kanban board for myself. Since each task has a deadline and should take at most a day, we've set ourselves up to get a daily Kanban board basically for free. I like to set up a board that has two columns- just "To Do" and "Done". Every day that left side fills up and it's very clear what I need to do to stay on track.
This clarity gives me the peace of mind at the end of the day that I've done everything I need to do. There's no worrying about whether I'm on track. I don't feel bad if I finish early and leave at 5 pm. I also never have any surprises when my boss asks about progress. I know at any point in time if we're good or not. And I have all the power to turn "not good" into "good". I know when I look at my board if I need to stay later. It's great motivation when you know that you get to choose every single night to stay on track or not.
And since it's on my mind, I'm going to side track us for a second. This will likely be the topic of another post, but I think it is so important to separate planning and execution as explicitly as possible. I think they are two different skill sets that require two different states of mind. I love planning a project, planning the structure and relationship of the components. Planning what classes a service needs at a high level. Once I have this planned out, I enjoy sitting down with a drink and crushing through the actual code. I can trust that I've thought through most of the structure and now I just need to "do". I greatly enjoy both parts of the process for different reasons. This is exactly how I'd like a sprint to feel. When it's time to plan, I can focus on that. And then during the sprint, I can focus on execution. I can enjoy being in that headspace while being confident that I'll produce good results.
Make It Measurable
It's important to make things measurable and this should be a priority for anything you touch as an engineer. This advice from a former manager has served me well: "always take the extra step to make your impact measurable and to increase visibility". You can do this lots of ways. It could be as simple as measuring "before" and "after" stats or, even better, you could create dashboards and monitoring. I can feel your eyes rolling, and probably rightfully so for many smaller projects. But you get the point. Measure your impact and make it clear and provable to others. It's going to benefit you over and over and over...
I promise that paragraph relates to the rest of this post. Measurability will be important to your product managers, to whoever they report to, and so on. When tasks have deadlines attached to them, it's easy to calculate the number of completed tasks at any point in time and compare it to reality. Task completion from individuals can be rolled up to task completion for teams easily. At the end of the day, our strategy both solves the "personal progress" problem as well as your boss' "measurability" problem. Often, we find ourselves with separate, suboptimal solutions. Solutions that leave you sizing tasks by story points and time. That is tedious and if you can accurately tell me how long it will take you to debug an issue two weeks from now, I'll buy you a drink. It's a massive amount of time to spend doing something that everyone is terrible at. At least in my opinion, milestone based metrics are easier, solve multiple problems, and are more reliable than time estimates.
If you take away nothing else, take away that it's incredibly important to know if you're on track relative to your goals. To answer that question, you need to have a perspective on what being on track means. One way to have that perspective is to create objective, measurable milestones. It's useful to work backward from your goals, filling in milestones along the way. This allows you to uncover dependencies, flag when deliverables need de-scoped, and determine when lower priority deliverables need to be dropped entirely.
Epilogue: Two Minutes Rant
I wanted to take some time to rant about daily standups. Standups should be quick and no one should talk for more than two minutes. You should be covering what you did yesterday, what you're doing today, and if you have any blockers. It's also nice to toss in whether or not you're on track. And hey, now you have a framework to figure that out easily! The group should hold each other accountable to two minutes and "parking lot" anything that will take longer.
Parking lot conversations are important, but those topics shouldn't waste the time of team members who have no stake in the conversation. Pick those conversations up after standup with the relevant parties or set up followup meetings. Finally, I want to say that having to explain what I've been working on to my peers is a healthy amount of pressure to actually get work done. It sounds dumb, but it's at least true for me. Daily standups are important and I'll always have one as long as I'm running a team. Just, don't waste my time.
- Your Sprinting Engineer