• We have five product owners. What do we do?
• We drop work from every sprint. How do we get out of that habit?
• We can’t ever get things “potentially shippable” at the end of a sprint. How can we?
• We spend forever in planning meetings. How can we spend less time doing that?
• etc…

So, what problems have you encountered or heard of teams encountering?

Thanks for your help.

That leads me to my new year’s resolution for 2012 and one that I hope a lot of others will make with me: make recommendations not rules.

There are very few hard-and-fast rules to agile software development. I’d put things like:

• work in iterations of no more than a month long
• by the end of each iteration be “done” with something to some pre-agreed upon definition of done and solicit feedback from your key stakeholders on it
• at the start of an iteration, get together and figure out what you’re doing to do during the iteration
• at the end of the iteration, reflect on how well you did during the iteration
• talk a lot during the iteration

Beyond that, it’s much more about recommendations. And there are plenty of things we’ve learned in the nearly 20 years that some agile processes have been around in even informal forms. For example, I recommend teams use user stories as their approach to requirements. I recommend teams use story points for estimating. I recommend that the team pick a day other than Mondays for starting their iterations. I recommend the Szechuan Chicken at Spice China. But, none of these things is required for success with agile. Each may help a team be better, and I have reasons I recommend each. But, these things are not required.

So, my resolution for 2012: Make recommendations not rules. I’d kind of like to make it a rule that you join me in this resolution, but I’ve just resolved not to make such rules.

By the time Adam Smith wrote The Wealth of Nations in 1776, pin-making had become specialized to the point where it could involve eighteen different specialists. Smith wrote that, “One man draws out the wire, another straights it, a third cuts it, a fourth points it, a fifth grinds it at the top for receiving the head…”

Not only has this trend continued through the present day, it is likely accelerating. A recent article in Harvard Business Review, “The Age of Hyperspecialization“, claims that as work becomes more knowledge-based and as communication technology improves, it is easier to split work into smaller and smaller pieces.

The article talks about about a number of companies and business models. But, in particular, presents a site called TopCoder, which allows companies to present development work that needs to be done. The work is then bid on and completed by hyperspecialists all over the world: a designer in the US, an analyst in Kiev, an architect in Bangalore, a programmer in Beijing, and so on.

These individuals do not work together as a team. Rather they have very specific artifacts to produce. The artifacts are defined in a very sequential (“waterfall”) process.

It is interesting to think about a grand, sweeping trend like the one toward hyperspecialization in contrast to agile development. Agile does not at all require individuals to be generalists, but individuals are expected to work together as a team. The handoff-driven model created by hyperspecialization and used on sites like TopCoder are anything but agile.

So where does this go? Is agile at odds with a 300-year trend? It could be. Or, perhaps teams will evolve more agile ways of working within the trend toward hyperspcialization.

This has, of course, coincided with the growth in popularity of the agile development methodologies, including Scrum. These approaches have become popular because, among other benefits, they help companies deliver products more quickly.

Why I’ve been thinking about this lately is I’ve begun to wonder if we’re nearing the end of the era in which time is a competitive advantage in project management. It’s quite possible: Other sources of competitive advantage have gone away.

Quality, for example, used to be a one of the strongest differentiators among companies. Thirty years ago, quality varied tremendously among carmakers. Today, a high quality car is assumed. Quality–at least in most manufactured goods–has largely gone away as a source of competitive advantage.

Price has long been a source of competitive advantage. But some authors have even argued that as more products and services are offered for free, price is going away as a competitive advantage.

Innovation has become a fertile area in which companies seek competitive advantage today. This has served Apple well over the past decade. I don’t think innovativeness will be going away soon as a source of competitive advantage. But I do wonder whether time is running out on time as a competitive advantage. If project management using agile and other innovations lead us to a world where all companies can deliver new products and services equally quickly, companies will need to find newer ways to differentiate themselves.
Let me know what you think.

I was in New York with my wife and daughters for spring break and doing the tourist thing. I’d live in NYC for a couple of years in the mid-1980s and was enjoying showing my daughters some of my frequent haunts. Our last full day there was very rainy, and we decided we’d visit a museum–either the American Museum of Natural History or the Metropolitan Museum of Art. We settled on the Natural History museum. Dinosaur bones win out over fancy paintings in my family any day, and I’m usually OK with that.

While buying tickets at the Natural History museum I was told that for not much more I could also buy a ticket that would let me into the Met. That was a bit odd. One museum was selling me a ticket that would let me into both. I later found out that the Met would have sold me a ticket that would also have allowed admission to the Natural History Museum.

Yet clearly these two museums were competitors. I know that because my family’s discussion that morning had been, “Which museum should we visit today?” The two museums had competed for my family’s dollars that day. Yet each was selling discounted admission to the other.

Which made sense. Sure, on that day the two museums were competitors for my attention and dollars. But, both museums realized that both could prosper together. Someone likely to enjoy a day at one museum is the type of person likely to enjoy a day at the other. A donor to one museum is likely a donor at the other.

