Richard Lawrence

Short Answers #2: What to Focus on in 2009

Richard — Sat, 03 Jan 2009 23:48:33 +0000

It’s officially a series now. In this Short Answers post, I answer the question, “If my Scrum team could work on one thing in 2009, what should it be?”

Of course, adopting agile engineering practices and getting better at product management are often easier said than done. If you’d like help getting started with some of the practices I mentioned in the video, I’m running a New Year’s training and coaching special with 7 ways to get 2009 started right for less than $2,000.

Books I mentioned in the video:
The Goal by Eli Goldratt
It’s Not Luck by Eli Goldratt

New Benjamin Zander Video - “How Fascinating!”

Richard — Fri, 12 Dec 2008 18:10:40 +0000

There’s a new Benjamin Zander video over at the Pop!Tech conference website. There’s some overlap with the video from TED I posted back in June—most of the content in each video expands on the ideas in The Art of Possibility. Nonetheless, this video is well worth watching even if you’ve seen the few other videos of him on the internet.

In this video, Zander works with a 15-year-old cellist—who, as far as the boy knows, has come simply to perform for the crowd—and over the course of 20 minutes turns a technically sound performance into music, music that touches everyone there.

One moment that connects with me as an agile coach is when he teaches the young cellist how to respond to mistakes in a performance.

The natural response is to grimace, lose energy, become discouraged. (I was terrible about this as a young performing musician.) This launches a downward spiral that affects the rest of your performance and influences your audience’s perception of it. Instead of respond in that way, Zander suggests that the boy throw up his hands, smile, and say, “How fascinating!” That mistake is information. It’s an opportunity to learn and improve. He says in the book, “…it is only when we make mistakes in performance that we can really begin to notice what needs attention.” (p. 31)

The awareness of mistakes is not sufficient to improve. Improvement comes from a willingness to take risks and then to accept the inevitable mistakes as useful feedback. I tell managers that software teams that aren’t allowed to struggle and even fail in their early sprints will still struggle and still may fail…you just won’t know it in time to do anything about it. Your retrospectives may show that your team is a mess, that you struggle just to deliver working software, that there are a million places you could do better. “How fascinating!”

UI Sketches for Distributed Teams

Richard — Thu, 11 Dec 2008 20:59:17 +0000

In the same way that user stories help focus a software team’s work around business value, starting construction of a user story with the UI keeps focus on the core user experience through which that business value is received. Early in my career I’d make the most beautiful Photoshop UI mockups I could. I thought that the more the mockup looked like the final design, the better the conversation with the customer would be. Over time, I’ve learned that the opposite is true. The more the mockup looks like a sketch or a draft—something changeable—the more collaboration and early feedback I get from the customer. For collocated teams, this is easy: simply sketch the UIs on paper. Use a big marker so it’s not possible to put in too much detail. Hand over the sketch and let the customer mark it up.

What I’ve been missing, however, is a good tool to recommend for distributed teams (or teams with a remote Product Owner). Until now.

All the tools I’d tried (Photoshop, Visio, Power Point, etc.) took longer than paper or produced results that looked too polished or weren’t easy to collaborate around. Faxing or scanning the paper sketch worked pretty well, but somehow scanning always seemed to be more trouble than it ought to be.

The solution I’ve found is Balsamiq Mockups. [Disclosure: I got a free review copy, but I was prepared to buy it and write about it here within minutes of trying the evaluation version.] Mockups is an Adobe AIR program (think stand-alone Flash application), so it runs equally well on Windows or OS X. It features a library of sketches of common UI elements that can be positioned, resized, and annotated. I can build sketches here faster than I can draw them on paper, but they don’t look too polished.

There are versions of the program for wikis that specifically support collaboration around UI sketches, but I haven’t tried those.

If you’re in a situation where you can’t use paper for UI mockups, I recommend that you consider Balsamiq Mockups as an alternative. The website has more information, a trial version, and screencasts of the desktop and wiki versions of the program.

Short Answers #1: When Stories Are Larger Than Planned

Richard — Wed, 10 Dec 2008 23:20:57 +0000

I’m experimenting with video for what is likely become a new series here. In these “Short Answers” posts, I’ll answer an agile question in about a minute. Use the comments to suggest questions you’d like to see in future Short Answers.

In this post, I answer the question, “What should I do when I discover in the middle of a sprint that a story is larger than we planned?” Several people have asked me this, and the answer is not, “Suck it up and work 80 hours to get everything done.”

