Is success or failure really a choice?  I don’t think it is at all.  Pretty much no one chooses to fail.  Unfortunately, we can’t just choose to be successful either.  What we CAN choose is to try to make a success out of a failure!  The old saying “Make lemonade out of lemons” really is a good way of looking at things, especially for agile teams.

Agile teams will have times when they “fail.”  I know a lot of people dislike using the words “fail” and “failure” when talking about team results.  I’m actually pretty tired of that argument because I don’t think it helps anyone.  I’d rather call a “poor result” a “failure” and acknowledge we can and will strive to do better next time.  As I say during workshops I facilitate, “I am blunt and reality based. Sometimes that means I will say things which you won’t like to hear.”  I don’t call teams “failures” or anything like that.  That would be namecalling and that is never appropriate.  However, calling results a failure is correct and leaves no room for interpretation.  I find being blunt in those situations to be more useful because teams then must face the reality and not try to sugar coat it as “not being all that bad…”

What comes out of failure is what I care about.  I don’t care so much how it happened, why it happened, who supposedly caused it to happen, or that it wasn’t all that bad really.  What I care about is acknowledging there is a problem that needs to be solved.  In my experience I find it easier to digest and solve if failures can be limited to happening only if 3 conditions can be met:

Conditions for acceptable failure

1. Fail FAST!
2. Learn from it.
3. Don’t do it the same way again.

Teams which keep these three simple conditions in mind when dealing with risk they often find themselves making better decisions and reacting more appropriately to the results of those decisions.  The areas of highest risk are where we are most likely to encounter failure, so how will we limit the timeframe to failure?  If we fail, what will we learn from it?  If we fail, how will we avoid failing in the same way again?  This is the heart of improvement.  Be open and honest about the result (failure).  Limit the damange (fail fast).  Examine the failure closely (learn from it).  Try a new way to solve the problem (don’t do it the same way again).

I see too many teams accepting failure time after time after time.  It is very frustrating to the organization and sometimes the team doesn’t even acknowledge there is a problem.  They keep saying they can’t do anything about it or it is an “acceptable failure.”  What does that even mean?  Acceptable to who?  Last time I checked, none of my clients were particularly pleased about failures.  This is where it gets dangerous to call a failing result anything but failure.  Calling it something else makes it somehow more palatable and easier to ignore.  Getting past difficult failures is the time of greatest learning and improvement for teams.  It changes regular teams into high performing teams, and high performing teams can become hyper-productive teams.

Don’t blow failures out of proportion (it really isn’t the end of the world), but at the same time don’t ignore them either.  Teams must deal with failures and turn them into successes downstream.  If they don’t do this then the failures will continue to cascade and cause a loss of morale, loss of urgency and ultimately a project or organizational failure.  Not dealing with failure is leaving a fuse lit on a ticking time bomb – I hope you defuse it in time!

Until next time I’ll be Making Agile a Reality^® with my clients by continuing to make sure they all understand the 3 conditions necessary for failure to turn into eventual success.

Related posts:

1. New to Agile? Beware of the elephant in the room! Like many other agile consultants I am often asked how agile adoptions...
2. Agile antipattern: Another burndown chart that lies! That burndown chart looks sweet doesn’t it?  The team finished the iteration...
3. Agile antipattern: Moving work from one iteration to the next All agile teams start at something less than the completely proficient level. ...

The theme of the blog this month is “Getting a Fresh Start.”  In order to get a fresh start it is important to know WHY you want to do it!  I’ve seen many presentations over the years about why agile is something a software development organization should use.  I’ve seen this sort of presentation called “The Business Case for Agility” and several other names.  I’ve seen people walk out of those presentations, go back to their organizations, implement agile – and fail miserably.  Clearly having a reason for using agile is not the only important thing.  I think many of these presentations are presenting some possible reasons for using agile, but they sometimes miss a key point – WHY are those reasons important.  In the spirit of Agile For All’s second agile belief, I’m going to try to explain WHY some of the popular reasons are important to consider.

Know why, not just how. Too many people are learning the “hows” of agile and not the “whys” that drive successful process. This causes much more failure than is necessary. We always teach whys and not just hows.

Having worked with clients that range from very small to very large I’ve observed an unusual trend.  Each client believes their problems and issues are unique because of their corporate culture, industry, people or something else.