And so, while looking at a fossilized protoceratops skull, I realized that while the Scrum Alliance and PMI are competitors in some ways, they each serve a common audience, and their real future is together just as with these two great New York museums. People likely to get a certification or training in agile processes or agile project management from one of these organizations are likely to be interested in agile training or certifications from the other.

Sure, there are times they will be competitors. Just like my family sat in our hotel deciding which museum would get our time and money that day, people will choose daily between a PMI event or certification and one from the Scrum Alliance. But, the person who takes a PMI-approved class today is the type of person who will take a Scrum Alliance class tomorrow.

Both organizations can thrive together. And that’s the future I hope we can work toward.

Even in my own division, we questioned our decision to use Scrum. After all, most of the buzz in those days was about the Unified Process. There was this feeling in the air that if you weren’t doing the Unified Process, perhaps you should be. We had been tremendously successful with Scrum yet were filled with doubt—would we have been even more successful if we used a complete methodology instead of this little toy of a process called Scrum? After all, we didn’t know anyone else doing Scrum and the term “agile software development” didn’t exist. When the whole world seemed to be moving toward a “unified process,” it was hard not to wonder if you were the only ones who weren’t.

And then one February morning I got an email from Ward Cunningham: “Look how I spent the last few days,” he wrote. He included a link to a new website, www.agilemanifesto.org, and a grainy photo of some guys standing around a whiteboard. But that website hit me like a lightning bolt—we weren’t alone, after all. Suddenly I knew there were at least seventeen others who felt the same as we did. And then day by day, there were more, each signing his or her name and adding a brief statement of solidarity on the agilemanifesto.org website.

With a name for what we were doing— agile—others like us seemed to pop out of every corner. “Yes, we do that, too,” became the catchphrase of early agilists as we all discovered we were not alone.

And now here we are ten years later, and things have swung 180 degrees. If you aren’t agile or in the process of becoming agile, you probably feel like you should be. The biggest change from ten years ago is that agile processes now deserve a seat at any table where people are discussing which process to use. If I were a VP of development today in a large conglomerate and I suggested agile to the VPs of other divisions, they could not just dismiss it with a wave of their hands. Agile, in its many forms, is a viable, credible alternative. It may not be the right one for every company or project but no one would be laughed out of the room for suggesting it.

From laughed out of the room to credible alternative in ten years. Where does agile go from here? Hopefully two things are in store for us next. First, I’d like all the brands to go away. No Scrum. No XP. No Kanban or lean. No DSDM. No Crystal. Just agile. We saw this happen two decades ago in objects. We had various modeling approaches and methods from Rumbaugh, Booch, Meyer, Jacobson, and others. Those differences were eventually put aside and we now have merely objects and UML.

The next change I’d like to see (and predict will occur) over the next ten years also occurred in the OO world: We stop talking about agile. We stopped talking about objects a while ago—they won. No one engages in big debates about OO anymore. Sure, there are some applications, such as those with intense performance requirements, where we don’t use objects. And some projects are written in non-OO languages. But even in those cases I suspect the code being written has still been influenced by objects. I’d like agile to reach this same point, where we no longer need to talk about it. Rather than “agile software development” it is just “software development.” Rather than “agile project management” it is just “project management”—Of course it’s agile. No one asks me if the Ruby code I’m writing these days is OO. Of course it is. I hope someday no has to ask if I used agile on the project. Of course I did.

In another ten years I hope I am asked to reflect on what will then be twenty years since the Agile Manifesto. I hope by then it’s a largely forgotten document, like the Magna Carta. Yeah, that dusty old thing. My life is still influenced by the Magna Carta, and I was recently called to jury duty to remind me of this, but I hardly spend my days thinking about it. I hope for a similar fate for the Agile Manifesto. And when I do reflect back on agile software development ten years from now I hope we’ve stopped calling it agile. I hope we’ve stopped calling it anything at all and are just doing it.

www.CashForClunkerPCs.com

Take one step at a time up the slippery mountainside, and make absolutely sure that each hoof is on solid ground before you take the next step.