Are the Product Owner and ScrumMaster’s Interests Opposed?

Richard — Wed, 26 Nov 2008 17:53:31 +0000

The Chief Engineer role in the Toyota Product Development System combines parts of the Product Owner, ScrumMaster, and senior technical team member roles from Scrum. In addition to leading the technical design of a new product and facilitating the work of the other engineers, the CE must deeply understand and care about what the customer values—he has ultimate responsibility for delivering value to the customer and for the resulting commercial success or failure of the product.

CEs have gone to amazing lengths to gain that deep understanding of the customer’s needs.

For example:

While developing Toyota’s successful 2003 Sienna, the Sienna CE drove his team in Toyota’s previous minivan model more than 50,000 miles across North America through every part of Canada, the United States, and Mexico. The CE experienced a visceral lesson in what is important to the North American minivan driver and discovered in every locale new opportunities for improving the current product. As a result, the Sienna was made big enough to hold full sheets of plywood while the turning radius was tightened, more cupholders were added, and cross-wind stability was enhanced, among many other improvements that resulted from this experience.

(From The Toyota Product Development System by James M. Morgan and Jeffrey K. Liker, p. 30)

If you’ve followed recent discussions on the scrumdevelopment group, you’ve seen multiple threads over the last couple months that discussed how the interests of the team, SM, and PO are intrinsically in conflict and that acting as both PO and SM requires a kind of useful schizophrenia.

I have to wonder: Toyota is one of the best product development organizations in the world. Are Toyota’s CEs a special breed, immune to the conflicts of software teams? Do the rest of us need distinct roles to balance our selfish interests?

At the very least, if we find that the interests of our POs, SMs, and teams seem to be fundamentally in conflict, we should ask why. Shouldn’t we all have the same goal: Producing valuable software now and in the future? Perhaps we should consider how to align around that goal rather than how to balance the interests of roles centered on lesser goals in the hope that we achieve the true goal as a kind of dialectical byproduct.

It’s one thing to say that the PO and SM roles ought not be combined because each is so demanding that it requires a person’s full time attention. But it’s quite another to say that the roles are fundamentally locked in a conflict too intense to be handled by a single person, and that better software results from that conflict.

Motivated Individuals

Richard — Fri, 14 Nov 2008 20:31:35 +0000

As agile approaches the mainstream, it’s easy to lose sight of some of the core principles, especially this one:

Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.

If agile is to apply broadly, we can’t reserve it just for those projects that start with motivated individuals. We need to learn how to cultivate them.

What makes for motivated individuals on a software team?

The belief that the product is worth building. (I consider really interesting technology a special case of this.)
The belief that the expectations placed on the team are achievable.

(The book Influencer divides these into Motivation and Ability, but I find that ability so often drives motivation that the two can’t easily be separated. Nonetheless, the book and the authors’ blog are well worth reading.)

Scrum’s sharp distinction between “what to build,” which belongs to the Product Owner, and “how to build it,” which belongs to the team, can create a situation where the team passively builds whatever the Product Owner asks for whether they believe in the value or not. If better software is built by motivated individuals, this is not the way to get it.

This week, I facilitated a project retrospective for a team that struggled with the value of the product they’ve been working on since May. On several occasions, the team was visibly demotivated by the low value they saw in the product. They worked hard and did a good job, but I could tell that they weren’t motivated by the product itself. In the retrospective, one of the answers that emerged to “What should we do differently next time?” was, “Engage the Product Owner in conversations about the value of the product.” Had they done this, the team might have been able to help the Product Owner identify more valuable stories. Or the Product Owner might have been forced to articulate the value of the current stories more compellingly. Either way, the team would have been more motivated to deliver.

The principle I quoted above can be read as, “Find individuals who are already (or inherently) motivated and use them on your projects. Avoid the unmotivated individuals.” That’s fine as far as it goes, but I don’t think it usually works that way. It’s better interpreted something like this: “Find individuals who are open to caring about their work (i.e. potentially motivated). Engage them to become motivated about building something valuable. Let them make delivery commitments they believe they can achieve. Support them and get out of their way.” That’s how you build projects around motivated individuals.

A Common, but Bad, Idea

Richard — Fri, 14 Nov 2008 04:44:09 +0000

Please don’t do this:

