Monday, 27 August 2007
Motivating volunteers
Posted by Simon Baker
Mike Griffiths asserts that when everyone on a team is recognised and treated as a volunteer their productivity far exceeds that of team members working for reward. He uses the diagram below to illustrate the scale of an individual's contribution to the team. (I've included Mike's descriptions):
Read more...
Comments: 2
Sunday, 26 August 2007
Monday, 20 August 2007
Architecting maintenance
Posted by Simon Baker
Jason Yip is distressed by the lack of consideration given to testability and maintenance by many enterprise architects and their followers. It's not all about scaling and vendor relationships, but doing the simplest thing, building features only when they're needed, and keeping options open while deferring commitment until the latest responsible moment is not the staple diet of the enterprise architect. 'Anticipate' is their word. Justify why you're not building a generalised solution that caters for everything and can handle every conceivable change. The problem with this approach is that it introduces complexity and that complexity requires significantly more maintenance. Keep it simple, stupid . Justify why you're building more than you need to. Justify why you're building something that is expensive to test. Remember: It has to work. It has to be easy to verify that it works and keeps working. It has to be maintainable. A single change should be a single change. It has to be understandable otherwise it won't be maintainable. Less things built means easier to maintain.
Friday, 10 August 2007
Grow a whole dedicated team around a single product
Posted by Simon Baker
If your people are organised by function rather than along product lines then you are fostering a silo mentality, creating artificial barriers and introducing coordination overhead. Give responsibility for each product to a cross-functional team with full-time members, located together in one place, who possess all the skills required to deliver product frequently to your customer. If a committee makes business decisions for each product then you will see a lack of authoritative decision-making and a loss of direction and urgency, resulting in delays and rework. Empower a single person , collocated and available for discussion, to own the product, champion its vision, maintain a visible backlog of requested work items prioritised by value, and steer development by making business decisions quickly.
Wednesday, 8 August 2007
Partnerships, not relationships
Posted by Simon Baker
If you establish relationships that keep the other parties at arms-length and are based on contracts describing the expected results rather than the nature of the relationship, then each party will work for its own short-term gains, and the relationship is likely to break down over time as goals diverge, motives are questioned, and communication becomes forced. Nurture cooperative partnerships for the long-term that are built on mutual loyalty, trust and confidence, and which share the risks and the rewards. Treat your partners as extensions to your business and align incentives so that everybody works for the good of the partnership.
Reward the team, not the individual
Posted by Simon Baker
If reward is linked to a person's individual performance and job title then you are encouraging people to pursue success as an individual. This undermines teamwork and peoples' sense of team. Actively support the integrity of teams. Through your actions foster the conviction that a team will always be better than any individual at solving a problem and that success as a team is more important than individual success or success at any cost. Reward a team for its success and let it decide how to share the reward.
Saturday, 4 August 2007
Keep the customers' perspective visible
Posted by Simon Baker
I've talked about being customer-driven : See everything from the customer point of view first, understand value from the customers' perspective, ask what they want next and deliver it to them quickly. In the charter , express the product vision in customer terms. Start to create a product backlog by first capturing the product sponsor's strategy as goals expressed in customer terms. Organise the goals as a tree with the vision at the root. Break goals down into smaller goals (and be careful not to go too far so that strategy becomes tactics). The goal tree is a strategic planning tool but, just as importantly, you should use it as an execution tool with the goals encapsulating the voice of the customer. The product owner uses the goal tree as a roadmap to achieve the vision (periodically reviewing it with the product sponsor to ensure it continues to steer a true course). Making tactical decisions and creating tactical goals for the release and iteration planning games the product owner steers the development effort to deliver the highest value functionality to customers and realise maximum return on investment for the business.
