Agile pondering: How does agile work with a team of 1?

See that picture off to the left?  That is me and my agile team!  It’s not a bad picture, but there appears to be something missing, right?  Where’s the “team” part of me and my team?  Well, you’re looking at it!  That’s right, I am a team of 1 for almost everything I do.  This has unique advantages and challenges over larger agile teams.  My goal with this blog entry is to give you some insight into how I make it work by telling you how I do it, and more importantly, the principles I try to keep in mind.  The idea for this blog entry came from a comment on a blog entry about Simple Agile back on October 6.  I have been doing some variation of what is written below for the past 18 months or so.  Things have changed a bit over that time (some examples are given) but I’m still basically doing what people would recognize as Scrum.  For those of you into Personal Kanban, I have a bit of that in here too.  Let’s see, maybe I actually do Personal Scrumban# (anyone who gets that is way too much of a Scrum/Lean/Agile geek!).

First off, while I am an agile team of 1 I rarely write software.  Most of my work is in areas of other types of content development and running a successful agile consulting business.  I use Scrum as the basic framework for what I do, but I obviously represent each role (Product Owner, ScrumMaster and team member).  It means I have conflicts of interest between those roles ALL THE TIME!  This is why a true team of 1 is very difficult to do well.  It is very easy to fall into the trap of doing the easy thing or the urgent thing and not the most valuable thing!  I use Scrum for myself, so below is the Scrum basic framework along with how I do it for my team of 1.

Scrum Roles

Product Owner, ScrumMaster and Team Member are all me.  I play different roles at different points in time as you will see below.  I am almost always working as a team member trying to accomplish the goals of the iteration.  On occasion I am a Product Owner prioritizing work and taking input from customers and stakeholders.  I rarely have to be a ScrumMaster.  The Product Owner role pops up at unexpected times because I believe in real-time reprioritization of the backlog (except for what is in the current iteration of course).  So after a phone call with a client or prospect, or after reading something interesting I may pop open my backlog and change some things around while adding or deleting others.  This system works well for me as long as I stay committed to not changing the current iteration.  I used to allow myself to change the current iteration as long as the new item replaced something I hadn’t started and I quickly realized that although I hadn’t worked on the item yet I had actually devoted significant thought to it so it was better to just follow through with it and do the new item the following week.  Like defects in the real world I do occasionally have the true necessary interrupt and I handle it like any other agile team – all hands on deck until the fire is out!

Scrum Meetings

Release Planning – This one I do quarterly or thereabouts anyway.  I drive my business forward one quarter at a time because that is about how much visibility I have into the future in terms of scheduling.  During my Release Planning I try to determine goals based primarily upon content delivery in various flavors (courses, blog postings, marketing materials, presentations, etc.).  I don’t really give myself sales goals for a variety of reasons (none that I want to go into right now).  Because I’m primarily dealing with content I try to determine roughly how much content of which types I can expect to complete during the quarter given my schedule as I know it at the time.  This is just a rough guess and I try to prioritize based upon upcoming events, grouping work of similar types, and new for December 2009 and beyond, according to my internal editorial calendar.  So far this works pretty well for me.  I do manage to hit the majority of my goals, but like in real projects I do have changes in priority and plans as the quarter goes on.

Iteration Planning – I do this weekly for one week iterations.  Sometime between Friday afternoon and Sunday night (depends on my schedule) I will look at my schedule for the week and try to determine how much work from my backlog I will be trying to complete.  I don’t usually do a sizing exercise because I have found I naturally break my work into chunks which are about equal size.  If I am updating a course I will have several backlog items, all approximately the same size for several different areas of updates.  Once I determine how much I think I can get done during the week I go through a specific procedure to turn it into a commitment for myself.  I’ll describe the procedure below when talking about the iteration backlog.

Daily Standup – For me it works best to review my day at the end of the day.  I see what I have accomplished, determine if it was sufficient and move plans around as necessary to try to get as much done as productively as possible for the rest of the iteration/week.  On occasion I will find myself behind due to unexpected circumstances (lengthy sales calls are the primary culprit and I am certainly not going to stop taking them!).

Iteration Demo – At the end of the week I review all my content and make sure it is what I wanted to create.  I try to take a step back and really be a Product Owner at this point and look at it all with a different set of eyes.  I have learned to be very critical of my work and this is when that comes in handy.  If I find something I don’t like I add it to the backlog for correction in the next iteration.