It will hurt. Not right away, but around sprint 4 when the bugs found in sprint 3 for the stories built in sprint 2 need to be mixed in with the stories planned in sprint 3 for sprint 4. And then it’ll hurt more in sprint 5 and later when you have to start regression testing more and more code each sprint.

Instead, just do as much work as you can get really DONE in each sprint. Plan it, build it, test it, and deliver it. It’ll be hard to ensure that testing doesn’t get squeezed out the back of the sprint. It will. When that happens, try moving testing to the front of each story. Create your test cases as specifications and then do just enough development to make them pass. (Consider a tool like Cucumber for this, using it to drive Watir if you’re building a web app. Or look at Fit/Fitnesse if that’s more your style.)

One Word Can Change Your Daily Scrum

Risk

Richard — Fri, 07 Nov 2008 17:29:24 +0000

If you’re an IT executive, which is less risky? Investing a little bit in an effective agile adoption, something that’s been proven at other companies to improve cash flow, increase productivity, and grow revenues…or…hunkering down and cutting costs, knowing that at this time when your business needs you the most you’ll be less productive than you were last year?

Agile Architecture - Neither BDUF nor Chaos

Richard — Mon, 03 Nov 2008 18:00:07 +0000

I’m often asked how architecture works on agile software projects. It’s a big question, but the core answer, I think, is this: Neither a big, detailed architecture up front nor no architecture at all is a good approach. The former leads to waste. The up-front architecture tends to support features that turn out never to be necessary and that unnecessary complexity tends to make the features that are implemented more expensive than they need to be. I worked in one organization where the requirement to fully implement the company-standard architecture added several hundred thousand dollars to the initial release of any new product with questionable business value in return. The latter approach, no architecture at all, is prone to produce a system that is unmaintainable, leading to waste later as features cost increasingly more to implement and maintain as the system grows.

Here’s my two rule heuristic for agile architecture:

Have a minimally sufficient technical vision. Know where you’d like to go architecturally at a high level. What technologies do you expect to use? What architectural patterns are appropriate (e.g. SOA)? You may not implement most of the target architecture until features require it, but it will keep the team working in the same direction. Revisit this target architecture regularly as the backlog changes to ensure that it stays relevant.
Make decisions that keep your options open. Always try to build just enough to support the current features, while keeping it easy to move towards the target architecture (or any other architecture that future features may require). Avoid making commitments to a particular architecture before you have to.

For example, suppose your target architecture includes SOA. Until your features require your business layer to be consumed as a service by more than one client, you might defer actually building the service interface. Instead, build a good OO interface and use it directly from your client, designing it such that a service facade will be easy to add when needed. Your current features will be usable faster, allowing for early ROI and for learning that might change the requirements around the service interface. Fortunately, since you haven’t built a service interface yet, you won’t have to throw anything away to incorporate that learning into the product.

You can employ a similar approach around persistence, caching, reporting, configuration, and security, among others.

Where have you struggled with agile architecture? What creative architectural solutions have you come up with that allowed you to implement just enough architecture while leaving your options open?

Free Agile Product Management Seminar - Nov 11, Denver

Richard — Thu, 30 Oct 2008 18:18:44 +0000

I’m hosting a free seminar on Tuesday, November 11 from 1:00-2:30 PM in the Denver Tech Center area. Please join me there and spread the word to others who might be interested.

Here’s a brief description:

Too many teams adopt agile processes like Scrum and XP, become effective at iterative and incremental delivery, get their software quality higher than it has ever been before, and finally achieve a sustainable pace…yet fail to harness that new productivity to deliver anything of real business value.

As an agile coach, I see Product Owners who don’t understand the features on their Product Backlogs well enough to explain them to the team in a planning session. I see Product Owners who can’t explain the larger context of a user story. I hear teams and Product Owners tell me that it’s not possible to come up with a valuable release that will take less than 6 months to build. I see teams demotivated because they don’t see the value in what they’re building.

In this free seminar, I’ll show how effective agile product management can accelerate and increase ROI, I’ll introduce an approach to identify high value feature sets, and I’ll share some tips on how to avoid getting bogged down in the details and losing the big picture.

You can find more info and register here: http://agileproductmanagement1108-rl.eventbrite.com.

Links for 2007-08-03 [del.icio.us]

Sat, 04 Aug 2007 00:00:00 -0500

Links for 2007-07-24 [del.icio.us]

Wed, 25 Jul 2007 00:00:00 -0500

Ridiculous
Ridiculous is a simple wrapper for del.icio.us API writing in Ruby.