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
Ahh, the ubiquitous Post-It® Note. My workspace is covered with lovely multi-coloured notes, or it was until I discovered Digital Notes. The unassuming Post-it has become a legend but I wanted to share it again, as told in The Knowledge-Creating Company by Nonaka, and Takeuchi.
“Art [Fry] sang in the church choir and noticed that the slips of paper he inserted to mark selected hymns would fall out. He decided to create a marker that would stick to the page but would peel off without damaging it. He made use of a peel-able adhesive that Spence Silver at the Central Research Lab had developed four years previously, and made himself some prototypes of the self-attaching sheets of paper.
Sensing a market beyond just hymnal markers, Fry got permission to use a pilot plant and started working nights to develop a process for coating Silver’s adhesive on paper. When he was told that the machine he designed could take six months to make and cost a small fortune, he single-handledly built a crude version in his own basement overnight and brought it to work the next morning. The machine worked. But the marketing people did some surveys with potential customers, who said they didn’t feel the need for paper with a weak adhesive. Fry said, “Even though I felt that there would be demand for the product, I didn’t know how to explain it in words. Even if I found the words to explain, no one would understand…” Instead, Fry distributed samples within 3M and asked people to try them out. The rest was history. Post-it Notes became a sensation thanks to Art Fry’s entrepreneurial dedication and dogged persistence.
(Nonaka I, Takeuchi H. The Knowledge-Creating Company: How Japanese Companies Create the Dynamics of Innovation. 1995)
That entrepreneurial spirit has been part of 3M’s corporate culture almost since inception. As stated in the William L. McKnight Management Principles:
“As our business grows, it becomes increasingly necessary to delegate responsibility and to encourage men and women to exercise their initiative. This requires considerable tolerance. Those men and women, to whom we delegate authority and responsibility, if they are good people, are going to want to do their jobs in their own way.
“Mistakes will be made. But if a person is essentially right, the mistakes he or she makes are not as serious in the long run as the mistakes management will make if it undertakes to tell those in authority exactly how they must do their jobs.
“Management that is destructively critical when mistakes are made kills initiative. And it’s essential that we have many people with initiative if we are to continue to grow.”
Chris touched on this when he blogged about Failing Should be Easy and even Why don’t people like my ideas?!. Art Fry was given the opportunity to fail. When people didn’t like his idea, he proceeded to find a way to prove that his idea truly was great.
I’m proud that we here at Point2 allow people to fail; in fact, using Test Driven Development we ensure that everyone fails at first.
We give people time to explore and experiment, and everyone has some time for professional development.
Incidentally, Ken Schwaber’s early paper, “SCRUM Development Process” references heavily the work of Takeuchi and Nonaka and their description of a rugby organization style.
By: Kevin Bitinsky
Over the last year I’ve learned a lot about people and business. I’ve observed that there are two basic types of interaction – those that involve logic and those that involve emotion. These interactions are applied to people and business on a daily basis, but they are generally applied in the wrong ways.
Logic can be described as a system of reasoning. When asking questions such as “which server platform should we choose, Windows or Linux”, you can weigh data points against other data points and use reason to come to a conclusion about which platform is best for you.
Emotion can be described as a mental or physiological state associated with a variety of feelings or thoughts. In essence, our moods. Emotion does not follow any system of reasoning – it just exists. There is no reason for me to be annoyed by people walking by my desk. Sometimes it just rubs me the wrong way. (I’m not really annoyed; it’s just an example.)
Now that we have defined logic and emotion, let’s look at how they are applied incorrectly.
HR managers sometimes need to tell people that they are not performing adequately. Imagine how you would feel if you were hauled into your boss’ office and told that you needed to pull up your socks. Your boss presents the logical side of your performance problems (being late, introducing bugs, etc). Your boss then logically presents a plan, metrics, and alternatives for this behaviour. Everything is cold and calculated because the boss thinks that you are logical and you can not possibly disagree with the facts.
But people are emotional. Maybe you’re late because your spouse is sick and you had to take the kids to school. Maybe you ran out of jam for your toast. Maybe your kid keeps turning off your alarm clock. On top of your home/commute/extracurricular frustrations you’re nervous about being called into the boss’s office, and now you’re angry and defensive that you don’t get to explain.
But imagine the difference if you have a great boss and emotion is applied to this situation. The boss tries to understand why you are late. The boss empathizes with your situation and realizes that the kids will grow out of the turn-off-the-alarm-clock phase. You both have a shared understanding and there is actually no problem. You say “I’ll check the clock before I go to bed”. The boss doesn’t need to prescribe a solution.
Now let’s look at the business portion of … business. People can have strong emotional attachments to things like product lines or brands. An example - there is a need for servers, but do you choose Windows or Linux? Ideally you would identify required features, the pros and cons of each platform, and come up with a formula of some sort to weigh the options. In reality you get people who are emotionally attached to one or the other and they debate based on their attachment. “Windows sucks because the kernel isn’t separated from the UI.” “Linux sucks because it has no drivers.” Or whatever. This is not the situation to make a decision based on emotion. You need to analyze the facts because you can’t properly make decisions any other way. What you end up with is one party capitulating - “Whatever, use Linux” just so you can move on and get something done.
Have you noticed this? Do you agree or not?
By: Ryan Shuya
When I started my career in IT I was a UI developer. The most I had learned in my formal post-secondary education was that projects consisted of functional requirements gathering, documentation, development, acceptance and release. I lived in a tiny bubble. Code was written and tested, and then it was magically deployed to a customer’s website by some process that I was obviously not involved in.
As my skills and responsibilities evolved, so did my aptitude for understanding everything that was going on in the development and release cycles. I wanted to know what was supposed to happen before, during and after a software release. When I read this post about non-functional requirements from Leading Answers, it reminded me how much I have learned over the past several years as well as how much I enjoy seeing things from several points of view.
Some people (of course not all…) find comfort in understanding more aspects of their development projects.
If you think that might be you, consider getting out of your bubble to explore something a little different.
By: Melanie Cey