Iteration Retrospective – I do this between my internal review of content and my planning for the next iteration.  My main goal is to determine how I can improve my efficiency/effectiveness.  For a long time that consisted of recognizing times when I wasn’t as productive as possible and determining the cause.  I found out when I travel I don’t get as much work done as I hoped, so I no longer plan for a lot to get done while on the road.  Now I try to determine new ways of doing things or new tools/techniques I can use to help myself.  I do create a lot of documents from my retrospectives.  These tend to be standardized procedures that I can follow in order to accomplish certain things very consistently.  For example, I have a packing list now.  For as many trips as I take in a year you would think I would just pack naturally, but I always used to forget something.  Now I have a list that I update whenever I add something for a course.  The list includes clothing and toiletry items as well as every item I need for any type of course or seminar I might give.  I haven’t forgotten something in the past 6 months since I created the list!  I have several other lists or procedures which document things which are necessary to do consistently, or I do rarely enough that I used to have to look them up someplace each time.  Taking some time to reflect I have found to be critically important to me becoming more productive, and more important, happier with my life/work balance.

Scrum Artifacts

Prioritized Product Backlog – This one for me is pretty easy.  I have an editorial calendar with every day of the year on it.  It is stored in a multi-sheet Excel file.  I have all blog entries listed on it by date.  For other content I use a notes field at the bottom of the month to remind me what I want to try to accomplish during the month.  It isn’t technically a single list in priority order, but it is close enough for me to use it that way.  It also matches the way I think about things.  Having it look like a calendar allows me to better visualize it too especially because I color code days based on travel, or meetings or free.

Iteration backlog – Here is where it gets a bit crazy for me.  When I decide what I will be completing during the iteration/week I create tasks in Outlook for each item.  I use the description field to hold any relevant information like website links, emails, bits of text that I need, etc.  I save the tasks on the day I think I’ll be getting to them.  I used to put them all on the first day and just move all the ones that were uncompleted to the next day.  Unfortunately that led to some bad behavior when I started just “moving them around the corner” to the next iteration.  That was no good and I quickly realized I couldn’t be doing that.  Better to fail properly than to cheat!  So now, based on priority and available time I try to project where each will fall.  If I don’t complete one on the proper day then I’m just moving one item, maybe two, rather than the ten to twelve I would move from day 1 to day 2 previously.  Some people see me using an Outlook task list and they scrunch up their face and say ICK!  For me this works for a very simple reason – I use MS Exchange Server (ICK again, I know) which allows the task list to be sync’d between all my computers AND my phone.  I almost always have my phone with me and having the task list right there on my main screen helps remind me of my commitment to myself.  It won’t work for everyone, but it works for me.

Iteration Burndown – <blush> I don’t do one.  I don’t really need to because of the way I work.  If I am moving tasks forward a day I am behind.  If I am at Inbox:0 and Tasks:0 at the end of the day then I’m not behind.  Occasionally I finish early enough that I move tasks up a day or two.  Because a burndown chart is meant to give the team and management status at a glance I feel I am accomplishing the same thing just by knowing if I moved tasks or not.  I think I get the same result so I don’t worry so much about the implementation details.

Principles for very small teams

Let me finish by giving a list of five principles I think are important to follow for very small or micro-teams.

1. Have all of the roles even if one person holds most of them.  On a team of 1 you need to be your own Product Owner and make the RIGHT decisions on priority, not the “oh this looks easy so I’ll do it first” type of decisions.  Having all of the roles will help you hold each other accountable on small teams as well.
2. Do all of the meetings, but do them in a way that makes sense for your team structure.  Very small teams sometimes think a daily standup is pretty silly.  I find it to be extremely important for my success.  Do all of the meetings and try to do them so you are meeting the main objectives those meetings would have for larger teams.
3. Have a prioritized backlog and use it to drive the work to be done.
4. Don’t let yourself or your small team slip into bad habits like not worrying about meeting your iteration goal, or skimping on quality to meet the goal.  Meet your definition of done each and every time, or you will regret it down the road.
5. Collaborate on small teams.  When you are a team of 1 try to put yourself into the various roles by coming up with different ways of looking at things.  When I am a team member I look at things in terms of getting them done reasonably well.  When I act as a Product Owner I try to put myself in the position of never having seen the content before and looking for the holes.  This helps me to get it right more often than not.

I’m sure there are a lot of things I’m leaving out, but these are the basics of what work for me.  I’m sure a year from now I could write this same blog entry and be doing things very differently.  In fact, I hope that is the case!  I want to think I will continue to improve my work habits and results each week and if it looks the same a year from now I’m afraid I will not have improved at all.

Until next time I’ll be Making Agile a Reality^® for me and my team by trying to improve on what is written above!