Tuesday, July 28, 2009

Scope Budgeting

A while back, I attended the talk Scope Is Not A Dirty Word given by business analyst Angela Ashworth and delivery manager Mark Coster from ThoughtWorks.

The centre of the discussion was "scope budgeting," which basically boils down to having the developer work with the user to manage scope within an iteration.

In many flavours of agile, the user writes a story, the developer estimates it, and then it goes into the backlog. It's only when the story gets pulled from the backlog and put into an iteration that the user and developer fully flesh out the implementation details. But at that point, they may find they have scope creep—that the implementation will take longer than the original estimate.

At this point, the developer has two options:

  1. Implement the story, even though it will take longer than originally estimated, pushing out the other stories, potentially dropping some off the end of the release.
  2. Talk to the user more. Let him know that the estimate has changed and why. See if together they can come up with a way to reduce the scope of the story to get it back down to the estimate.

Option 2 is scope budgeting.

I have to admit that I was actually very disappointed to hear this from ThoughtWorks.

I have never been part of an agile project, I've only read about it. My agile daydreams included how nice it would be to have the user prioritise stories from the beginning, understanding that not everything would necessarily make it into a release, thus avoiding one of the activities I've come to think of as churn—the developer and user constantly having to re-prioritise and re-think functionality as scope creep happens in order to try to fit everything in or to figure out what is best to leave out.

I suppose I can understand why scope budgeting is a good idea. And I can understand that having all the stories in an unchanging ordered list from the beginning of the project isn't really very agile at all.

But it's still tough to see my daydreams shattered.

The up side is that it highlights that both the developer and the user are in the same boat, working together toward the same goal. In waterfall, each is under pressure to "be perfect." The user should write down every single implementation detail at the beginning of the project and the developer should estimate every one of them down to the minute. Later, when they discover that a requirement was missed, the developer blames the user for blowing the project. When they discover that an estimate wasn't quite right, the user blames the developer for blowing the project.

At least with agile and scope budgeting, the focus changes from blaming to recognising that neither the user nor the developer can make a perfect plan at the beginning of the project—that they need to work together throughout to figure out how to create the most value.

Monday, July 27, 2009

My Favorite Technical Books

It's been half a year since I moved from Chicago to London, and there is still an awful lot of stuff that isn't unpacked and is sitting in boxes, including many, many books.

But last weekend, the DH and I added yet another bookcase to the flat, and it's time to take care of the box sitting at my feet, labeled "Amy's favorite computer books."

But wait, I hear you say, if those are your favorite computer books, how can they possibly still be packed away in a box? Don't you need them at your desk every day?

Not so much anymore. A few years ago, I bought a subscription to Safari Books Online, which I can't say enough good things about. Yes, it can be expensive, but if you can scrape together the cash and you love technical books, it's great. Almost all of the books in my box are on there, so I don't need them at my desk.

The other aspect of having these books at my desk was that they were available for my teammates to easily grab and use. But now that I'm in London and those teammates are in Chicago, that doesn't happen anymore.

So, my favorite books have been sitting in their box until now. Now, I have a bookcase with glass doors available, so they won't get dusty. Here they come out of the box:

Head First Design Patterns by Freeman & Freeman I can't say enough good things about this book. It was the book that made the light go on for me for understanding what design patterns are and why they are useful. I own two copies—one was for work and one for home—plus the poster.

Working Effectively with Legacy Code by Michael Feathers For when you have to deal with ugly code, old code, code written by someone else long gone from your company, scary code, code without unit tests, or code you wrote last year and now hate.

Refactoring to Patterns by Joshua Kerievsky A bridge between patterns and refactoring.

Software Estimation: Demystifying the Black Art by Steve McConnell Sometimes I curse that I read this, because it made my BDUF estimates more accurate. Don't worry, there's lots of other good stuff in there, though.

Patterns of Enterprise Application Architecture by Martin Fowler This was the most-borrowed book in my library before I moved.

Pro C# 2008 and the .NET 3.5 Platform by Andrew Troelsen When I can't remember how something .NET 3.5 works, and I have trouble finding it online, this is where I end up.

VB & VBA In a Nutshell by Paul Lomax Because unfortunately, sometimes VBA still happens.

There are two more that I need to mention, even though they aren't in the box. The first, I have on CD, and the second I used to borrow from a work-mate until I got Safari books:

Design Patterns: Elements of Reusable Object-Oriented Software by Gamma, Helm, Johnson and Vlissides

Refactoring: Improving the Design of Existing Code by Martin Fowler

But wait? Where is The Mythical Man-Month by Fred Brooks? Good question. Darn thing is too skinny. It's always getting itself lost.

Sunday, July 26, 2009

Programmer.Grrl: The Prequel

As I mentioned before, back in high school, I was pre-med. The interesting thing is, when I was about 15, I actually did take a programming class and really enjoyed it. It was BASIC on Apple IIe computers. I remember one of the projects being to code a dice game. What could be more fun that that? Not just playing a computer game—but creating one?

