In August I was fortunate enough to attend the Agile 2009 conference. I saw two excellent sessions presented by Pollyanna Pixton. I later found out that four other sessions (attended by Tefon) included recommendations of the book Stand Back and Deliver, authored by Pollyanna and 3 of her colleagues. These presenters were so convincing Tefon even purchased the book while still at the conference. It was a good read, but the chapter on the “Purpose Alignment Model” was by far my favorite.
The Purpose Alignment Model is a simple tool designed to do exactly that – facilitate an alignment of purposes. The underlying premise is all product features or development that a company performs can be placed on two scales: how critical and how differentiating they are to the operation or success of the company. With everything placed on these scales, they can then be combined into a graph.
This simple graph can make discussion about any number of product features or work processes significantly easier and more effective. When discussion about a feature starts by first placing it on the graph above, it is placed sharply into perspective.
What constitutes a mission critical differentiating feature? One simple method for determining this is to ask ‘Could this feature be the center of an advertising campaign for the product?’ These features are the driving force to a product’s adoption and define the identity of the company. If every feature gets a ‘yes’ answer to this question the model is being used wrong. Trying to differentiate with every feature will result in little more than a mediocre product. A select few features should be placed in the ‘Invest’ quadrant and these are the features that, naturally, should receive heavy investment. If these features aren’t the most polished and solid in the product, get to work.
If an honest assessment of everything about a product is completed with this model, the majority of what might initially have been placed in the investment quadrant will end up falling into the parity quadrant. The parity quadrant is interesting. Most of a product’s features will invariably not be differentiating, so why waste resources trying to develop them? These features are mission critical, make no mistake about it, they have to work and they have to work well. Parity features will drive the sticking power of an application, thus it is still critical to get them right. The key point, however, is that parity features only need to reach parity. No wheel reinventing required. Parity features aren’t innovative. Look at what the market is doing. What is the accepted best practice? Do that and nothing more.
If a feature is differentiating but not critical to the success of the business, find a partner. Don’t waste resources that could be spent getting parity features to parity and investing in mission critical differentiating features. Find a partner who is investing in the feature and use them.
If a feature is not mission critical and not differentiating, who cares? If a feature in this quadrant is being worked on, ask why.
If every feature to be worked on is placed properly relative to each other on this graph the result is an amazingly powerful communication tool. Suddenly everyone from the CEO to the developer implementing the feature can easily be on the exact same page. With an aligned purpose across the whole team, from executive to business to development to IT, more time is spent making a profit and less time debating about how to make a profit.
By: Dustin Bartlett
Whenever I go to restaurant, I always spent a lot of time to choose my menu. Ordering from the menu is still a very complex process for me. Sometimes, I feel more comfortable with ordering fast food.
Just order combo 1!
It is so convenient and hassle free. What a simple choice..!!! Combo menu solves all my confusion about what to choose. However, what if every restaurant has only combo set menu? It’s not the world I want to live in… I still want to order with variety of choice.
SD West 2009 gives me a lot of choice on the menu. It is not a burger shop which only has combo set menu. It has too many variety of choice. Everyday I had a hard time in deciding which session to go to.
I tried to enjoy the diversity of flavors as much as I can.
Here is my menu list for SD West 2009.
BDD (Behavior Driven Development) and Acceptance Test
New Spring Framework 3.0
DSL (Domain Specific Language)
Java can serve DSL…
Java with multi-thread
Interface with Design
Interface-Oriented Design (Interface means ability)
Design Pattern from Theory to Practice (Interface means flexibility)
I am still enjoying plenty of new streams of technology. If you want to taste one of those menu, I would love to share the recipe with you.
Now I am full……um um yammmm
By: Henry Ha
On behalf of Todd (there were 2 UE related talk at the same time), I went to the “Personas, Profiles, Actors, & Roles: Modeling Users to target Successful Product Design” by Jeff Patton. Being a newbie in this area, I found the idea to be refreshing and powerful. Using the funny video clip on Spinal Tab’s stonehenge, he illustrated the importance of understanding the context of the product that we are building, rather than blindly following specification from the clients/users.
A software product is shaped by business strategy, users, legacy code, regulatory constraints, product usage … Being agile, we can have a bloated backlog. A good way deal with that issue is to identify the different types of users that is relevant to the product design and prioritize them accordingly to the targeted audience that we care most. We can have many different way of categorizing the user, such as according to their computer skills, their goals (broker vs agent vs buyers vs press…), first time user, returning user, user with different domain understanding level (agent just got into real estate business vs agent who has years of experience)…. We can come up with lots of different users with their own characteristics, but some users may not make a difference in how the product should function, hence we can group them together. After having distincts personas, we can prioritze them taking into account of the business goals, then we can priortize the different feature/design according to the characteristics. Personas make user data more tangible, ensure we didn’t miss the different aspects and gives clue about the proper UE design. The distinct personas show who are the targeted audience and become the design imperatives to keep us focus.
By: Nyik San Ting