The basic idea is to adapt the various Agile practices for a team of one. Let’s start by taking a look at scrum master, user stories, one piece flow, product owner, backlog, daily standup, iteration reviews, retrospectives, unit tests, and refactoring.
Scrum Master of One
Since there is only one person in your team, you are automatically the Scrum Master. Congratulations, but try not to abuse your new found authority over your team. Remember, the Scrum Master is a facilitator, not a boss! The key thing that the Scrum Master does is to facilitate Agile. The Scrum Master understands how Agile works, makes sure that all of the meetings are happening, and also looks for and removes impediments.
If you are going to be an effective Scrum Master, you need to understand Agile development. If you can get your company to sponsor you to take a Certified Scrum Master course, that’s a great way to get started. If not, consider sponsoring yourself. It is expensive and will probably require you to expend two vacation days, but I assure you it will pay off in the end. Short of taking a CSM course, go and get a copy of “Agile Software Development with Scrum” by Ken Schwaber. You may also be interested in checking out my freely downloadable book “Do It Yourself Agile.”
Reverse Engineered User Stories
The next step is to start working with User Stories. A user story is a simple statement in plain English (or whatever language you are primarily using) that describes the work that needs to be done from the perspective of the end user. They are generally of the form “As a user, I want X” where the “X” describes a goal that can be achieved with the software to provide value to the user. For instance, “As a user I want to be able to purchase anything that I am looking at with a single click.” The user story doesn’t describe the nitty-gritty details.
I realize that since you are not the product manager (or business analyst), you don’t get to determine what you are working on or how it is described. The way that you can benefit from user stories is to reverse-engineer whatever description you have been given of the work you need to do into user stories. The benefit to you is that you will either have a better high-level view of what you are looking to accomplish, or you will immediately start to see holes in the description of the work you have been given. User stories give you a framework for thinking about your work.
Once you start using user stories, you will start having more questions for your manager or the product manager or business analyst. At first, folks may see your questions as annoying, but over time I believe they will see your questions as reflecting your interest in their success and the success of the company.
Divide and Conquer
Now that all of your work is described in terms of user stories, think about the size of those stories. Can any of the stories be further broken down? For instance, if you had a story that was “As a user I want a simple calculator function” you could break that down into “As a user I want to be able to add a number to an existing value,” “As a user I want to be able to subtract a number from an existing value,” etc. Breaking your work down into user stories has many benefits from an Agile perspective. We’ll look at just a few of them here.
One Thing at a Time
Most Agile teams use iterations for organizing their work. As a team of one, that probably doesn’t make much sense. Instead, as a team of one, try to do One Piece Flow. The idea of One Piece Flow is that you do all of the work required for a single user story before going on to the next one. Try to resist working on two stories at once.
Product Owner For a Day – Creating the Backlog
Ok, now you have a bunch of user stories that describe everything you’ve been assigned to do and they are as small as you can make them. It is time to put on your product owner hat. As product owner, you need to rank each of these stories relative to all the rest in terms of value. If you are not sure what the value of the stories is, ask around to see if you can gather enough information to make a reasonable guess. Perhaps you know one of the actual end users. Ask them what they think about the stories you have.
Over time, you’ll get better and better at ranking your user stories. No matter what you do, having some sort of ranking is much better than none. Rank all of your stories from most value to least value and start working on the top story. This ranking is called a backlog.
The benefit of having a backlog of small user stories and working on just one story at a time comes into play when somebody taps you on the shoulder and asks you to do something other than what you are currently doing. When you are interrupted, you now have some options. You can point to your backlog and say “where do you think this new request fits in this backlog? Is it really more important than this task that I am currently working on?” If you are lucky, the person interrupting you will decide that their request has a lower priority than whatever you are currently working on. At the very least, the backlog provides a framework for discussing the relative priority of the new request.
If the new request does seem to be higher priority than what you are working on, you have one more tactic you can try. Since your stories are small, you can say that you only have one task in progress and how much work remains on the current story and suggest that you finish what you are doing prior to starting the new task. Over time, this tactic should work more and more often as you get a reputation for delivering higher quality work and being able to quickly change gears. The backlog examination exercise should also slowly train other folks on the value of user stories and the backlog. Your goal should be to have folks give you new requests and for them to say “let’s see where this belongs in your backlog.”
Even if you have to stop whatever you are currently working on and start working on a new task, it is much easier to change course if you only ever have one story in progress at a time and it is small. Don’t forget to treat this new request the same as any other task. Create one or more user stories for the request and order them relative to each other at the top of the backlog.
Once you get the hang of maintaining a backlog, consider making your backlog visible to others. One way to do this would be to print out your backlog in a large font along with an indication of which stories you are currently working on and post it near you in a place that passersby can clearly see. You may even find that the number of interruptions goes down as people can see for themselves that you are clearly working on the most important thing and leave you alone to get it done.
Talking to Yourself
It may seem silly to do a “daily standup meeting” with yourself every morning. So don’t stand up. But do go through the exercise of going through the three questions:
- What have you accomplished since the last meeting?
- What are you working on next?
- What impediments do you have?
This will help to keep you focused on your current story. If you find that you just aren’t making the kind of progress you’d like to make, it is time to get some help! Let’s face it, if you go work on something else in the meantime, you’ll eventually have to come back to face whatever it is that is blocking you now. Yes, it is possible that you will solve the problem on your own, but why not at least find somebody to describe the problem to? Maybe the simple act of explaining the problem will provide a new insight. In any case, if you do end up working on something else, try to keep the total number of stories you have in progress to a minimum.
The Moment of Truth - Did it Work For You?
When you finish a story, now it is time to do an iteration review. Normally this would be done at the end of an iteration, but since you aren’t doing iterations, you might as well do the iteration review now. It is simple. Find somebody to demo the story to. The idea here is to have an audience and get feedback. If you feel like you aren’t ready to have somebody else see a demo of your work… then your story isn’t really done, is it? Keep working on it until you feel ready for an audience.
In Retrospect, That Was a Good Idea
Once you have finished your story and done the “iteration review,” it is time for the retrospective. Find a quiet place that you can spend 30 minutes or so to reflect back on how things went, from the time that you had the story ready to the time that you finished the iteration review. What went well? What didn’t go so well? What could you do better in the future? Write down your thoughts for future reference.
Unit Tests
If you aren’t already doing unit tests, now is the time to consider it. Unit tests are something that you can decide to do on your own for your own sake. At first it may seem that it is slowing you down, but consider all of the rework you have to do when QA finds problems with your work. Why not invest that effort into writing unit tests? If you are using Java, you can use JUnit. If you are using .Net, you can use NUnit.
Refactoring
Unit tests go hand in hand with refactoring. Refactoring is simply the practice of rewriting code to make it simpler to understand and change. The more unit tests you write, the more you will refactor the code and the easier it will be to understand the code and add new functionality.
Growing Your Team
See if you can get somebody in QA interested in what you are doing. You might look for their feedback on the ranking of your backlog or the quality of your unit tests. A QA person would also be a good person to invite to an iteration review. The more that QA sees the work you are doing as helping them, the more they will want to help make you successful. A close relationship with QA is an essential ingredient to Agile success.
As you practice these Agile techniques, I think you will find that you are producing higher quality results in less time as well as keeping focused on the work that the business cares the most about. You may also find that what you are doing gets noticed and appreciated. If you can get other folks to follow your example, you may soon find yourself part of a real Agile team. Good luck, and let me know how it works out for you!
If you enjoyed this post, you may also enjoy the freely downloadable book "Do it Yourself Agile."
1 comment:
I agree one of the biggest stumbling block to being Agile is to get part the cynicism of the Team members. The Team members were unwilling to suspend their disbelief and really try. For one organization I worked with, this was a significant barrier.
Post a Comment