Archive for the ‘agile’ tag
Short Answers #2: What to Focus on in 2009
It’s officially a series now. In this Short Answers video, I answer the question, “If my Scrum team could work on one thing in 2009, what should it be?”
New Benjamin Zander Video - “How Fascinating!”
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.
UI Sketches for Distributed Teams
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.
Short Answers #1: When Stories Are Larger Than Planned
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?
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.
Motivated Individuals
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.
A Common, but Bad, Idea
Please don’t do this:
Risk
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
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:
Free Agile Product Management Seminar - Nov 11, Denver
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:
