Luke Hohmann’s Blog

One of the phrases that Enthiosys consultants use is “The Zen of Agile”. Although the meaning of Zen is associated with Buddhism, we don’t mean this to mean someone who has become a “religious” convert or zealot for Agile Product Developmnent. Instead, we mean it to mean someone who comes to understand the deeper meaning of Agile and the principles that drive Agile through their own direct experience.

This disctinction is important as it helps to get past the trivial questions Enthiosys consultants often get when we’re helping product teams adopt agile practices. One such trivial question deals with the kind and level of documentation needed for a successful agile project. The proper answer, whether you’re a consultant or not, is “it depends”. Embracing that this is the proper answer is part of the Zen of Agile.

Consider this question in the context of one of the most discussed documents associated with product development: The Market Requirements Document, or MRD. (Lots of people are discussing the pros/cons of MRDs, and the role of MRDs in Agile Product Development; a few include Roger Cauvin and Tyner Blain).

A simplistic, Waterfall influenced development process simply mandates that you create MRDs for every project/release, and, more than likely, similarly mandates that you follow a rigid format. An Agile process, on the other hand, would state you create an MRD when needed, and include the information required to answer the questions and/or document the problems that your team needs to address.

But getting there in one step is really hard for teams that haven’t got any experience with Agile. A better result is achieved when teams come to this realization through their own experience and then, through the Zen of Agile, decide what to do about this.

To illustrate this concept I’ll use a story from a client team that is well along the path of getting the Zen of Agile. This team was in the process of trying to reconcile the tension of their traditional “You must build an MRD for every release” (Waterfall-centric development with their new experience of Agile development (”We value working software over comprehensive documentation“). In a shared meeting, they rather quickly realized that they don’t always need an MRD. They sometimes need an MRD. And they had pretty good ideas on knowing when they did, and didn’t, need an MRD.

Funny thing, though. This team was composed of smart, experienced, and hard-working people. They already knew that they don’t always need an MRD. But, they were working in a system that didn’t really allow for them to act on this knowledge.

The Zen of Agile — their direct experience with Agile — allowed them to embrace this idea by simply stating that they, as a team, will decide when they need an MRD, and that they will trust their shared social processes to ensure that no one person can avoid creating an MRD when one is needed or force one as a process step when one isn’t. And yes, they even created a process for dealing with the inevitable “we’re not sure if an MRD is needed” by creating a time-boxed inquiry process for handling such situations.

The results include better MRDs when they are needed, and faster, more agile development when they’re not. This is a powerful expression of the Zen of Agile

Special thanks to Peter, a client who inspired this post, and who has indeed acquired the Zen of Agile.

The maturity of your target market is one of the strongest influences on the selection and management of a given business model. In the early phases of a given market, business models should be chosen so that they can be quickly and easily understood, primarily because you may not be certain of the best way to structure them. You may find that your customers prefer an annual license to a subscription, or that they expect discounts if they purchase in bulk. Moreover, despite the best intentions of the business plan, innovators and early adopters may expect and/or demand special terms.

As the market matures, chances are good that your business model will become increasingly complex in order to serve the idiosyncratic needs of different market segments. I helped one client whose growth had stalled attack a new market segment with the same underlying system simply by defining a new business model. The original one consisted of an annual license. The new one was pay per use. The easy part was modifying the underlying architecture so that both models could be supported. The hard part was creating the appropriate price points so that a given customer could choose the best model without harming the relationships with current customers. This is not always the case, however, and it is more typical that changes to the business model can cause significant changes to your underlying architecture. These changes are often so large that they consume an entire release cycle (and sometimes two) to fully implement.

The enforcement of business models also matches the maturity of the target market. In early market stages, enforcement tends to be lax. As the market matures, or in cases where you suspect piracy, the enforcement tightens up. My experience is that product managers and software architects take enforcement far too lightly. You’ve worked hard to create your system, and software piracy is a serious problem. Create a business model that identifies the real value provided to your customers, price it competitively, and enforce it accordingly. Just remember that onerous enforcement will lead to dissatisfaction among honest customers, so be careful.

Choosing a business model is one of the most challenging tasks faced by the product manager, as it incorporates a plethora of factors, such as the business and licensing models offered by competitors (which may constrain you to existing market expectations) and corporate and/or environmental factors beyond your control (such as when another division does poorly and you need to find a way to increase short-term revenue). To help you through the potential morass of choosing a business model, consider these questions.

• Who is the target market? What do they value? A crisp description of the target market and what it values is the first step in creating an appropriate business licensing model. If you’re not certain of  what it values, consider how it wants to use what you’re offering. Once you’ve determined your market values, show how your solution provides it.
• What are your objectives relative to this target market? In an emerging market you may wish to capture market share, so create simpler models. In a mature market you may wish to protect market share, so create more complex models to provide flexibility.
• What is your type of value exchange? In other words, what is basic mechanism that tracks and/or causes “money” to change hands?
• What rights do you wish to convey? Begin by asking your legal department for a “standard” contract, as it will contain a variety of nonnegotiable rights and restrictions. Many of these you can ignore. Focus on the business terms that motivate sales of your software.
• What is the affect of this business model on your technical architecture? Work with the software architect to make certain that any business model you propose is appropriately supported.
• What is the pricing model? The business model provides the framework for defining how you’re going to make money. The pricing model sets the amount the customer will pay. You’ll need to consider such things as volume discounts, sales and/or channel incentives, and so forth. Pricing choices may also affect your software architecture, so make them carefully.

As you develop the answers to these questions, you’re likely to find that the best way to reach a given target market will require a variety of changes to your current business model, licensing model, and software architecture. You’ll have to rank-order the changes in all areas of your product so that you can reach the largest target market. The benefits are worth it, for creating the right business and licensing model for you and your customers is the best way to maximize profits while increasing customer satisfaction.

Innovation Games® is being discussed at in the Agile and Other Processes forum at JavaRanch. There are some interesting posts — come join the fun.

I speak at a lot of conferences. Part of my job. For quite some time I’ve been promoting the idea that conferences should provide open rating systems of the speakers. This way you could have the prior feedback of other conference participants to help you decide if you should listen to someone speak. Of course, the idea isn’t perfect or foolproof. It is more an attempt to share information.

In this spirit of sharing, I offer the complete text of the email I just received from the organizers of the Software Development Best Practices conference, which contains my evaluation. I’m pleased to learn that my session beat the conference average but that not all of the people who attended my session completed feedback forms (I had more than 14 people). I think that this is because my presentations rely a lot on “learning by doing”.

—————

Dear Luke Hohmann,

I’d like to extend my sincerest appreciation for all of your hard work in preparing and presenting for SD Best Practices 2006. I hope you enjoyed your experience.

Below is a link that will allow you to access your session evaluation results and the compiled comments that were collected. We rely heavily on attendee feedback to help us determine which topics best met the needs of the attendees and where we can make modifications to better meet expectations for next year.

https://www.cmpevents.com/?M=7I3QW2VGMEjoZwelCQJDMpKPWm532XRGCE1eewP2pA==

Please note: Birds-of-a-Feather Sessions will not have evaluation results.

We’ve received some really positive feedback regarding the conference.

On behalf of the Dr. Dobb’s SD Events Group I want to thank you for your part in that success. Without your commitment, we could not have done it.

We’ve transcribed the notes as they were written–complete with spelling and grammatical errors, along with the occasionally profound and or profane comment. Also, take note that comments do not always accurately reflect the overall rating of your course. Unfortunately, many attendees who rate courses highly do not make any comments, sometimes making the tenor of the comments seem overly critical. In any case, I hope you find the feedback valuable.

Below is some information that you might find helpful in order to compare your results with the conference average.

1.) Average Overall Rating: 7.94

This would be an average of question #6 on the evaluation form “Overall rating of the presentation” This rating was determined by the attendees.

2.) Average Rating: 8.10

This is an average rating of questions 1-6. This rating is located at the top of the evaluation summary, next to the headcount.

3.) Average Headcount: 65

