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
So here we are at the SD West conference! We arrived last night and it has been awesome. Between the 4 of us we have attended 8 sessions today J Here’s a list and some detail of the sessions we attended today:
- Better software – No Matter What by Scott Meyers
- From Stories to Automated Acceptance Tests by Brett Schuchert
- Extreme Programming: After 10 years, Why are we still talking about it? Keynote address by Robert C. Martin
- Test-Driven Development with Junit by Robert C. Martin
- Agile Model Driven Development (AMDD): Techniques for Scaling Agile Software Development by Scott Ambler
- Set your User Stories Free with Groovy’s easyb by Andrew Glover, Rod Coffin
- Is SOA dead? Keynote address
- Life inside LinkedIn Engineering: The Architecture, the Processes, the Lessons by Rusian Belkin and Nicholas Dellamaggiore
From most of the talks we have attended today it appears that Agile, Scrum, TDD, Stories were topics that all the speakers are talking about, and we are proud to be part of Point2 where these are employed on a daily basis.
To view more photos, please go to:
More updates will be coming tomorrow!!!
By: Nyik San Ting
Our company is currently ‘diving into Python‘ which as a developer makes me extremely happy. I can see diversity is emerging in our development arena.
But this post is not so much about Python as it is about disseminating knowledge across our company, i.e. how do we make sure that our organization learns technology X or methodology Y ? If you have been in this industry for a while you must have heard this sort of answer from your boss quite often: “Make them learn that stuff at home!” or “Buy them a few books so that they can read about it at their own pace!” or the classic: “Let’s get a Knowledge Base” or “Let’s get an expert on the topic”.
Although these approaches may work for you, they have never worked for me as well as what my new company has in place. At Point2, one way to disseminate knowledge and make sure that everyone is on the same boat, is using a workshop schema whereby every Friday we run two or three workshops in parallel that last for 1 or 2 hours depending on presenter and topic. Most of them are so good that presenters have to repeat them the following week for the audience who could not attend some workshops. To give you a taste of what these are, this month we are running the Python series. The following four workshops are aligned:
- Python 101
- Django 101
- Django to interface REST services
Hopefully out of this series we’ll get some more Pythonistas in our company 😉
It would be interesting to know what other things worked for our readers, besides workshops.
By: Marcos Tarruella