It didn't feel like school, it felt like play. And because it felt like play, and because I didn't know that programming was a real profession, when it came time to sign up for the next semester of classes, I decided I didn't have space in my schedule for Programming II. I needed to take more biology or chemistry or some such thing.

The problem was, where and when I grew up, in a small town out in the country and before the Internet, I didn't have any concept that what I'd done in the programming class was at all useful. I didn't make any connection between it and the software my family bought for our own PC clone—things like WordPerfect and Lotus 1-2-3.

I don't know that it's true, but I hope so, that the Internet has opened childrens' horizons, so that when they think about what they want to be when they grow up, they understand there is more available than the professions they see in their everyday lives. Because when I think about that programming class I took when I was 15, I always wonder what a better programmer I might be if I'd kept with it from way back then.

It also makes me think more about how people end up as programmers in general. One of the original joys of programming when I was 15 was that I was making something. Most of my life, especially my school life, didn't produce anything remotely tangible or useful. It was about completing assignments or studying for tests, where once the assignment was done or the test taken, it was over, and the graded paper or test wasn't useful in any way.

But programming was different. You could tinker around and write some code and have something useful when you were done. Making something—something that other people might even really like—it's a rush. I'm sure there are other programmers out there who got interested in programming because of that. And for us, that's one of the frustrations with Big Design Up Front or with other processes where it's difficult to link end-user value back to our own work. Even if the process works for the organization, it can be tough for the individual.

Monday, July 20, 2009

Companies are Addicted to Profit Like Smokers are Addicted to Nicotine?

What I believe and what I'm discussing are two very different things. I absolutely can't agree more with pretty much everything Jim says in Define success....

My worry is that if an organization views its projects as successful, the argument that the success isn't sustainable may not be compelling. If so far, using its current methods, the organization has been making money, and as far as its managers can see, will continue to do so in the near future, how do you convince those managers that it needs to change?

It's even more difficult than convincing a smoker that smoking will kill him eventually, and that he should stop—at least in a logical sense. An organization isn't an individual, whose best interests are intrinsically aligned with the longevity of his body. An organization is a collection of individuals, who can leave at nearly any time. If the organization's methods aren't sustainable—if it won't make it through the next 50 years—how many employees really care, as long as they are currently able to cash their paychecks?

It reminds me of Alan Greenspan's testimony about the economic meltdown: "Those of us who have looked to the self-interest of lending institutions to protect shareholder's equity—myself especially—are in a state of shocked disbelief."

Yes, it's a shocker. It turns out that not everyone in an organization cares about its longevity, as long as they get their cash and escape before it implodes.

But let's assume better of employees of software companies, especially since most I've encountered really do seem to care a lot more than that.

It's still hard to convince people to change when the current model is "succeeding."

In organizations where meeting yearly financial targets takes higher priority than continuous improvement, the continuous-improvement conversation can end up working like this variation of being too busy sawing to sharpen the blade:

Lumberjack: Say boss, this blade is getting dull. It's getting slower for me to cut down the trees. I don't think we're going to make our quota.

Supervisor: You have a point. How long do you think it will take for you to sharpen the blade?

Lumberjack: I'm not sure. Since I've been working here, we've never sharpened the blades, so it's difficult to estimate how long it would take, because I'm out of practice. Plus, the blades are pretty dull, so it probably would take longer than usual anyway.

Supervisor: Hmmm. I'm not sure we'll be able to make our quota if we don't know how long it will take. We can't risk that. At our current rate of cutting, we can still make the quota if we hire in a few contractor lumberjacks. We'll do that.

It's not necessarily that the members of the organization don't want to improve—they may just think they don't have time given their current constraints.

And as far as the greater organization is concerned, they still made their quota. As far as it's concerned, everything is hunky-dory.

So, I'm back to the question. If the organization thinks the project was a success, but some people do not—some people think that success will be unsustainable in the long run—how do those people convince the rest of the organization that change is needed now?

Sunday, July 19, 2009

What If Your Unsuccessful Project Wasn't?

In Large-Scale Project Doesn't Equal Large-Scale Development, Jim Fiorato concludes that "The concept of parallelizing development with a large team to deliver a large amount of code for a large project all at once, is in my opinion, well... broke."

The only successful large projects I've been a part of have consisted of small development releases.


With the "large scale development" mind set, the odds are stacked against you. You'll find that you've fallen short on what you've envisioned, fallen short on your timeline, and probably done some irreparable damage to your talented team.

My concern is, so what? Just because a project fell short of what was envisioned, blew the timeline, or damaged the team, does that mean it wasn't successful?

Did the software release? Did customers pay for it? Is the organization still in business?

And if so, do you think the organization viewed the project as a success or a failure?

Saturday, July 04, 2009

FireFox 3.5: How To Bring Back "Close Last Tab"

First, in about:config, set browser.tabs.closeWindowWithLastTab to false.

Then, add the following to userChrome.css (via comment on Veera Sundar's blog):

    > .tabbrowser-tab > .tab-close-button 
    display: -moz-box !important;
    > .tabbrowser-tab[selected="true"] > .tab-close-button 
    display: -moz-box !important;