It's second nature to the experienced program managers I work with to break projects into milestones, so the idea of breaking a project into sprints seems easy to adopt. According to what we've read, sprints are supposed to be a short (2-4 week) cycle of work kicked off when the team agrees on a list of tasks to be attempted and finished off with a review (usually a demo) of what's been completed.

We've been used to determining the milestone schedule according to the size of the tasks on our list, though. A related set of large, complex tasks should require a longer time frame than a single simpler task, right? Makes sense. Scrum says you ought to be able to break any task down into component tasks that would fit into a sprint, but why force different size tasks into an arbitrary schedule? Why try to demo something that's only half done? Is there any reason we couldn't have a sprint of 2 weeks followed by one of 4 and then one of 8 for a really big task?

I've heard a few reasons that sound credible and that we plan to test.

1. Accountability - Have you ever seen a feature stay at 90% complete for weeks with no apparent progress? Have you ever seen developers procrastinate on work with a long deadline? Rapid-fire deadlines force people to get things done efficiently for fear of looking bad at the demo.
   
2. Course corrections - There's always some gap between what product manager asks for and what the engineers deliver. Frequent reviews minimize that gap by bringing the two parties together regularly even when features aren't done. It's easier to make changes before the feature is done, tested and documented. And without the discipline of regular check-ins it would be easy to wait until back-tracking feels like more work than it's worth.
   
3. Rhythm - I've heard people experienced in Scrum say that a regular schedule puts them into a productive rhythm. It's like exercise, I gather - once you get to doing it regularly you begin to expect it. It's self-reinforcing. Developers look forward to the sprint reviews and to kicking off the next round.
   
4. Attaboys - Steve Johnson from Pragmatic Marketing mentioned this effect when he spoke at the BPMA recently. He likened it to the increased desire of a husband to tackle items on the "honey-do" list when he gets praise from his wife for doing them. The regular demos provide an opportunity not just for feedback on direction but for positive feedback. "Cool!" the product owner will say when they see something working (even partially), and cool the developer will feel hearing that. Will developers respond to that kind of thing. Are developers human? It's in our nature.

It's still under discussion but I'll push for fixed-length sprints, the shorter the better. It seems to me the chief value in Scrum is the visibility that frequent check-ins afford, facilitating accountability, course corrections, rhythm and morale-boosting attaboys. I'll let you all know how it goes as we dig in.

Next time I will try to write a bit about coordinating sprints and releases for an Agile project with the longer release cycle of an underlying platform.

Many of the problems we are grappling with seem to stem from trying to plan an Agile effort within a more traditional development organization. At my company, for example, projects can last for many months and doc and QA usually join a project already in progress and stay with a project after feature work is done. And unlike most developers, doc and QA folks (especially doc) are often split among several projects at once. So while some team members are ready to start daily scrums, it has been hard to include these disciplines. Our first pilot began scrumming with only the developers and a program manager turned scrum master. The doc person has since joined but is still splitting her time between two projects.

There is a general feeling of wanting to do Scrum "right" with this next pilot, so we've decided to wait until doc and QA can at least be part of the project kickoff where the team is supposed to review requirements and decide which features they can take on in the first sprint. Even then, commitments to other projects will mean the first few sprints in that project will have to consist of tasks not requiring doc or QA, things like tech spec writing and UI design.

At first I was uncertain about this approach. I thought one of the key principles of Scrum was that all disciplines were represented and that features were supposed to be really "done" at the end of a sprint - done as in shippable - which would, of course, require they be tested and documented. Some smart folks at Cyrus Innovation told us, though, that at least in their approach to Agile, it was more about commitments and checking progress on a regular basis than about "completing" features in each sprint.

What you put on your product backlog (the prioritized list of work for the team) doesn't have to be limited to features. The list can include anything the team needs to accomplish to meet the goals of the product. And that can begin with designs and specs. It can also begin with only part of the team represented, it seems, though we do plan to fold all disciplines in as soon as we can.

I'm still not sure how I feel about this, but it seems in resolving the tension between two principles, one sometimes has to take precendence over the other. I will revisit this issue as we move forward with the project and let you all know how we do. 

Next time I will try to talk about scheduling sprints and releases for an Agile project in a traditional organization. 

While developers sprint through development cycles, one of three things happens to product managers. 1) They are ignored. 2) They are dragged deep into the development cycle. 3) They lead the team to build products people want to buy. The first two situations are lethal to a product manager’s career. The third alternative can lead to successful products and successful careers.