Thanks again for all of your hard work and dedication to the event. I enjoyed working with you and hope to do so, on future events.

Save the date: SD West 2007 will be held March 19-23, 2007 at the Santa Clara Convention Center.

Sincerely,

Michelle Ruettinger

Conference Specialist

Dr. Dobb’s SD Events Group

CMP Media

600 Harrison St., 5th Floor

San Francisco, CA 94107

www.sdexpo.com

In a few weeks Enthiosys is going to be conducting several Innovation Games at the PDMA National Conference (you’re coming, right?). We’ve got a 10×20 booth at the conference, and a great wall space for playing games. The challenge that we’re facing is creating our first booth.

(I should state that Scott Gilbert, President of Enthiosys, warned me heading into this event that this was going to be a lot of work — more than expected. Boy, was he right!)

I started by researching the various exhibit companies that will help you design and plan your booth. What a racket! The prices were unbelievable. Way beyond our meager budget for something that didn’t strike me as all that memorable or useful for our purpose.

I naturally started searching the web for tasteful shelving/furniture that we could use for our booth and would fit our budget. Succombing to the advertising of tasteful furniture at affordable prices, I checked out Ikea. Their web site offers exactly what I think would fit our needs — the Ivar Wall Unit. It has space for shelves that we could use for playing the games and storing game supplies. It seems relatively tasteful, and a price that we can afford.

Keep in mind that Enthiosys is located in CA and the conference is in Atlanta. So, the natural solution is to order online and have it shipped to the conference. I can do this at just about every retailer I know.

But I can’t purchase the unit online. Why, I don’t know. Hmmm.

So I called up the number on the web site. They told me that I can’t purchase this over the phone. Huh?

Well, how can I purchase this unit? What I was told was that the only way I can purchase this item is if I physically go to the store, in Atlanta, to purchase the unit in person.

Now, let’s think about this. I live in California. Flying out to Atlanta to purchase a unit doesn’t really make that much sense, does it.

I noted that the web site lists a local delivery option. Since the PDMA conference is being held just a short distance from the Ikea store, I figured it qualified for local delivery. It does. But I can’t order it over the phone.

As it turns out, you can’t even talk to someone at the store. All calls are routed to a call center. And the call center won’t let me talk to the store.

I spent about 90 minutes calling all sorts of people. I asked them to imagine I was standing in the store, credit card in hand, wanting to purchase the unit. No dice.

I asked if there was any way we could get this done. Nope. The rules are the rules. I even referenced Nordstrom’s, and mentioned that I was sure that if I was trying to purchase an item from Nordstrom’s from California for a conference in Atlanta they’d probably find a way to help me do this. The reponse was just classic — “You’re right, sir — Nordstrom’s would probably help you. But Ikea is a Swedish company, and we have rules, and we don’t break them for customers”.

Perhaps there is some possible silver lining to all of this. It gives me a chance to blog about a few things I think are important in managing products through channels.

The first is that you should offer your product through as many channels as possible. Don’t make me do the work of looking for what I want, finding it, and then telling me I can only purchase it through one channel. Instead, try what Land’s End does — let me purchase the object of my desires any way that I want (and make every way enjoyable). Along the way, don’t make me worry about which channel I want to use.

Of course, technology products often go through many different channels, and some of those channels (such as VARs) improve the product in the process. In this case you should communicate the offerings and provide ways to let people interact with that channel in a way that is appropriate for that channel.

As for Ikea, I offer three suggestions:

1. (Ideal) Change your strategy so that a customer can purchase whatever they want through the web, through the phone, through the catalog, or directly in the store.
2. (Ideal) Empower your employees to break the rules when a potential customer (me) is begging you to take my money. Here’s a hint: Take it. I’ll come back and spend a lot more. (Guess how likely I am to try and purchase Ikea items in the future).
3. (Less ideal) Redesign your web site so that the customer is not confused about what they can order. In other words, don’t get me interested in purchasing something that I simply cannot purchase.

So now I’m off searching the web for a different company that can offer tasteful furniture that I can purchase in CA and have shipped to Atlanta.

Suggestions, anyone?