James Shore

Email Troubles (Please Resend)

07 Jul 2008

James Shore/Blog

I returned from the long weekend to discover that my ISP, Comcast, is blocking all emails forwarded from Domain Discover, who hosts jamesshore.com. This means that any email you sent me went to the great bit bucket in the sky. (It probably explains the intermittent email failures I've been experiencing over the past month, too.)

So... if you have emailed me in the last month and didn't get a reply, please email me again. I've responded to all of the emails I have.

I apologize for the inconvenience, and I've taken steps to prevent this from happening again. Domain Discover now archives my email before forwarding it to Comcast, so I won't lose anything if this happens again.

(To top it all off, Domain Discover inadvertently turned off my domain name when they added archiving to my email forward. Sigh... it's fixed now.)

Update, 8 July 2008: Mark Casem of Comcast just called me to make sure my problem was resolved. Apparently, Comcast uses Google Alerts to follow up on blog posts like this one. Impressive. I've heard that Comcast has a reputation for poor customer service, but my experience has always been positive, and this was certainly above and beyond.

Comments

Book Piracy

03 Jul 2008

James Shore/Blog

I recently discovered that our book is available on a popular textbook torrent tracker. This isn't the first time I've seen it pop up on a pirate site; given the nature of digital files, it's both inevitable and unsurprising.

What amused me, though, was the hypocrisy displayed. The front page of the tracker says, "We're fighting the high price of textbooks." They actually might have a point, considering what textbooks go for. But we wrote our book for professionals, not a captive student audience, and it's priced accordingly. The cover price is a reasonable $40 and Amazon has it for $34.50. There's no price gouging here.^* If you're fighting the evils of price-gouging publishers, why is our book on your site?

(^*Yes, even at $40 we're more expensive than a paperback, but it's not price gouging. Computer books have very low sales compared to mass-market books and I'd bet they have higher production costs.)

Look, guys. You're taking something without paying for it. You're doing it because you don't want to pay, or because it's more convenient than paying. Current law calls that "stealing," the vernacular calls it "piracy." Whatever. I'm not going to lecture you--duplication of digital content is unstoppable and us content creators have to figure out other revenue streams. (Hey, hire me!) I lose more sleep over the RIAA's lobbyists and thugs than I do over lost sales. But please... don't pretend you have some high-minded aim here. You're pirates. You're not being noble, you're being cheap. Or lazy. Just admit it, already.

PS: I'm glad you like the book. 36 seeders and 257 downloads? That makes us the second-most popular by seed and seventh-most popular by download at the time I checked. Yay us!

PPS: To really show your appreciation, review the book for Slashdot.

Comments

Agile Release Planning Webinar Online

13 Jun 2008

James Shore/Blog

The Project Management View blog has put their recording of my Wednesday webinar, "Maximizing Value with Agile Release Planning," up on their site. I thought it turned out really well. If you were interested but couldn't attend for some reason, now's your chance.

Thanks to Chelsea Woodhead and Ryma Technologies for putting together such a well-organized session.

Comments

The Art of Agile Development: Reporting

11 Jun 2008

James Shore/Agile-Book

in 99 words

A vision statement, weekly product demos, release and iteration plans, and a burn-up chart are a normal byproduct of your work. Share them as a matter of course.

Other reports take extra time. They're technically waste, but may be necessary to help build trust in your team. Roadmap and status emails summarize your release plan and demos. Productivity, throughput, and defect reports help management understand your effectiveness. Time usage reports help explain your velocity.

Avoid reporting lines of code, numbers of stories, and velocity. They're misleading at best. Avoid sharing code quality metrics, too: they require expert interpretation.

Inside The Book

Reporting
Types of Reports
Progress Reports to Provide
- Vision statement
- Weekly demo
- Release and iteration plans
- Burn-up chart
Progress Reports to Consider
- Roadmap
- Status email
Management Reports to Consider
- Productivity
- Throughput
- Defects
- Time usage
Reports to Avoid
- Source lines of code (SLOC) and function points
- Number of stories
- Velocity
- Code quality
Questions
- What do you mean, "Progress reports are for stakeholder trust"? Shouldn't we also report when we need help with something?
- What if some of our stakeholders want to micromanage us?
- Isn't this just busywork? We have an informative workspace, stand-up meetings, and iteration demos. Stakeholders and managers can visit any time. Why do they need reports?
- What if programmers don't want to track their time for the time usage report? They say they have better things to do.
- Why should the project manager do all the grunt work for the reports? Shouldn't he delegate that work?
- Our organization measures employees individually based on the contents of certain reports. What do we do?
Results
Contraindications
Alternatives

Work In Progress

As my career has progressed, I've spent more and more time with senior software managers. One thing my younger self would have been surprised to learn is that executives aren't really out to get you. Instead, they're generally interested in seeing individuals grow and succeed.

At the same time, executives have a lot to keep track of. There's no way for them to have the same insight into your work that your team does. And yet the people doing the work--the ones in the know--are often uncomfortable sharing their opinions with senior managers. Information gets transmogrified, and sometimes whitewashed, on its way to the executives' ears.

So one of the common things I'm seeing in executives is an interest in software metrics. They want to know how their teams are performing. Not so they can punish and reward people, necessarily, but so they can know where to direct resources for improvement.

This is a challenge. For one thing, it's really hard to measure productivity. Martin Fowler has said it can't be done. I've said it can be, but the metric I proposed is very difficult to measure. I'm experimenting with an alternative that's easier to measure, but the jury's still out on how well it will work.

To make things even more challenging, some people say that measurements, no matter how accurate, risk dysfunction. In "Mad About Measurement," Tom DeMarco writes:

Encouraging people to work to the numbers is what the 1960s called Management By Objectives (or MBO). MBO had a brief history as the fad du jour through the early 1970s, and then largely disappeared from the popular business press, though unfortunately not from all our organizations. The problem was that MBO didn't work very well. Companies that tried it didn't prosper; most people who used the scheme were clearly aware of the growing dysfunction it caused.

I think you can see where I'm heading: directly toward my third Disquieting Thought About Software Metrics:

DT #3: Have we in the software industry through the use of our software metrics programs inadvertently rediscovered Management By Objectives?

I suspect we have. We've stumbled upon a bankrupt concept from the past, and tried to make it work without ever understanding why it didn't work before.

Tom DeMarco, "Mad About Measurement," Why Does Software Cost So Much? (Dorset House, 1995)

Robert Austin agrees. He's the author of Measuring and Managing Performance in Organizations, based on an economic model developed in his Ph.D. thesis. The book's a bit dry, but it makes a compelling case for the problems of measurement-based management.

[O]ften the best that can be [achieved] through measurement, even after job redesign, is partial supervision [that is, only some aspects of the work can be measured], which generates relatively weak improvements in value to the customer compared to [the alternatives]. In addition, partial supervision produces significant distortion of incentives. If motivation theorists are correct in their conclusions, distorted incentives obscure inclinations [a worker] may have toward doing the job right for internal reasons, like pride in his work. Worse, if targets are set badly, distortion may become significant enough to produce dysfunction.

Robert Austin, Measuring and Managing Performance in Organizations (Dorset House, 1996)

And, as Robert Austin mentions, there's the problems that arise from using extrinsic motivators rather than intrinsic motivators.

It's a pickle. Executives have a real need for good performance measurements. But there's compelling arguments that say good performance measurements don't exist... and even if they did, they could lead to dysfunction and decreased motivation.

A tough situation. I don't have any answers yet, and I'm not ready to give up.

Comments

Watch Out For These Common Problems

05 Jun 2008

James Shore/Blog

A client in Poland recently emailed me about his new branch office. They're applying agile development from day one. Here's my response:

Thanks for the update, P----. I'm glad things are working well.

Here's some things to keep an eye on as you go forward:

The team should be able to make and meet iteration/Sprint commitments almost every time. If they don't, it reflects planning problems or engineering problems.
Your QA/testing burden should not grow over time. If it does, it reflects engineering problems.
Bugs and incorrect features should be rare in iteration/Sprint demos. If you see them, it reflects communication problems or engineering problems.

These are the most common issues I see new teams struggle with.

Comments

The Art of Agile Development: Iteration Demo

04 Jun 2008

James Shore/Agile-Book

in 99 words

Produce working software every week, and demonstrate to stakeholders that you have done so.

Invite anyone who's interested to the demo. It should take about ten minutes. The product manager often conducts the session. Briefly describe the features scheduled, their value, and any unexpected changes. Build trust by being honest, not defensive, about changes.

At the end of each demo, ask your executive sponsor two questions: "Is our work to date satisfactory?" and "May we continue?"

Conduct demos at the same place and time each week. When schedule problems occur, a regular demo makes it easier to face reality.

Inside This Section

Iteration Demo
How to Conduct an Iteration Demo
Two Key Questions
Weekly Deployment is Essential
Questions
- What do we do if stakeholders keep interrupting and asking questions during the demo?
- What do we do if stakeholders keep nitpicking our choices?
- The stakeholders are excited by what they see and want to add a bunch of features. They're good ideas, but we don't have time for them--we need to move on to another part of the product. What should we do?
- We completely blew this iteration and don't have anything to show. What do we do?
Results
Contraindications
Alternatives

Commentary

One of the most common problems I'm seeing with agile teams these days is trouble making and meeting iteration commitments. In other words, these teams often have half-done stories at the end of each iteration. As a result, their iteration demo is often disappointing.

The causes of this failure can be complex and varied... actually, wait. That's baloney. I'm trying to be honest here, not sell you "everybody's right" pablum. It happens when you take the easy way out. That road looks easy and simple, but it's strewn with traps. (Call it Ackbar Way.)

Trap #1: The Ever-Increasing QA Burden

Many agile teams I know have adopted short iterations, daily stand-up meetings, and the planning game, but they haven't taken a serious approach to agile engineering. Their iterations look like mini-waterfalls. Programmers design and code, then hand the results off to QA for testing. (These teams struggle with requirements analysis, too, but that's a topic for another day.)

Context and transcript here

QA ends up with an ever-increasing test burden. Even if QA creates automated tests, those tests tend to be integration-style tests, which are slow and fragile (see video at right). They're a maintenance burden. More often, though, the testing is done manually, which is an even bigger burden.

Worse, this burden scales proportionally with the size of the software, and is repeated with every iteration. Before long, testers are running out of time to test the developers' work, bugs are spilling over into the next iteration, and the team's ability to plan reliability goes to hell in a rather uncomfortable handbasket.

End result: buggy iteration demos. Fix: prevent bugs using agile engineering techniques and involving customers rather than trying to test the bugs out.

Trap #2: Wishful Thinking

The other big cause of disappointing iteration demos is quite simple: teams sign up for more than they can do. They often blame this on poor estimation, but that's not really the problem. The real problem is that, for whatever reason--eagerness to please on the part of developers, or pressure on the part of customers and managers--the team ignores or inflates their velocity when planning the iteration.

Velocity is quite simple, of course. You take all of the stories from the previous iteration, set aside those that weren't "done done", and add up their estimates. That's your velocity, and you aren't allowed to include any stories that were partially done, untested, or otherwise unacceptable to your on-site customers. Those stories have to be ready to ship. (There's some nuances, but teams having trouble meeting commitments need to go with the straight-and-narrow approach.)

The "done done" requirement is quite strict and can lead to disappointing velocity numbers. So people fudge. Rather than calculating velocity from completed work, they estimate it with "capacity" by counting developer-hours and multiplying by an arbitrary percentage. Or they take partially-done stories and award themselves part of the story's estimate. This adds enough subjectivity to the mix that the team can now set their velocity to the number they wanted, while maintaining the illusion that it's based on real facts and calculations.

Part of the problem here is a macho desire to improve velocity, based on the misguided belief that higher velocity leads to higher productivity. (It's the other way around. Sorry.) Whatever the reason, making up a pleasant velocity figure does not change your ability to actually deliver software.

End result? When the iteration demo rolls around, the team hasn't finished everything. In fact, they don't even finish as much they were capable of finishing, because rather than getting half of the work all the way done, they get most of the work partway done. Very little is done done. This, of course, leads to a crappy velocity and increases the desire to make up a happier number.

The fix? It's the easiest thing in the world, and the hardest. Just stop making up your velocity. Calculate it based on what's "done done," and be cautious about increasing it. This may not yield a number you like. Actually, it probably won't yield a number you'll like. But you will be more productive and you will be able to make commitments. You'll probably spend less time fighting fires, too, and you'll finally be able to start tackling your underlying productivity problems rather than playing games with numbers and staring uncomfortably at your feet during your iteration demos.

Comments

Anybody in Toronto This Weekend?

27 May 2008

James Shore/Blog

I'm going to be in Toronto, with some time free, this Friday and Saturday (May 30th & 31st). Is anybody interested in getting together for beer and/or food? I'm available Friday evening and Saturday morning with no other plans, and I can drive anywhere in the Toronto area.

If you're interested, email me and we'll make some plans.

Comments

Secrets of Agile Success--Summary

27 May 2008

James Shore/Blog

In case you don't feel like listening to all ninety minutes of my Secrets of Agile Success presentation, Mike Polen has a nice summary of the talk on his blog. He also links some of the papers I mentioned. Thanks, Mike!

I do want to make one correction: I wasn't trying to beat up on Scrum. I state my position on Scrum better in my post, "Should We Adopt Scrum or XP?"

Comments

The Art of Agile Development: Coding Standards

21 May 2008

James Shore/Agile-Book

in 99 words

In team software development, we create a collective work that is greater than any individual could create on his own. Arguing about style gets in the way.

When creating a coding standard, your most important achievement will be learning how to disagree constructively. To succeed, create the minimal set of standards you can live with. Focus on consistency and consensus over perfection. Remember that few decisions are irrevocable in agile development.

Assume your colleagues are professional and well-meaning. If they deviate from the standard, discuss reasons rather than placing blame. No coding standard can substitute for professional judgement.

as haiku

Fists fly, dust billows--
Tomatoes die, peas cry, as
we choose rose's hue.

Inside This Section

Coding Standards
Beyond Formatting
How to Create a Coding Standard
Dealing with Disagreement
Adhering to the Standard
Questions
- We have legacy code that doesn't fit our standard. Should we fix it?
Results
Contraindications
Alternatives

Rant

Sometimes it's hard to figure out what to write in these weekly updates. Coding standards--what can I say about coding standards that we didn't already say in the book? Oh, I know. In the immortal words of William Shatner...

People get really worked up over coding standards. I mean really worked up. But they're actually not that important. The choices are more style than substance. I like exceptions; you like error codes. I like camelCase; you like words_with_underscores. It's programmers' equivalent of the fashion industry: different styles evoke disgust; the thought of having to actually use that style generates outright loathing.

If you're one of those people, it's time to get over yourself. It's good to be consistent, sure. But it doesn't matter which consistent you choose. Just pick one already. And if you're constantly arguing about coding standards, here's a sure-fire way to win the arguments: give in.

That's right--give in. Either you're right, and the other guy's standard will lead to pain and suffering, in which case you'll be vindicated, everybody will agree to follow your coding standard, and you'll get to say "I told you so"...

Or it won't really matter, nothing bad will happen, in which case you've won because people will stop thinking of you as that jerk who always argues about coding standards.

Either way, it's a net positive.

Comments

August 7th at Agile 2008: Agile Planning in Action

21 May 2008

James Shore/Calendar

I'm presenting one of my favorite sessions at Agile 2008 this year. It's one of my favorites because it's highly interactive, with very little lecture, and yet it always succeeds at getting right to the heart of Agile planning.

Read More...

Comments