I’ve always considered Tom to have been the original agilist. In 1989, he wrote about short iterations (each should be no more than 2% of the total project schedule). This was long before the rest of us had it figured out.
Although I’d named the company after one of Tom’s principles, I had never met him in person. Well, last month I finally had the honor of meeting Tom and his son, Kai Gilb, who is a top-notch software consultant in his own right. (See Kai’s book on the Evo process.

At dinner, Tom and Kai posed a challenge to me that I haven’t been able to figure out yet. We talked about how adding a new feature to a product is not an issue of adding new capabilities as much as it is about changing how well something can be done. I other words, it is about changing the quality of the implementation.

For example, imagine a simple word processor back in 1982 without an integrated spell-checker. Spell checking was still possible. You could have looked up each word on the screen in a physical dictionary and determined which were misspelled. Adding the integrated spell-checker was more about improving the quality of an implementation than about adding a new capability.

The challenge that Tom and Kai posed me was to think of a function in MS Word (any word processor will do), that is a new function, and not just a change in the quality of those functions. To think about this, compare Word of today with the tools of a century ago—paper, pen or pencil, the post office, and so on.

Surely, they were nuts, I thought. So I tossed off a few answers:

“Undo.”

“No,” they replied. “That could have been done in the old days with an eraser.”

“Printing.”

“No,” they replied. “That could be done by monks in a monastery making copies by hand.”

I tried a few more but came up empty. So, how about it? Can you help me by coming up with a feature in a word processor, like Microsoft Word, that is new functionality and not just a change in how well something could have been done with pencil, paper, and similar tools.

I started reading a new book called Made to Stick by Chip and Dan Heath. It’s about why some ideas are “sticky” and spread while other ideas die out. They start with the classic urban legend of the guy who is drugged and wakes up in a bathtub full of ice and discovers his kidney has been stolen. That’s a sticky idea. Many of us have heard it, and we remember it after hearing it. Sticky ideas and stories aren’t necessarily bad; they are just things that change our attention at just the right time and that are so intriguing/compelling/interesting that they spread like wildfire.

This got me thinking about sticky stories from my past and how perhaps stickiness has changed given the rapid communication of today, including and especially the Internet. One real story from my life is from back in January 1981. I was in college and living in the dorm. Ronald Reagan was newly sworn-in as President. A common joke at the time was that Reagan would start a nuclear war and blow up the whole world. The previous summer the US had boycotted the Olympics because of the Russian invasion of Afghanistan. It was a bit of frightening time.

That’s why I remember how scary it was one Sunday morning when our whole dorm woke to rumors that the US and the USSR had declared war on one another. We couldn’t confirm this, though. Not a single person in our dorm had a TV. None of the radio stations were saying anything about it. This was before Al Gore had invented the Internet. This rumor of US-USSR war was *sticky.* It spread around the whole dorm building within minutes. People were waking others, pounding on their doors saying, “Wake up, we’ve declared war on Russia!” Still, we couldn’t get any real confirmation of this.

I finally called my parents who lived two timezones away and were still asleep. I sheepishly asked, “Mom, did we declare war on Russia this morning?” She thought I was crazy so I explained. While I did that she turned on her television and confirmed nothing was being reported. That was good enough for us. All of us college students went back to sleep.

Two thoughts strike me form this: First, Communication has changed that much in 27 years. It was possible back then to be unable to verify something like a war. If that happened today I’d browse the web on my phone and know in seconds. Second, that was a very first-hand example of how quickly a sticky idea could spread.

It seems that agile might be a sticky idea.

I took off for a weekend last month
Just to try and recall the whole year.
All of the faces and all of the places,
wonderin’ where they all disappeared.
I didn’t ponder the question too long;
I was hungry and went out for a bite.
Ran into a chum with a bottle of rum,
and we wound up drinkin’ all night.

Although no one showed up with a bottle of rum last night (where are friends when you need them?), I did take some time off this weekend to “try and recall the whole year.” I had a birthday this weekend (as did my wife; we were born one day apart) so I felt entitled to a little nostalgic recollection over the year.

Wow—what a year it’s been. We’ve definitely seen agile project management methodologies cross over and become of interest to mainstream organizations. Even better, agile is definitely viewed as a viable alternative to heavier weight processes. Three years ago I used to get a lot of calls for consulting work that started with, “Can you help assess whether agile would be a good fit for us? We’re considering using it on a small pilot project.” In trying to recall the whole year, I didn’t get a single call like this. Instead, this year the calls I got were more like the one from

Jimmy continues in Changes in Latitudes, Changes in Attitudes:
Reading departure signs in some big airport
Reminds me of the places I’ve been.
Visions of good times that brought so much pleasure
Makes me want to go back again.

I did make it to Paris for a trip last fall. What a beautiful city—just like all the other great places I had the opportunity to travel this past year: Atlanta, Austin, Boston, Columbus, Dallas, Denver,Helsinki, London, Minneapolis, Orange County, Orlando, Oslo, Phoenix, Portland, Rockville, St. Louis, San Diego, San Francisco, San Jose, Seattle/Tacoma, and Washington. On the other hand, Jimmy’s right and at nights I do dream of the ocean. I grew up in Huntington Beach, California. I don’t know what someone who loves the ocean is doing living in Denver, but I really do like it here.

Jimmy wraps up with:
Yesterdays are over my shoulder,
So I can’t look back for too long.
There’s just too much to see waiting in front of me,
and I know that I just can’t go wrong

It’s exciting to think about what the coming year holds for agile software development and for those doing it. While the changes agile has made have been tremendous, there so much room for more. Think of all the projects and companies that haven’t yet started and that could benefit from a shift toward agile. The last year has been wonderful and busy. The next will be even better. Hopefully I find time to do more than dream of the ocean and do take time off for sailing.