We’ll Look at Traditional SCRUM — SO THAT We Can Better Understand How To Implement SCRUM for One.
SCRUM for one (SFO) is working for me — very well. Since I’ve been doing it I don’t have that nagging anxiety that comes from working on long projects for too long without feedback. I’m still working out the best way to implement SCRUM for One. But so far so good.
I’m becoming increasingly convinced that anyone who has to manage complex projects on their own can benefit greatly from implementing this practice.
SCRUM was originally
developed for teams
In a nutshell, SFO is the practice of developing a project in short sprints (1-2 weeks each), with feedback sought at the end of each sprint.
I believe it can help solo business owners, inventors, software developers, authors, and artists of all kinds to keep their heads in the game while working on big projects.
The most important part of SFO, in my mind, is that it helps you get frequent feedback and thus avoid the anxiety that comes from going too long without feedback on big projects. (Remember that frequent feedback is one of Mihaly Csikszentmihalyi’s three flow conditions. That anxiety that comes from going too long without feedback is a major flow killer.)
One source of anxiety is the fact that the longer you work on a project by yourself, with no feedback, the more likely you are to drift away from what your audience wants, and your sunk costs grow even as your uncertainty increases. That uncertainty in the presence of mounting costs often presents us with agonizing sunk cost dilemmas as we decide what to work on each day.
Another problem with going too long without feedback is that feedback is an opportunity to discover unexpected complications (see this post). More eyes on your project means more flaws will be noticed. And the earlier you catch complications, the easier they are to deal with (exponentially easier).
To my mind, these are the main benefits of doing SCRUM — whether as an individual, or as part of a programming team (SCRUM in its traditional context).
In this post I want to discuss briefly what SCRUM is in its traditional context (just the main elements so you can get a feel for how it works). I will follow up this post with at least one more on how to implement SCRUM for One.
This is not a full treatment of SCRUM by any means. But I’ll give you enough so you can see how it works and how it can be an effective way for teams to develop projects. (Christopher Avery has some interesting thoughts about Agile SCRUM and how it works with teams, if you want to dig a bit deeper)
In traditional SCRUM, there are 3 main roles:
- The Project Owner
- The SCRUM Master
- The Team Member
The Project Owner represents all the stakeholders in the project. This is the person responsible for being in touch with how the end users will receive the finished product, and either is, or represents, the major financial backers of the project. The Project Owner has the final say about what functionality the finished product should have.
The SCRUM Master makes sure the process runs smoothly. One of this person’s major responsibilities is to check in with team members to see if they’ve run into any obstacles that are preventing them from completing their work. The SM will work to remove impediments so team members can complete work as smoothly as possible. The SM is also responsible for holding the daily and weekly meetings.
A Team Member does work. Team members might include programmers, designers, graphic artists, copywriters, and so on.
In traditional SCRUM there are two main parts of a project:
- The current Sprint
- The entire project
SCRUM was developed partly in reaction against the shortcomings of the traditional “top-down” planning methods that went before. According to that top-down methodology (at least the oversimplified cartoon version of it) you plan a project out in complete detail before you start on it. You work out all the interactions and dependencies, and you know what all the features are that the finished product needs to have — before you even start. Then you just follow the plan to completion.
In the real world it’s almost impossible to anticipate all the interactions that parts (and sub-parts, and sub-sub-parts) of your project can have with each other. And end users often don’t know what features they want a thing to have until they start using it.
So SCRUM practitioners seek to have clarity about whatever is currently being worked on, and the rest of the project is allowed to remain fairly vague. The idea is that we might as well not spend time developing parts of the plan that will almost certainly have to be changed substantially by the time we get there.
In SCRUM we plan and execute only a part of a project at a time in detail. What part? Well, it has to 1) be something we can complete in 1-2 weeks, and 2) should result in something we can deliver to end users so the product owner can get feedback on it. The end users will be able to catch bugs and other complications, and will be able to suggest new functionalities they would like to have.
The sprint project can be carved off of the main project in different ways.
First, you can aim to produce a bare-bones prototype of the whole during the sprint, and then get feedback on that. For instance, an author might want to get a detailed overview of the story to her editor for feedback. Or a game developer might want to get a cheesy stick figure version of a game with only the bare essentials sketched in, so the audience can get the main concept and give feedback.
Second, you can do a sprint that develops a smaller “part” of the project. For instance, our author might want to get a draft of chapter one to her author. Or our game developer might want to present a fairly full featured character that can be ‘leveled-up’ in various ways — without advancing the rest of the game during the sprint.
Third, you could use a hybrid approach. For instance, if you’re remodeling/redecorating your house in your spare time after work, you might want to paint one wall, put in one fixture in the bathroom, and install one section of counter top in the kitchen this week, so you can show friends and see what they think of the individual choices, AND how they play together as a whole, before you complete the whole thing. This is kind of like doing “parts”, but it’s also an attempt to give them a sense of the “whole”.
Anyway, the main point here is that in SCRUM there are two main parts of a project, . . . the entire project, which aims at something big, but is left somewhat structurally vague, and the current Sprint which is planned in detail and executed mostly as planned.
In traditional SCRUM there are two main plans (or “backlogs”)
- The Sprint backlog
- The project backlog
Corresponding to the two main parts of the project are the two main planning tools, the sprint backlog and the project backlog.
In traditional Agile SCRUM both backlogs are composed of “user stories”, not “to do” items. A user story describes what needs to be done in terms of what the end user should be able to do. This does two things. First, it focuses the team member on the user’s experience. Second, it leaves room for the team member to solve the problem in her own way.
The Sprint backlog contains only the functionality that will be added to the project during the current Sprint.
The project backlog, on the other hand, contains other functionalities that, it seems at present, will need to be done at some point, but not during the current sprint.
The product owner is responsible for putting things into the product backlog, and prioritizing them, so that it will be pretty clear which items should be moved into the upcoming sprint (after the current sprint is done).
And, finally, . . .
In traditional SCRUM there are three main kinds of planning sessions:
- The Daily Meeting
- The Sprint Planning Meeting
- The Sprint Review Meeting
The Daily Meeting is a chance for the team members to assess what they should work on for the day and to mention any complications they are facing.
The Sprint Planning Meeting is the time when the team members, the SCRUM Master and the Product Owner come together to determine which user stories will be completed during the upcoming sprint.
The Sprint Review Meeting occurs at the Sprint Deadline. The team and SCRUM Master will typically review the last sprint, assess how much they got done (adjusting estimates for the future if needed), and figuring out what went well, and how things could improve.
That’s Traditional SCRUM in a nutshell.
I’ve left out a lot of detail, but that’s the gist.
The idea is that at the end of each sprint, you have something tangible to show to the Product Owner, and possibly to other stakeholders (such as end users). In software development you might release a new version of the code at the end of each sprint, for example.
This practice gets you the feedback you need to keep your head in the game, and to make good decisions along the way.
Now, SCRUM for teams requires more structure than SCRUM for one.
With SCRUM for One there is only one person to manage, one main project plan, and one person to review the work. So there’s really no more organizational overhead compared to what you’re probably doing right now.
The key will be to learn how to carve sprints off of projects such that 1) the sprints are 1-2 weeks long, 2) the sprints result in a chance for effective feedback from the market, and 3) the sprints add up efficiently to an excellent final product.
We will look at those issues in the next post or two.
P.S. As always respectful comments and questions are more than welcome. I’ll be around to continue the dialogue.
P.P.S. Chris Smith over at LifeHack.org found an interesting system that’s similar to the SCRUM for One approach I’m developing here: