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.

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.
 

In my initial post No More Iterations I mentioned that estimating was a factor in the change we were making. Specifically:

• 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.

We've committed to iteration-less pull based software development starting on Monday for one of my teams. A number of factors led up to this decision, not to mention the vast amount of discussion I had with my project managers.

The factors:

• 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.
• I am looking for a good departmental metric for the rest of the company to see how development is doing and Velocity is always too abstract.
• 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.
• There was invisible work being performed.
• We had a tool (Rally) that wasn't really being used as intended.
• The scheduling process seemed overly complicated.
• We didn't have a great way to express the result of adding "one more thing" to the release.
• We are just about to get a true single backlog per product line.

What we are ending up with:

• A kanban board currently in the PM office, to be moved to the team space as soon as physical re-org is complete (~2 weeks). The kanban will have 4 columns: pending, blocked, in process and complete.
• A single department metric: throughput expressed as average days to complete a story.
• Limited work in process (WIP). We are starting with a maximum of 5 stories WIP and will experiment from there.
• Differentiating stories from support requests.

Our current kanban board.

What we're not sure of yet (that we know of):

• How many support requests in process (RIP) makes sense? 1? 5? 10?
• How the blocked state will get (mis)used.
• If we need to track the amount of time a story spends in the blocked state.

The kind of output I'd like to track.

Casie is one of my project managers who has a blog but doesn't post much. I'm hoping this change will cause her to comment more often about what she is thinking and experiencing as we move through the process.

References:

Lean Software

• Amit Rathore: Estimation considered harmful
• Amit Rathore: If estimation is harmful… then, what’s not?
• Peter Seibel: Software estimation considered harmful?
• The Poppendiecks: Managing the Pipeline
• David Anderson: Stop Estimating
• David Anderson: Agile Estimating
• Corey Ladas: Time-boxed iteration: an idea whose time has come and gone
• Alistair Cockburn: Are iterations hazardous to your project?

Estimation

• Mike Griffiths: Agile Estimation – Upfront Estimates

As my team becomes more responsive to the business needs placed upon it I realize that I haven't clearly communicated the guidelines I'd like to see in place and why I believe the guidelines are helpful. Here is a recent clarification I sent out (modified for a more general audience).

The Question: How do we know what to work on and what not to work on?

This question has come up a number of times in every project team I've ever worked on or with. It is a good question and one that deserves an answer.

Short answer:
Only items on the backlog should be worked on.

Follow-up question
#1: Who gets to add things to the backlog?

Answer: The
Product Owners have the right (and responsibility) to add or remove things from the backlog. They take input from many people outside the company, inside the company and inside the department.

Please, please, please do not interpret this as reason to not tell the Product Owner your great ideas or lobby them to raise or lower the priorities of certain backlog items. You have a unique insight to the products we create and we need your input.

The primary reason behind this approach is that we want to make it crystal clear what we are working on. There is a concept in astrophysics called "Dark Matter" which essentially is stuff we can't see but affects what is going on. Dark Matter in software development is all the little things that we do, but don't track that end up making the project late. The dark matter isn't necessarily "bad", we just don't see it until the project is late and someone asks why. The backlog and support queue are ways to "see" more of the dark matter.

Follow-up question #2:
What about issues that come from support?

Answer: Support
issues are just another form of work that may have a higher priority than what you are currently working on.

Note that all support issues are not created equal. If it is not obvious check with the Product Owner and the support manager to understand the urgency of the situation and the requested turn around time. If it is possible try to finish the task you are working on so you don't have to try and pick it up again in the middle later.

Currently we track these issues in the support queue and that is fine. Just be sure to assign the issue to yourself if you are working it. Your project manager may choose to replicate this information in the project tracking tool so that we have a consolidated place to review this data.

Follow-up question #3:
What happens if <insert executive here> asks me to work on something else?

Answer: It depends :-) You will get requests from people from time to time that aren't on the backlog. If you know the answer off the top of your head feel free to answer. Generally though please redirect them to the Product Owner (politely of course). Once again, the idea here is to make the work visible and the Product Owner needs to be able to help balance the workload against other existing priorities.

Follow-up question #4:
How do we schedule things like unit tests, JVM upgrades, product evaluations, build servers, and meetings?

Answer: These types of things are definitely required to build our software, but they are not typically backlog items into themselves.

These things tend to group in 3 categories: big technical changes, non-story related work and tasks.

Big Technical Changes tend to be things that affect the system horizontally, i.e. you have to touch almost the whole system in some way. Examples of this are significant runtime or database upgrades, new persistence mechanisms, new security models, etc.

Big Technical Changes in our future are things like migrating to Subversion, upgrading Sybase ASA to version 10, upgrading PowerBuilder to version 11.2, and migrating to Eclipse 3.3.

These happened infrequently (2-3 times/year), but have a potentially significant impact on the project schedule. Because of the possible impact Big Technical Changes need to be coordinated with the Product Owner in the form of a Technical Backlog which gets scheduled in the same way as any other backlog item.

Non-story Related Work tends to be things that help us get work done better/faster but is smaller in scope than big technical changes. Often these kinds of changes don't directly affect the code we ship to our customers.

Examples of this are improving the build server, upgrading Bugzilla and testing framework improvements.

These happen about once per month and can be a separate backlog if big enough or can be attached to a story as a task.

Tasks are the technical things we need to do in order to complete the backlog. The Product Owner owns the backlog, but the task list is owned by programmers, testers and writers. The Product Owner doesn't muck with the tasks and nobody else mucks with the backlog.

Tasks may directly or indirectly affect the code we ship. For the most part I expect everyone has a basic handle on what tasks are.

Example Backlog:

As a Manager I want to Print the Category Setups so I can refer to them when I am not at the computer.

Tasks I'd envision:

1. Research reporting tools to replace existing one
2. Create sample report in BIRT
3. Create sample report in JasperReports
4. Add button to print report on Category screen
5. Create final report in selected tool
6. Create test cases
7. Test case #1
8. Test case #2
9. Test case #3
10. Update documentation & help files

Researching the tools are tasks in the first report that is worked on. Also note that tasks 2 & 3 probably didn't exist until #1 was mostly complete, similarly tasks 7-9 and #6.

You can also see some of the elements of "Done" that we defined in the past.

There aren't any meetings, unit testing, refactoring, compiling, designing or breathing in the task list because those are just part of the everyday life of creating software.

Summary

Only work on tasks related to backlog items in the current iteration and urgent support issues. The Product Owner manages the backlog, everyone else manages the task list.

Thoughts?

I had never read "The Deadline" by DeMarco, but it turned up on my boss' desk one day and I borrowed it.
I thought it was an enjoyable read and only violently disagreed with his attempt to say that if we would just do more up-front design everything would be better (High-performance projects spend proportionately far more of their time in design).

Four Essentials of Good Management: (p.28)
Safety and Change (p.35)
Negative Reinforcement (p.46)
The Manager’s Essential Body Parts (p.59)
Battle Command As a Metaphor for Management (p.69)
Interviews and Hiring (p.69)
Productivity Improvement (p.83)
Risk Management (p.83)
Playing Defense (p.93-94)
Modeling and Simulation of the Development Process (p.115)
Pathological Politics (p.131-132)
Metrics (p.149-150)
Process and Process Improvement (p.161-162)
Changing the Way Work Gets Done (p.179-180)
The Effects of Pressure (p.199)
The Angry Manager (p. 209-210)
Ambigous Specification (p. 216)
Conflict (p. 225)
Roll of the Catalyst (p. 238)
Human Error (p.246)
Staff Level (p. 260)
Project Sociology (p. 275)
Pathological Politics (Again) (p. 288)
Lean and Mean (p. 299)
Radical Common Sense (p. 302)

Tom DeMarco, The Deadline (New York: Dorset House Publishing, 1997), http://www.dorsethouse.com/books/dl.html. Copyright (c) 1997 by Tom DeMarco. All rights reserved.

the spurious pundit has a really good post on how hard it is for manager types to do a good job of telling people what they want done.

Snippets:

First off, there's the mechanics of how to do it. What tools does he need? You know that there's a hammer and nails in the back of the supply closet. He doesn't, and it's fair of him to assume that you wouldn't have asked him to do something he didn't have the tools for. He looks around his desk, and he's got a stapler and a tape dispenser.

There is also another way this can go wrong, particularly with a certain breed of eager young programmer. You find that he's gone down this path when your boss comes by the next week to ask about this purchase order for a nail gun. So you talk to your guy and discover that he's spent the last week Googling, reading reference works, and posting to news groups. He's learned that you hang pictures on a nail driven into the wall, and that the right tool for driving nails into walls is a high-end, pneumatic nail gun. If you're lucky, you can point out that there's a difference between picture-hanging nails and structural nails, and that a small, lightweight hammer like you have in the supply closet is really the right tool for the job. If you're not lucky, you have a fight on your hands...

So now we get into higher-level design issues. Where should the picture go? At what height should it be hung? He has no way of judging any of this, and again, it's not as obvious as you think.

In my previous post we had some good discussion regarding rule # 1:

The best product managers follow the Pragmatic Marketing maxim: Your opinion, while interesting, is irrelevant. Always use market facts to decide the best course of action.

The general sense of the responses was that this rule doesn't allow for innovation. So I tracked down Steve Johnson who was the source of the rules for comments. Here is his response (with permission):

Amazing that "use market facts" is somehow being misinterpreted as "Ask people what they want." The internet solved a huge, documented problem; people didn't ask for it by name but they had long asked for a solution to the problem of connecting businesses and consumers with a single connection point.

True, I don't rely too heavily on product management encouraging innovation; more often I need them to curb unfocused featureitis disguised as innovation.

Steve has a good point here. In the past I've noticed a similar disconnect between the desire to have "innovative" products and a willingness to collect data. Somehow people get to the point where what they believe is more important. This doesn't mean you have to ask people what they like, you can observe what they use, which is probably more accurate anyway.

Amazon, Ebay, Google and many others try new things all the time without lots of fanfare to see if they get used (i.e. market facts) to see if an idea is worthwhile.

Malcolm Gladwell in his Pop!Tech 2004 presentation (via ITConversations) talked about the Aeron chair and how people hated it at first, but gradually it became the best selling office chair of all time. His point was that people don't really know what they want. A common theme in software circles (the users don't really know what they need) there is some truth to it. But users (the market) will tell you if it is useful and you can save yourself a lot of time and effort if you collect some market facts.

Reference: A copyrighted story from SoftwareCEO written by Bob Weinstein Software product management: If you can't define it, you're doing a bad job at it and published by Pragmatic Marketing on productmarketing.com

From a copyrighted story at SoftwareCEO written by Bob Weinstein Software product management: If you can't define it, you're doing a bad job at it

Product managers' rule #1: The best product managers follow the Pragmatic Marketing maxim: Your opinion, while interesting, is irrelevant. Always use market facts to decide the best course of action.

Product managers' rule #2: Product management is a not a "natural" fit for everyone. A good product manager has a technical background with business savvy. Software engineers and programmers, for example, can make a smooth transition to product management because they're starting off with a strong technical background. But technical smarts alone won't cut it.

Product managers' rule #3: In "Crossing the Chasm," Geoff Moore says that product management is a senior, business-oriented role and typically fails because we staff it with junior, technically-oriented people.

Product managers' rule #4: Credibility comes from being able to manage the business of the product. Otherwise, product management gets relegated to a technical support role.

Product managers' rule #5: Product management is about delivering what the market needs. Good product managers spend more time in front of customers and potential customers; they spend less time on sales calls and in their corporate offices.

Product managers' rule #6: Product management is not necessarily about delivering what the customer asks for. The best products solve the customer's problems and no more. A product manager has to observe and understand what the customer needs in order to solve the problem, rather than building the features the customer requests. "The old guys at Home Depot do this well," says Johnson. "They don't ask you what you want to buy; they ask you to describe your project so that they can tell what you need to buy."

Product managers' rule #7: Mature companies value product management and enjoy shorter time to market. According to a survey Pragmatic Marketing conducted with softwareminds, companies that consider product-management business critical cut their time to market in half. This results from more focus on the product and less last-minute reaction to sales demands du jour.

Product managers' rule #8: Product management usually fails when organized in the development or engineering team. Technical managers do not consider product management a value-add to their teams and relegate them to project management and scheduling.

Product managers' rule #9: Similarly, product management fails in sales departments. Naturally, sales management considers product management a sales resource and allocates 110 percent of its time for supporting salespeople.

Product managers' rule #10: It seems counterintuitive, but product managers who spend a lot of time supporting salespeople find that they are not valued by their companies. Invariably, the product managers who have been laid off are the ones who are closer to sales.

In many organization I've encountered there is this artificial distinction between the new development group and the maintenance programming group. Why on God's green earth would you want to do such a thing?

Every time the topic comes up I point out that there is only "maintenance" since once you have the first line of code checked in you are now maintaining the system. Probably the only difference between "new development" and "maintenance development" is whether the system is being used in production or not!

A better approach in my opinion is to view all your systems as the software ecosystem for your organization. You now have the common problem of limited resources to change/add features to the ecosystem. The features may or may not be added to systems that already exist. Whether the system already exists is irrelevant to the decision to spend money on that feature.

Organizations that have adopted agile practices eventually notice that there is little or no difference between new functionality, enhancements and bug fixes. If there is a difference it is more a difference of granularity in that some bug fixes are very small while everything else tends to be larger.

The advantage of the ecosystem approach is that your development resources are more of a pool that you can draw from, the stigma of being on the maintenance team doesn't exist, and knowledge can be spread among the team.

Think about it, try it. You might like it.