However, I’ve also observed another unusual trend which goes directly against the first one.  Most of the time my clients are wrong in the belief they are unique!  Certainly there are some differences.  That has to be true or every company would be identical.  Many times even the ways the problems manifest themselves are different.  I know that sounds strange.  How can the problems be different if I just said the problems aren’t unique?  I’m not looking at the problems, I’m looking at the CAUSES!  The underlying causes are the same or very similar but the way those causes manifest as problems may be different!

Below are 5 of the popular reasons given for switching to agile (and one extra I added because I could).  I’ve added the problems typically addressed, but I’ve also added some underlying causes and WHY an organization would might see those results and want to address them.

This list is FAR from exhaustive.  I am sure there are 20-30 items in causes I have not listed.  I just wanted to make the point that the obvious problems being “solved” by agile actually trace back to potential issues which may are may not be directly addressed by an agile process.  For example, will organization structure be addressed by switching to agile?  Probably not, but it WILL be exposed as an issue if agile is done properly.  Organizations need to be prepared for 2 possibilities for each problem: 1) it is caused by agile, or 2) it is exposed by agile.  Most problems will be of type 2 and very few will be of type 1.  Some things may be caused by agile, such as the stress it causes as teams get used to meeting iteration deadlines.   However, most problems will be of type 2.  Are you ready to admit it and deal with those as they are exposed??? [note, this technique is based on a blog entry by Vikrama Dhiman where even more details for a good retrospective can be found]

I know the table above has a LOT of entries in it.  If you don’t understand one please leave a comment and I’ll try to clarify it.

Are you depressed now?  Don’t be.  Agile really can help solve most of those problems simply by exposing them!  It is often too easy to hide the elephant in the room.  Get it exposed then deal with it and your organization will get better!

Until next time you should look at the list of causes and see how many fit your organization.  After doing that exercise maybe you should call (303-766-0917) or email me so I can help you in Making Agile a Reality^® for your organization!  I’ll offer 30 minutes of free agile or scrum coaching to the first 10 people who email me mentioning this blog entry.  The coaching will start out via email questions, but will include a phone conversation if necessary.  If your organization is struggling, let me help!

Related posts:

1. Agile pondering: How does a highly mobile agile team of 1 work? In my last post I gave you insight into how I do...
2. Agile Pondering: Who leads an agile team? On Saturday, April 11, I ran a PMI Mile Hi workshop I...
3. Agile pondering: How does agile work with a team of 1? See that picture off to the left?  That is me and my...

Do you want to see several different ways agile and scrum burn-down charts can lie?  If so, you are in the right place! This month I went on a burn-down chart craze and posted several blog entries about the different ways those charts can lie to us or expose us to team dysfunction.  In order, the blog entries are:

• Agile antipattern: Burndown charts that hide the truth
• Agile antipattern: Taking on large stories
• Which led to New to agile? Learn how to split stories
• Agile antipattern: Burndown “wall”
• Agile antipattern: Changing the definition of done
• Agile antipattern: Another burndown chart that lies!

The whole series had a LOT of web hits, so clearly I’ve touched a nerve.  Good luck improving your agile or scrum metrics.  Sometime next year I’ll do a series on metrics in general.  Our current state of the art for agile teams is pretty pathetic because the data can be skewed so badly (as shown by all of these blog posts).

Until next time I’ll be Making Agile a Reality^® by helping people understand the real meaning behind their agile burn down charts.

Related posts:

1. Agile antipattern: Another burndown chart that lies! That burndown chart looks sweet doesn’t it?  The team finished the iteration...
2. Agile antipattern: Burndown “wall” Does your team have an iteration burndown chart (giving credit only for...
3. Agile antipattern: Burndown charts that hide the truth See that burndown chart over there to the left?  It looks beautiful...

That burndown chart looks sweet doesn’t it?  The team finished the iteration on time.  What could possibly be wrong.  Well, a lot actually.  Notice that one day this team completed a tremendous amount of work.  Do you ever see teams really do that?  It certainly could be a symptom of allowing large stories and they just got completed that day.  But I’m not buying it.  When I see a chart like this I immediately think the team is hiding something.  Most of the time they are hiding that they changed the scope for the iteration.  They saw their trajectory and simply said we have to remove some scope in order to have a successful iteration.  DO NOT BE TEMPTED TO DO THIS!!!  There are far better ways to fail.  If a team starts to believe this is ok then they will use it as a fallback position too often.  How do I know this is the situation?  Easy, I look at the burnUP chart.

A burnup chart measures not only completed story points for an iteration or release, it also has a line representing the commitment the team made.  In this case the chart is quite enlightening.

Now we can see a completely different picture of how the team performed during the iteration.  They removed scope from the iteration and faked a success.  They decided they didn’t want to move work from one iteration to the next (another antipattern I wrote about) and instead they failed in what I believe is an even worse way.  Nothing gets learned from failing in this way.  The team did not meet their commitment, but we really have no idea if they were even approaching it well.  Wouldn’t it be better to see what work was left at the end of the iteration and determine if the team at least worked in priority order?  Based on the work remaining we might even be able to come up with some ways to help the team.

Fail in the right way (leaving low priority items which have not been started is best) and learn how to do better next time.  Agile failure is ok if 3 conditions are met: fail fast, learn from it, and don’t do it again.  In this case the team failed fast but they don’t have a good way to learn from it and there is no incentive to do it again since it looks like a success on the burndown chart.

In case you can’t tell, I prefer for teams to use a burnup chart when possible.  It exposes more issues and keeps the team more accountable.

Until next time I’ll be Making Agile a Reality^® by helping teams understand it is important to be transparent with their metrics.

Related posts:

1. Agile antipattern: Burndown charts that hide the truth See that burndown chart over there to the left?  It looks beautiful...
2. Agile antipattern: Burndown “wall” Does your team have an iteration burndown chart (giving credit only for...
3. Agile antipatterns: Agile burn-down chart roundup post Do you want to see several different ways agile and scrum burn-down charts...

Ever see a burndown chart like the one to the left?  I’ve been on a big burndown chart kick lately and when I saw this one I just couldn’t resist using it.  This one is a bit different from my previous blog entries here and here.  This burndown chart is a release burndown rather than an iteration burndown.  It sure looks like the team was incredibly successful and finished early, right?  Wrong!  What this burndown actually shows is all of the stories being “done” and the release not actually occurring for several more iterations.  How is that possible?

Unfortunately this is a symptom all too common for agile teams, so learn from this blog entry and don’t repeat the mistakes of others!  What this shows is a lack of commitment to a definition of done.  I touched on this briefly when I wrote about using a rules of engagement document.  If you don’t settle on a definition of done the pattern in this burndown chart can easily occur.  This pattern can also occur when a team is trying to hard to meet their deadlines.

If you went back and examined what occurred in this example you would find a team pressured to try to hit a release date by working at an unrealistic pace rather than a sustainable pace.  In order for the team to keep looking like they were on track for an ontime release they built technical debt by not sticking to a strong definition of done.  The result is a tremendous amount of testing which was delayed and triggered massive test-fix cycles.  In fact, the original release date was projected for after iteration 6, but instead it took 4 more iterations to actually release the product.  Technical debt cannot simply be allowed to build.  Software projects don’t have the luxury of deficit spending like the US Government.  At some point the bill will come due and it will almost always come due prior to release.  In fact, if it comes due after release it is even worse – you now are in emergency mode because customers are suffering!

Rally Software recently posted their definition of done on their blog.  It makes for some interesting reading and gives good perspective for other agile SaaS companies.

Richard Lawrence has a recent blog entry on this topic as well.  Richard encourages teams to not build technical debt and in fact he encourages growing your definition of done in order to release high value, high quality software as quickly as possible.  It is fascinating reading based on his work at a large organization.

Until next time I’ll be Making Agile a Reality^® by helping teams agree and abide by their definition of done.

Related posts:

1. Agile antipatterns: Agile burn-down chart roundup post Do you want to see several different ways agile and scrum burn-down charts...
2. Agile antipattern: Another burndown chart that lies! That burndown chart looks sweet doesn’t it?  The team finished the iteration...
3. Holistic vs. Dogmatic Agile Definition – Results Matter! I originally wrote about this topic in our September email newsletter.  In...

In my last post I gave you insight into how I do my work as an agile team of 1.  What I didn’t mention is I am highly mobile.  I travel a lot to other cities and even when I’m in my normal city I have meetings all over the place.  How do you remain agile if you don’t always have access to the same environment?  Let me tell you, it isn’t very easy.  It requires lots of help from tools which work without me having to think about making them work.  It also requires forethought on how your normal workflow will occur.  Finally, it requires knowledge about how certain tools function so they can be set up properly.

To start let me tell you my setup.  I have 3 primary computers.  The first is a desktop which is strictly for home use, not business use.  It contains all personal information, personal email accounts, personal Quicken and things like that.  The second is a 17″ Dell laptop which is my primary business computer.  However, it rarely leaves my desk any more because I now also have a small 10″ MSI Wind netbook which travels wherever I travel.  They are all sufficiently powerful for what they need to accomplish.  For the purposes of this blog entry I’m going to leave out the home computer because it simply shares an external monitor with the 17″ laptop.  Everything else about it is totally separate from my work as an agile team of 1.

I also have some other equipment which I find invaluable.  I have a networked drive which is 1TB in size.  I also have an 8GB USB stick which is also a USB splitter (it takes 1 USB port and turns it into 2 while also being an 8GB USB drive).  I also carry a USB cable which plugs into my phone for both charging and transferring data.  I also don’t go anywhere without my smartphone which runs Windows Mobile.  These extra devices are a necessary part of my overall strategy of being agile while being highly mobile.  They are probably overkill, but I am an engineer at heart so I’d rather have redundancy than have an unrecoverable issue.

Finally I have multiple email accounts “in the cloud” including a Gmail account and a Hotmail account.  For my company email I use an Exchange Server that allows Direct Push as well as Outlook Web Access.  I have access to Google Docs, Google Wave, Twitter and a host of other things which aren’t important right now.  I only mention these because they do come into play on occasion.

Wow, now that I look at it I am seeing quite a list!  No problem though, everything has a purpose and none of it is even hard to set up.  Costly maybe, but not hard

On my laptops I basically use only a couple of indispensible tools: Microsoft Office Ultimate (why in a moment) and a browser.  Everything else doesn’t matter a lot.

My normal workflow

In the first paragraph I said you needed to know your normal workflow in order to determine how to configure a system which would work for your usage patterns.  In my case I do some things like email, reading group mail and reading other blogs quite a bit.  I also edit my blog, maintain my calendar, browse the web, Twitter and edit documents almost every day.  Those are all things I do whether I am in my office or on the road.  When I am in my office I also may be doing things like maintaining the company financials.  When I am on the road I am often giving presentations of some sort or creating a document as a result of my work.

My solution

They keys to my solution are Microsoft Exchange Server, Microsoft Groove, an automatic backup program, and the Windows Task Scheduler.  These 4 items do all of the dirty work behind the scenes so I can just use one of my computers and know I’m in good shape no matter what  happens.

• Microsoft Exchange Server – This is important because it keeps a copy of my important correspondence, my task list, my calendar and my contacts “in the cloud.”  I can access it from anywhere via the web and Outlook Web Access.  I can access it from my phone, and more importantly, the changes are always PUSHED to my phone in near realtime so I don’t have to think about it.  I use many folders to store correspondence by type and Exchange keeps those folders available to me whenever I need them.  Both computers are kept in sync as long as they are online and have Outlook running.  I know people are starting to like the Google solutions (Gmail, calendar, etc.) but I just can’t get the same level of comfort with those as I do with Exchange.  It’s probably because I’m an old fogey.
• Microsoft Groove – THIS is why I purchase Office Ultimate edition.  It is the only edition that includes Groove.  Groove keeps a “workspace” in sync between 2 or more computers.  Without any human intervention!  It is a marvelous program – at least for me.  I have an “AgileForAll” workspace on both of my laptops.  As long as a laptop is online it will automatically sync all files in the workspace to the latest version.  If the latest version is on the laptop and it is different from what is available to other computers (in other words I edited a file in the workspace while offline) it will push those changes into the cloud for later downloading by other computers set to sync.  This requires ZERO work on my part.  I don’t even think about it.  If I edit a file and save it, as long as I am online and the other laptop is also online, the changes will just show up on the other machine, and usually very quickly (less than a few minutes).  My workspace has quite a few separate directories which lets me keep everything organized.  I even have a backup of my website in the workspace so I can change it easily from either machine!
• Automatic backup program – It doesn’t really matter what program you use as long as you can do full and incremental backups.  I back everything up each night to the networked drive.  When I’m on the road that laptopt doesn’t get backed up, but it syncs the important files to the othe laptop which IS backed up so I’m still protected.  I have things arranged so I can go back at least 30 days and not lose anything.
• Windows Task Scheduler – This one isn’t all that important, but it helps me sleep at night.  During the night if a thumb drive with a particular file is available then the laptop will make a raw copy of the Documents directory (which includes the Groove workspace), as well as some other important files like Outlook files and Quickbooks files.  This is not a regular backup which is usually compacted.  This is just a raw copy to the USB stick.  This means I have all of my work on the USB stick, on the network and in the cloud in case anything happens.  I use a couple of different USB sticks and keep one offsite.

This setup allows me to use either laptop at any time in any location and have access to all of my latest stuff including documents, presentations, calendar, contacts, task list and email.

This works for me a lot better than trying to use a remote desktop application, but just in case, I have GoToMyPC installed on all my systems too!  There is probably a lot of overkill in this system, but it isn’t anything I have to think about therefore it isn’t causing me to have waste in what I do.  Once it is set up it all just works.

There are some shortcomings though.  I don’t currently use a versioning system of any sort.  I tried to use both SVN and git but neither did quite what I wanted.  They required me to THINK about keeping things in sync and I didn’t want to do it at the time.  git also didn’t work because it made my system very unstable.  It crashed twice within an hour of installing git, even though I wasn’t using the program!  SVN works well and doesn’t crash my system, but I’m not quite sure yet how I want to use it.  I may at some point have an SVN repository in the cloud and do some automatic check-in, but I haven’t decided that yet.

This is a long entry about a problem most people don’t have, but if you do have this issue, perhaps this will help!  By the way, this works just as well for keeping a desktop/laptop combination in sync, or a work/home computer, etc.  It just happens that those problems are baby versions of a highly mobile agile team of 1

Until next time I’ll be Making Agile a Reality^® for myself by not thinking too hard about mobility because I’ve already solved those problems!

Related posts:

1. Agile pondering: How does agile work with a team of 1? See that picture off to the left?  That is me and my...
2. Agile antipattern: Moving work from one iteration to the next All agile teams start at something less than the completely proficient level. ...
3. Agile pondering: Why use an agile approach? The theme of the blog this month is “Getting a Fresh Start.” ...

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!

Related posts:

1. Agile pondering: How does a highly mobile agile team of 1 work? In my last post I gave you insight into how I do...
2. Agile antipattern: Moving work from one iteration to the next All agile teams start at something less than the completely proficient level. ...
3. New to agile? Work at a sustainable pace Question:  Which is better: a) Working nights and weekends to meet iteration...

This presentation was originally given at Agile 2009 in Chicago.  Richard Lawrence and I wanted to give teams a bit of hope if they weren’t quite doing agile.  In order to do that we gave a presentation helping them understand some of the basic issues.  However, we also recognize every organization is different.  We didn’t want to give cookbook answers when the kitchen wasn’t always the same.  So instead we gave attendees a way to help reach resolution on their problems.  This is based on the Thinking Process from the Theory of Constraints.  Below is the presentation from SlideShare.  It mentions creating clouds as exercises.  You can download the handout given to attendees in order to learn this for yourself.  If you want to download the presentation please email me.  I would rather send you the file directly.  My email is in the sidebar to the right.

Related posts:

1. Agile for Business Analysts This past week I was fortunate enough to be a speaker at the...
2. New to agile? Don’t make it too hard! OK, so this isn’t my normal type of blog entry.  I don’t...
3. I’ll be speaking in January at the Phoenix Scrum User Group I’m honored to be the featured speaker at the January 28, 2010 meeting...

See that burndown chart over there to the left?  It looks beautiful doesn’t it?  It is an actual burndown chart with no made up data.  It looks like this team is kicking butt and having a great sprint.  Unfortunately, the chart lies!  It turns out this team is actually in difficulty and in fact are unlikely to make their sprint commitment.  Are you confused yet?  I know when I do this exercise during agile courses the course attendees all look at me like I’m crazy.  I assure you, I am not crazy.  This team is in trouble, it just doesn’t show up in this chart!

The problem is hidden from view.  Notice the vertical axis has no units associated with it.  This is the problem!  It turns out this team is burning down task hours.  Of course they go down every day, and they even do it reasonably predictably.  However, there is NO correlation between task hours and the amount of completed users stories!!!  This is an important distinction which is often glossed over in agile training.  I like to say if you measure completed hours you will get completed hours, but that is no measure of completed stories or delivered value.  Instead you MUST measure completed user stories in order to be assured of delivering value.  From experience I can tell you the hours left unfinished on the burndown chart in the example are almost all testing hours (consider your own experience).  In other words the team pushed testing to the end of the iteration, which is more or less guaranteed to fail.  Most teams in this situation forget to account for rework hours once testing finds defects and the problems get worse.

On the other hand, the chart to the left of this paragraph not only looks nice, it really is nice!  Notice the vertical axis is now labeled with “Story Points.”  In other words the team has completed a significant number of story points and they look like they will finish their commitment based on the current trend.  In fact, this team might even finish early!  The only difference between these two charts is the legend on the left side.  I tricked you with the first one because I didn’t give units at all.  If I told you it was hours it may have led you toward the right answer a bit faster.  However, I wanted to point out how charts can be made to lie VERY easily.

In agile, you WILL get what you measure, so make sure you measure the right things.  One of the 3 Scrum artifacts is the burndown chart (the other two are the prioritized product backlog and the sprint backlog).  Make sure the burndown chart is a valid artifact by measuring completed story points – oh, and NO PARTIAL CREDIT.  Just because the coding is done does not mean half the story points are completed!!!  Otherwise you are no better off than measuring hours.  Measure success in order to achieve success.

Until next time work on Making Agile a Reality^® by measuring properly!  In particular be very suspicious of any metric which tends to look good all the time, yet the team doesn’t get the anticipated results.

Related posts:

1. Agile antipattern: Another burndown chart that lies! That burndown chart looks sweet doesn’t it?  The team finished the iteration...
2. Agile antipattern: Burndown “wall” Does your team have an iteration burndown chart (giving credit only for...
3. Agile antipattern: Taking on large stories Earlier this week I posted a blog entry “Agile antipattern: Burndown charts...

Here in the United States we will be celebrating the Thanksgiving holiday on Thursday, November 26.  If you are currently on an agile team you may want to consider giving thanks a bit earlier!  My thank you list would definitely include:

1. Thanks for the organization allowing us to be successful with an agile development framework.
2. Thanks for giving the team the support needed from all areas of the organization so value is delivered each release.
3. Thanks for giving us the training necessary to be successful with agile.
4. Thanks for daily standups lasting no more than 15 minutes and leaving us all feeling energized that we can meet our iteration commitments.
5. Thanks for iteration demos where the product owners, stakeholders, customer and users can all see what we have created and give us valuable feedback.
6. Thanks for iteration retrospectives where the team really comes together and improves by having an action plan for improvement in the next iteration.
7. Thanks for our Product Owner who always has a well groomed, ranked/prioritized product backlog ready for the team to use at each planning meeting.
8. Thanks for an understanding Scrum Master who uses servant leadership which leads us to success without micromanaging or using command and control to get us there.
9. Thanks for a great team that has all of the necessary skills for project success including developers, testers and others all working as part of a single entity and not having turf wars all the time.
10. Thanks for the team being disciplined enough to actually write the tests first for our Acceptance Test-Driven Development practice.
11. Thanks for iteration planning meetings taking 2 hours or less with the output being an achievable goal each iteration.
12. Thanks for Product Owners, stakeholders, customers and users who are willing to interact with us on a regular basis to help us create great products.
13. Thanks for a team dedicated to meeting their commitments by getting all stories completed and really do it iteration after iteration.
14. Thanks for a burn-down chart that goes top-left to bottom-right and an accepted story chart which goes bottom-left to top-right without large staggered steps in either.
15. Thanks for managers, directors, vice-presidents and others in the chain of command who pay attention to macro metrics rather than micro metrics.

Oh, you don’t have all those things to be thankful for?  Sorry, maybe after Thanksgiving it is time to take a look at how your team is really doing with agile.

Until next time I’ll be Making Agile a Reality^® for my clients by helping them be thankful for everything on this list and many, many more!

Related posts:

1. New to agile? Don’t settle for mediocrity James Shore recently changed the entire focus of his company. This blog...
2. Agile antipattern: Comparing velocity between teams I recently saw an excellent blog post about iteration velocity.  Good reading...
3. Agile antipattern: Another burndown chart that lies! That burndown chart looks sweet doesn’t it?  The team finished the iteration...