Guild Blogs

Jeffrey Phillips wrote a nice post on Accountable for production not attendance. In it he argues that most knowledge workers should be treated like virtual workers – they should be held accountable for their production, not their attendance. The implication is that the results of the work is far more important than when or where they work. This is something I have given a great deal of thought to and agree with in principle. However, the focus here is on the individual. What if the individual works on a team?

Teams and times
Generally I find there is a happy medium when the team is allowed some flexibility in the individual schedules while maintaining some amount of schedule overlap so that there is a guaranteed time when everyone one the team is present. In my experience this is typically 10am – 3pm. For highly interdependent work I have seen team members on healthy teams adjust their individual schedules to overlap significantly so as to not impede individual tasks purely because of individual schedule preferences.

Teams and locations
Location seems less flexible to me. Certainly technology exists to allow teams to access all the resources they may need from far flung locations, but sometimes you need more that access to just electrons. Just ask someone who needed a flaky server rebooted and couldn’t get in contact with someone who could actually flip the power switch. Admittedly access to physical devices varies by team. My current teams deal with lots of hardware add-ons and regularly visit “the lab” to ensure the product is working as expected. Whereas in my previous position the entire team could have been airlifted to Fiji and it wouldn’t have mattered much (other than their tans).

Teams need to work together
Now teams could be distributed or virtual, but I believe that teams work best co-located and face to face. The team’s output is still of primary importance, but because they are working together the where and the when become important as well. It is harder to work together if part of your team is either at a different location or a different shift or both. And if it is harder to work together the output suffers and the results are what really count.

I attended AONW last year and had a fabulous time. It was great to reconnect with some of the local practitioners and have some really interesting conversations and be introduced to new idea. If you can make it I would highly recommend attending this year. Remember, attendance is limited to the first 100 people, so sign up soon! Look me up and I'll buy you a frosty beverage of your choice.

Here is a flyer for your office

I mentioned in my No More Iterations post that we didn't really know how support requests were going to affect the overall system. As is often the case I didn't have to wait long to find out.

Within days of moving to the limited WIP approach we got a raft of support requests, several of which turned into "must fix now" types of issues. Since we had just switched, we absolutely didn't have a slot on the board (in fact we had 13 stories for a 6 slot WIP).

Since these urgent requests had to be completed "right now" we decided to go with an "expedited story" concept. An expedited story essentially trumps all other backlog and work in process (WIP) and jumps to the head of the line stomping willy-nilly all over the other in-flight stories.

Obviously we don't want to have a lot of expedited stories so we discussed having a special slot just for expedited stories that would remain empty most of the time, but would also restrict the amount of thrashing the team would experience. However, based on my experience urgent requests tend to come in waves, and telling the business that our process doesn't allow us to help more that one customer at a time is professional suicide. What we are doing is examining all the urgent requests to see if they are truly urgent, or if they could wait a few days. If they can wait we put them on the backlog and process them normally.

To help us understand what is going on over time we are going to track the number of expedited vs. normal stories as well as doing some root cause analysis so we can prevent as many expedited stories as possible in the future.

Travis has a great post on why It's Not OK To Skip The Standup.

I've decided to try out this twitter thing. Follow me.

One of my staff (Aaron) found this great post from David Bock called the 7 Question Project Health Check.

The only thing I'd add is start working on this today!

If you want to know why, start adding up the cost of not doing it. How long will it take you to recreate your build server if it dies? I've seen everything from 1 hour to 3 days or more. Assuming $100/hr burden rate and a team size of 5 that can result in a $100 cost (1 person, 1 hour, nobody is blocked) to $12,000 (all 5 people are blocked for 3 days).

You can imagine how the costs can escalate if your source code is sitting on a file server somewhere or even worse on the programmers box.

Now go calculate your opportunity cost. At one company I worked at the finance department calculated the opportunity cost for the development department was $550 per hour per person! Show that number to the CEO and the head of IT and find out how quickly support requests get resolved.

One final note: if you are relying on your people working overtime to overcome these types of issues consider how you might act differently if you had to pay for that overtime out of your own pocket.
 

• Story size was difficult to estimate and kept crossing iteration boundaries.
• The programmers really didn't see the value of estimating stuff they weren't familiar with and in our planning poker session gave out lots of ? and 100 cards.
• We were spending to much time researching the time it would take to fix a bug that we weren't going to work on for several weeks.
  

After reading posts by David Anderson and Amit Rathore I started to examine why we were estimating, how much time we were spending at it, the psychic cost, and the results. The results were not encouraging.

Not surprisingly the reason we were estimating was to help the business prioritize stories. If stories X and Y both had the same value to the customer, but story X cost 10x more than story Y (where cost in my world = time) then the business had more information to base their priorities on.

The next question was how much time and effort we were putting into estimates. It turned out that we had two extremes. Either we spent 2-3 minutes estimating a story, or several hours researching a defect (another name for a type of story), but not much in-between.