She says that "the problem seems to be that everyone is trying to wrestle control from the other" but I think the destabilizing effects of a move to agile on an organization just reveal long-standing tensions between developers who want certainty about what they are supposed to build and product managers who want flexibility to respond to changing market conditions.

In the end, she says that agile doesn't really change the product manager's role. They still need to "lead the team to build products people want to buy."

A key concept is that the product manager must become the market expert and the single voice of priority on the team. Rather than just reacting to the list of requirements submitted by everyone (customers, sales, support, development, executives), the market-driven product manager visits a representative set of people in the market (including non-customers) on an ongoing basis. He keeps the team focused on the targeted market segments, buyer and user personas, and problems worth solving. He conducts surveys periodically to quantify the inputs and a keeps a prioritized list of open problems to solve.

Go Barb!

In this post, I thought I'd outline our current understanding of Scrum. Briefly, Scrum is an Agile software development methodology designed to produce higher-quality output that is more responsive to market needs. it is focused on constantly delivering value rather than on meeting a specific date with a pre-determined set of features. It is characterised by:

• Work periods called "sprints," usually of 2-4 weeks, wherein the team attempts to complete some segment of work such as a short list of product features.
• An agreed-upon definition of completeness for the work, such as that it is functional, tested, documented and otherwise "done" enough that it could be shipped to the customer as is if required. Usually this requires a demo of the work at a meeting called the "sprint review" at the end of the sprint.
  
• A list of features and other work to be done called the "product backlog," maintained and prioritized by the "product owner" (the representative of the customer, usually a product manager) and updatable between sprints.
• "Just in time requirements" that are specific and detailed for what is being worked on in the current sprint but less well-defined for work that is further down the road.
• An agreement among the team members on what features will be attempted for a given sprint, and joint responsibility for delivery of that fixed list of features.
  
• Daily quick meetings run by the "scrum master" to review what's been done in the last 24 hours and what each team member intends to do in the next (called "stand-up meetings" because they are supposed to be held standing up to motivate people to finish quickly), designed to uncover issues that need immediate resolution among team members.

The team is independent during a sprint, dividing up and and completing work as they see fit, but they must demonstrate the results of their work to the product owner at the end of every sprint. Despite the autonomy of the sprint, this increases transparency and accountability. Flexibility is also enhanced by allowing the product owner to continuously adjust the priorities of the features on the backlog for the following and later sprints in response to changing market conditions and knowledge.

There is a lot more to it, but I suggest people view Ken Schwaber's video or read some of the other great material available on the web about Scrum rather than me summarizing it all here. In my next post, I will try to summarize some of the early concerns and issues raised by folks at ATG as we talk through piloting Scrum on a project or two.

I usually get a kick out of the tech comic Geek And Poke. I thought this one and this other one were particularly apropos. 

I've been doing a bunch of reading about agile methods, especially on how it affects the product owner (read: product manager) and requirements. Predictably, Steve Johnson at Pragmatic Marketing has a good summary of Agile requirements. It takes a little time to get past his trademark warnings against "ReqSpecs" (requirements that have too much implementation in them) and the need to say no to feature-creep, but the wait is worth it for his insights on the true motivations behind Agile.

If you can't wait, though, here are four paragraphs I think are key: 

Agile is often an attempt to manage our executives rather than to be more responsive to the market. The executives keep changing their minds, adding new feature requests, flip-flopping on issues. The agile approach of development is a technique in forcing executives to choose.

Management mandates rigor and precision before the scope of the work is truly understood. “How long would it take you to build it?” “Well, that depends on what it is, doesn't it?” “Yes, but give me a date anyway.” Management over-commits Development all the time.

As product managers, we should support the ideals of agile development. We want some process, but not too much process. Small iterations give us more flexibility to adapt to change. Team collaboration means less time is spent documenting, leaving more time for doing.

The key to any agile team is building products that people want to buy. To do that, an agile team needs a messenger for the market, a product manager who thoroughly understands the problems facing today’s customers. In agile programming—and frankly in any programming model—the effective product manager serves as representative of a market of customers.

Thanks, Steve! 

Apple Wins the 2007 User>Driven Hall of Fame

