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
Day one at the Agile 2009 conference in Chicago has more or less wrapped up. Sessions did not start until late in the morning so it gave the Point2 crew a bit of time to go out for breakfast, and to figure out where each of us had to be.
My first session was Developing Agile Leaders and Teams: A Developmental & Transformational Path as presented by fellow Canuck Gilles Brouillette. He spoke about the psychological theory behind the evolution of leaders in our society. It was interesting to see how 90% of the population hits a leadership ceiling, while only 10% are able to break through it.
After lunch I had the pleasure of seeing Robert C. Martin speak about Craftsmanship in software development. This guy is a pro and it was nice to see that Point2 is already doing most of what he is preaching. An interesting moment was when he asked people to raise their hands based on how many unit tests their team had. Mine stayed up until the “over 4000” mark, and one guy kept his up stating they had 20,000. Martin thought that was awesome, then asked how long they took to run. The guy responded, “all day.”
Giving and Receiving Effective Feedback by Elizabeth Keogh was acceptable, but I think Point2 is further ahead on some of the feedback work we’ve been practicing internally. I personally think that the feedback session proposal we made to Agile 2009 would have been stronger.
My final session for the day was 10 Temptations of an Agile Coach (new or experienced). Stevie Borne did a nice job of exposing many pitfalls that Agile leaders can succumb to, while providing many tips to help recover from, and avoid them.
The day wrapped up with an Ice Breaker event which included a few minor events, company booths, munchies, and “beverages”. I had the opportunity to speak to a few people in the crowd, and it was interesting to see people in different stages of Agile adoption. It was also pretty cool to be asked for advice on how they could make the transition easier, and what types of processes they should embrace. Seems like we’re doing the right things back at home.
At Point2 Technologies, we develop software following Agile principles. We are always interested in discovering, learning, and sharing new and better ways to embrace agile development practices. That is why we would like attend and possibly present at the upcoming Agile 2009 conference.
We have prepared a few presentation proposals which we have submitted to the conference’s official website:
*Please note that you do need to create an account or login to be able to view the links.
By: Jesse Webb