The psychic cost seemed to be directly related to the time spent estimating. The quick estimating (which used planning poker) often had a background rumble if "I don't really know" which caused some resentment when the estimators had to eventually pick a number. For the more detailed research the task switching had a level of frustration built in, but by far the frustration was that once the detailed estimate was created the work itself was almost complete. Instead they had to task switch back to the planned tasks resulting in more time wasted.

Our results weren't spectacular. The stories seemed to get either 100 points or less than 5. The new unknown work was 100 and the previously researched defects were less than 5. I'm not a big believer in tracking actuals, but it was clear that each 100 point story was not taking about the same amount of time. The defects were typically completed in about the time estimated.

Given this information one could easily conclude that we just needed to do more research so that the new features could be estimated more accurately. But wait a minute, why are we doing estimates in the first place? Are we estimating to create an accurate budget, or to price a bid? In our case we are not. This isn't to say that some people need to do these things, but we don't. Rather we are estimating to provide prioritization information.

I started to wonder if we were trying to be more precise in our estimates than we needed. Enter the concept of t-shirt sizing. Each story could be estimated as a small, medium or large story.

After a few discussion we determined that our smallest stories (mostly defects) really took no less than 3 days from start to finish. So I rounded up to a week and called that a "Small" story. The next boundary to identify was the "Large" story. We decided to call anything that takes more than 1 month a large story. So anything that was between 1 week and 1 month was a "Medium".

I chose the week and month boundaries because they are easy to communicate and part of our everyday language. Remember that the estimates are going to be used by non-technical managers for prioritizing so units like ideal days and gummi bears just get in the way.

Because we now have 3 simple possible outputs from the estimating process I didn't want to spend lots of time coming up with small, medium or large. Accordingly I set the upper limit on research time to 30 seconds. Why 30 seconds? Because for the most part 30 seconds is enough time to develop a gut feel and a gut feel is close enough for the intended use.

I posted a bit of research I did for some externally hosted tools previously. Here is a quick rundown of some self-hosted tools.

• VersionOne Community (free - I've used it and I like it, 5 user limit)
• XPlanner (free OSS, seems good, hasn't been updated since 2006)
• RedMine (free OSS, not really agile, more of an issue tracker like Jira)
• ScrumWorks Basic (free, pro version has more features)
• AgileTrack (new to me, seems to cover the bases - didn't see any burn down charts)
• VersionOne Team (like V1 Community except you get support)
• Project Cards (new to me, seems to cover the bases - didn't see any burn down charts. The UI looks a little MS Access)
• OnTime Express (not agile out of the box, but can be customized to support, similar to JIRA+Confluence in that underneath it is an issue tracker and a wiki)
• ExtremePlanner (nice simple system)
• Trichord (more lean than agile, kanban + burndown - interesting)
• OnTime Pro (more features than OnTime Express)
• TargetProcess On-site (new to me, seems similar to V1 and Rally)
• Jira Enterprise (an issue tracking system, but combined with GreenHopper can be very agile)
• VersionOne Enterprise (unlimited users)
• ScrumWorks Pro (more features than Basic)

There are several free options here 2 commercial and 2 OSS. If I only needed 5 users I'd pick V1 otherwise I'd go with XPlanner. There seems to be a sweet spot around $2000. In this range I'd pick either Trichord or ExtremePlanner.

I can't really add anything to Geoff's post. Go read it and apply it.

Update: See the list of self hosted agile PM tools

I've been researching agile PM tools to decide if we want to continue using our existing tool, switch to another or go 100% manual.

There are a few vendors that provide a hosted service:

• Rally Community (free, but limited to 5 users, a single project and minimal charting)
• BaseCamp (not really agile, but widely used)
• VersionOne Team (nice system I've used before and like. The Team version is limited to 5 users)
• Acunote (new to me, seems very complete)
• Jira/Confluence Enterprise (an issue tracking system, but combined with GreenHopper can be very agile)
• ExtremePlanner Live (nice simple system)
• TargetProcess On-demand (new to me, seems similar to V1 and Rally)
• VersionOne Enterprise (unlimited users)
• OnTime Pro (not agile out of the box, but can be customized to support, similar to JIRA+Confluence in that underneath it is an issue tracker and a wiki)
• Rally Enterprise (unlimited users & projects)
• Mingle (seems to cover the bases - agile tracking + wiki, but very expensive)
  
• Wrike (new to me, seems similar to Acunote with lots of support for distributed teams)

There are 3 clear groupings for me. Free or nearly free which includes Rally Community, BaseCamp and VersionOne Team. The middle group ranges from $2,400-$3,200. Starting with Extreme Planner Live you are looking at from $7,500-$17,000.

If I had a very small team I would look at Rally Community or V1 Team. For a larger teams I think AcuNote hits the sweet spot. If I had a distributed team Wrike would be worth checking out.

This is not to say that I am refuting our move away from iterations etc. into the "Post Agile" world, rather I am releasing the results of work I did leading up to that decision.