With multiple nominations for Leopard, the iPhone, the iPod Touch and AppleTV, Apple had the critical mass to lift them head and shoulders among others. Yes, Apple is a company and not a product or a service, but the consistency of nominations and votes for their products and services prompted me to award them the title collectively.

"This is easy. The best product is Apples' Leopard OS. The worst is Vista. I would have said the iPhone is the best, but the opportunity to compare / contrast Apple and MS for each of their OS releases was too compelling."

"iPhone anyone??"

"I'd have to second (or maybe third) the iPhone as best. If this is truly a competition of design then it wins hands down. The small technical and pricing issues with it don't come anywhere close to outweighing the elegance of the UI and user experience. That said, I'm waiting (seemingly forever) for the 3G version :)"

"ON THE POSITIVE side, I'm going to nominate the iPod Touch, especially in light of the software upgrade announced on Tuesday. As soon as Some Bright Mind figures out how to rig an audio in microphone and get VOIP working on it, it will become my must-have device."

"I'm going to go ahead and cast my ballot for Leopard. I'm really most intrigued by its contrast with Vista, the way it shows off what an OS can do if it's not hobbled by coming from Microsoft."

HONORABLE MENTION goes to the Blueline Power Cost Monitor for the greenest product nominated. I used this at home and with what I learned I was able to reduce my electricity usage by about 25% on a sustainable basis. By translating usage into dollars in real time, it quickly helps you learn what sucks the money out of your wallet and look for ways to save.

Samsung u540 V CAST Music Phone Wins 2007 User>Driven Hall of Shame

There was enough complaining about this one particular low-cost music phone from Samsung that it had to be the winner overall. (It was nominated twice in the first two responses to the contest announcement.)

"Every time I pick it up I accidentally engage two or three different buttons. Most times, my fumbling gets me to one step short of snapping a photo. And if you are not careful, it will snap shut on you while you are trying to open it to answer the phone"

"Worst product is my wife's Samsung cell phone."

"I keep my votes to the...Samsung phone (worst), as it has only proved itself worse every day."

DISHONORABLE MENTION goes to iTunes movie rentals for their 24-hour policy. Renting movies right from your TV or your Mac and moving them easily between devices seems like a dream come true - unless you are one of those people who have a hard time finding two hours at a stretch to watch an entire movie (and who doesn't?). Pause your movie until tomorrow then try to pick it up again on a different device and poof! It's gone.

Nomination Awards 

As promised, User>Driven t-shirts go out to those who nominated the winners. Glen was the first to mention Apple in his post about Leopard vs. Vista. Gina (my sister - full disclosure) jumped in early with the Samsung u540. Congratulations and thanks for playing our game!

Maybe that's because using the net on more traditional handheld devices is so gawdawful. I've had numerous internet-enabled phones but I've never found the usability adequate enough that I wasn't willing to wait until I got back to my computer to get to what I wanted. By putting a real browser and a usable input paradigm (in other words no more Blackberry 3 clicks for every 1 you'd normally have to make) in the iPhone, Apple has made the mobile net usable.

Another one for the water is wet category, I guess. Now if they'd only add 1 32-gig model and Exchange compatibility. 3G would be nice, too. 

Because we tend to use precise numbers for small amounts and round off very large numbers (lots of zeros), [the study suggests] sellers can actually con consumers into thinking a price is smaller than it is by replacing those zeros with other digits. - from Wired's summary

The effect apparently goes beyond the familiar phenomenon of 99 cents looking more than a penny less than a dollar. When large numbers are involved (think home prices), apparently $249,673 looks like less than $249,000. The study suggests this because our brains are wired for precision with small numbers and rounding off with large ones. Ergo, precise numbers must be smaller, right? (The Cornell folks claim to have eliminated alternative explanations such as precise numbers signaling unwillingness to negotiate.)

The authors then examined more than 27,000 real-estate transactions on Long Island and in South Florida and discovered the same effect at work in real-life deals. In South Florida, having at least one zero at the end of the list price lowered the final sale price by about 0.72 percent compared with houses listed at a similar price, three zeros lowered it by 0.73 percent, and each additional zero lowered it another 0.39 percent. - from The Atlantic's summary

Bear that in mind when you are selling your next house or pricing your product. 0.72% of a $400,000 sale is enough for a couple of plasma TVs for the new abode.

Of course it should be no surprise that Americans are bad at math. Las Vegas would be just another dry, hot southwest town if that weren't so and state governments wouldn't have the lottery to generate revenue from.