How to apply agile processes to manage your life's projects
- The challenge of keeping up
- 1. Define the project
- 2. Build the backlog
- 3. Prioritize the backlog
- 4. Estimate the size of each backlog item
- 5. Plan a sprint
- 6. Hold daily standups
- 7. Complete the sprint’s tasks
- 8. Demo what you’ve completed at the end of the sprint
- 9. Get feedback about the results
- 10. Hold a sprint retrospective and strive for “kaizen”
- Conclusion
The challenge of keeping up
At the upcoming TC Camp, during a brief 5-minute feud activity, Marta Rauch and I are going to provide our perspectives on the following question:
How can I keep up with all the tools, technologies, info and other stuff to stay marketable? What happened to the good old days when all you needed to know was FrameMaker?
Admittedly, I can’t help but feel caught in the same technological rat race, barely keeping my head above water. I do have some strategies that work somewhat for me, but there is a guy who I think does have genuine insight. His approach is one we’re all familiar with and use daily in our jobs as technical writers in IT environments. Yes, I’m talking about agile and the scrum principles put forward by its co-founder, Jeff Sutherland.
In Jeff Sutherland’s book Scrum: The Art of Doing Twice the Work in Half the Time, Sutherland explains that scrum processes (a type of agile development) aren’t just intended for the software industry:
I’ve seen Scrum used successfully to build cars, run a laundry, teach students in a classroom, make rocket ships, plan a wedding— even, as my wife has used it, to make sure that the “honey-do” list gets done every weekend. The end results of Scrum — the design goal, if you will — are teams that dramatically improve their productivity. (p. 10)
In Sutherland’s view, scrum is a way of completing any project much more efficiently — in half the time. This approach isn’t something that works only for software teams or tech companies. It’s an approach for managing any kind of project.
Sutherland explains:
A further important point: working in a maximally productive way — the Scrum way — doesn’t have to be confined to business. What if people used this method to address the big problems our species struggles with — such as dependence on oil, or poor education, or lack of clean water in impoverished parts of the globe, or rampant crime? What if there really was a better way to live and work and solve problems differently? A way we really could change the world? There is. There are people using Scrum to address each of those problems I’ve mentioned, and they’re making a powerful impact.” (p. 21)
Can scrum be used to help solve the problem I introduced at the beginning, that of keeping up with the latest technology and information?
I think it can. Here’s a brief outline of how it would work. If you’re familiar with scrum or agile, you’ll recognize the main principles at work here.
1. Define the project
The first step is to envision your tasks as a “project.” (Scrum is a project management approach.)
For example, maybe the project is to be able to read Java code. You’ve seen this requirement listed on nearly every developer documentation job (“ability to read code in a major programming language such as Java, C++, or Python”). By learning to read Java code, you’ll be able to increase your tech skills and keep pace with some of the developer doc jobs that are in demand in the market.
Sure, reading Java may only be one component in a larger project (“Building expertise in developer documentation”), which in turn might be part of an even larger project (“Moving up in your career”), but whether it’s a component of one project or another, it’s still a project.
2. Build the backlog
Make a list of all the things you have to do to complete the project. This is known as the backlog. The backlog for a project on developing Java expertise might consist of items like the following:
- Read Head First Java by Kathy Sierra
- Complete Java course from the Cave of Programming.
- Write a sample Java app.
- Generate a sample Javadoc.
- Create a Java project that solves some problem.
- Contribute to Java documentation at a project at work.
When you finish all of these tasks, you’ll feel confident that you’ll have completed the project of being able to proficiently read Java code.
3. Prioritize the backlog
Identify the backlog items that will bring the most value. Not everything is ultimately worth doing. You should start first on the items that deliver the most value. As you make progress, you might find that some of the other tasks aren’t as important as you thought.
In the case of the Java items, probably contributing to the Java documentation at a work project would be the most valuable, but you won’t be prepared for this until you complete the other items.
4. Estimate the size of each backlog item
Assign a relative size to each of the backlog items — small, medium, or large. Alternatively, give them points equivalent to the Fibonacci sequence.
Sutherland says people are bad at estimating, so you want to compare the tasks to something more familiar, like comparing the tasks to the sizes of dogs. This allows you to make estimations based on relative judgments rather than direct point assessments. Is this task a Great Dane, Beagle, or Yorkshire Terrier?
Looking at my tasks, here’s how I might classify them:
- Read Head First Java by Kathy Sierra –> Beagle
- Complete Java course on Cave of Programming –> Beagle
- Write a sample Java app –> Beagle
- Generate a sample Javadoc –> Yorkshire Terrier
- Create a Java project that solves some problem –> Great Dane
- Contribute to Java documentation at a project at work –> Great Dane
Ultimately these relative dog comparisons do equate to numbers. In my scheme, a Yorkshire Terrier might equate to 3 points, a Beagle to 12, and a Great Dane to 34.
5. Plan a sprint
Sprints are usually two-week cycles where you work on items from your backlog. You don’t plan all the work for all sprints at once. This is the key idea of agile. You want to complete some work and then evaluate how things are going. Between sprints you decide whether you should alter directions or continue your same focus.
Pick your most valuable items from your backlog and move them into your current sprint. For my current sprint, I might start with “Reading Head First Java by Kathy Sierra” and “Generating a sample Javadoc.”
At first, you won’t know how many items you can complete in a sprint. As I mentioned earlier, each item has a set number of story points, which allows you to quantify the work.
After a few sprints, look at the number of points you’re completing each sprint. This is your “velocity.” When you know your velocity, you can project how long it will take you to complete the project.
6. Hold daily standups
Standup meetings provide short huddles with your team where you report your status. Your status covers three things:
- What did you do yesterday?
- What are you going to do today?
- Is anything getting in your way?
Each morning you can briefly look at the items in your sprint and single out what you plan to work on for the day. I like to put several post-it notes at the bottom of my computer monitor that refer to the items I’m working on.
Obviously, if you’re the only team member you won’t have a daily huddle with others, but you can still hold a standup with yourself.
7. Complete the sprint’s tasks
During the two-week sprint, try to complete all the tasks you’ve set out to do. You shouldn’t alter your course during the sprint — you work on what you planned to accomplish.
Exactly how should you tackle each sprint item? Well, that’s kind of up to you. The key is to complete it. By the end of the sprint, you should have a functional output that you can demo.
8. Demo what you’ve completed at the end of the sprint
At the end of each sprint, project teams should demo what they’ve accomplished. The demo should show a fully functional product. Sutherland says that demos are “the most powerful part of Scrum.” By “driving toward a demonstrable product on a frequent basis,” you show that you’re achieving real value and moving towards your goal (p. 16).
How would this sprint demo apply if you’re learning Java? Here’s one approach. As you’re learning, take notes. Draft your notes into organized, information-rich nuggets that you can read through to review the material. For example, I put some of my notes here:
By making notes, I’m trying to avoid living the story of Sisyphus, where I continually roll the same boulder up a hill, only to have it roll back again. I’m soaking in a lot of new information — through my notes, hopefully I can shorten any re-learning efforts as time passes and my memory fades.
By publishing my set of notes at the end of the sprint, I also demonstrate my knowledge to others.
9. Get feedback about the results
After the sprint is finished, ask your stakeholders and users for feedback. Are you going in the right direction? Are you delivering value? Does the product suck or rock?
Sure, you’ve just finished only a little piece of the solution, but getting this feedback is critical so that you can make good decisions for the direction of the project overall. The worst mistake you can make is working in a cave for a year and not emerging until you’ve finished the whole project. By then, your audience may tell you that you’ve missed the mark long ago.
Sutherland explains that checking for regular feedback is a key principle of scrum:
At its root, Scrum is based on a simple idea: whenever you start a project, why not regularly check in, see if what you’re doing is heading in the right direction, and if it’s actually what people want? And question whether there are any ways to improve how you’re doing what you’re doing, any ways of doing it better and faster, and what might be keeping you from doing that. (p.9)
With our sample project — learning Java — you are your own audience, so you just need to evaluate whether your effort is helping you develop Java expertise. Are you going in the right direction? Maybe the book you’re reading is too advanced. Maybe you need to switch to video tutorials instead. Maybe you need to do more hands-on coding. Take time to give yourself some feedback about the direction of your project. Make corrections to better align with this feedback.
If you’re working on a small Java project, show it to a Java developer to get some feedback. Ask him or her to let you know if you’re doing things right.
You could also share your notes with others to get their feedback. Maybe you’re misunderstanding some key points. Feedback can help align you in positive ways.
In fact, this is one reason why I publish posts on my blog. By sharing and getting feedback early in the process, others can give me the insight and feedback I need to correct my course early.
10. Hold a sprint retrospective and strive for “kaizen”
After a sprint, identify any impediments or other processes that aren’t working. Maybe you’re only getting a couple of items done each week because you’re too tired. Maybe you’re spending too much time in your escape zone because you’re burned out and are losing energy. Maybe you have too many things going on in your life and need to simplify. Maybe you need to alternate tasks more to avoid getting bored.
Identify some of impediments and remove them. You may not be able to remove them all, but by removing one or two of the things that are dragging you down, you’re putting into practice the notion of “kaizen,” which means continuous improvement.
Conclusion
Although I’ve been in agile software development shops for years, I never thought to apply scrum to the projects in my own life. I do think that the same scrum principles that shifted the software industry into greater productivity can be leveraged for ourselves. We are lucky because most of us are immersed in this process and are familiar with scrum principles, whereas many other industries haven’t yet adopted it.
What do you think? Can you apply scrum processes to better manage the projects of your life?
About Tom Johnson
I'm an API technical writer based in the Seattle area. On this blog, I write about topics related to technical writing and communication — such as software documentation, API documentation, AI, information architecture, content strategy, writing processes, plain language, tech comm careers, and more. Check out my API documentation course if you're looking for more info about documenting APIs. Or see my posts on AI and AI course section for more on the latest in AI and tech comm.
If you're a technical writer and want to keep on top of the latest trends in the tech comm, be sure to subscribe to email updates below. You can also learn more about me or contact me. Finally, note that the opinions I express on my blog are my own points of view, not that of my employer.