Craftsmanship and Artful Making
At Agile2008, in his banquet keynote,
Uncle Bob proposed that "
craftsmanship over execution" be added to the
Agile Manifesto as the fifth value statement. I've blogged
before about the lack of craftsmanship in software development and it continues to concern me.
While in Toronto I was reading
Artful Making
. The book bored me for the first few chapters but then it quickly became a compelling read. I recommend it. It contains many statements of wisdom. One passage, talking about a stage set designer, resonated with me:
The designers movements were simple, free of tension. But the control that allowed this simplicity and freedom of movement was sophisticated and hard-won, a consequence of many iterations - individual rigor drawn from iterative experience yielding great precision.
For me, '
the control that allowed this simplicity and freedom of movement was sophisticated and hard-won' is called craftsmanship. As a worker practices the techniques for wielding his tools to work his material, he develops an '
individual rigor drawn from iterative experience yielding great precision'. Repetitive mechanical application teaches disciplined handling of the tools and also creates recurring opportunity to
learn more and gain experience. The practices governing how tools are used, once silently incanted, become inculcated. Contextual awareness develops and
a deeper understanding of the principles underlying the techniques is acquired. Intuition develops providing internal guidance to a growing expertise in trade craft.
As I
blogged previously, a craftsman's mastery is borne out of his personal discipline when applying techniques to use his tools, his awareness of what's going on around him, and his thought processes.
Martha Graham said,
technique is the dancer's freedom. Technique is also the developer's freedom.
Labels: agile manifesto, agile2008, craftsmanship, uncle bob
Links to this post
Energizers in Toronto
Labels: agile2008
Links to this post
Agile2008: The natural laws of software development
Via
InfoQ.
At Agile2008 I watched Ron Jeffries and Chet Hendrickson talk about the natural laws of software development.
Deriving agile practices from first principles could help people see beneath the practices to understand why they are done and why they are done like they are.
But, how many developers are truly capable of achieving the levels of discipline, craftsmanship and ethics and the necessary level of rigour to use these practices to great effect? Can this stuff really be coached to anyone or only those with an aptitude for it? Regardless, getting people to first understand the 'why' is definitely a step worth taking.
Labels: agile practices, agile2008, chet hendrickson, ron jeffries
Links to this post
Agile2008: Converting business value into actual money
At Agile2008, Luke Hohmann from
Enthiosys talked about
converting business value into actual money. Luke said
prioritizing the backlog by ROI doesn't work and suggested
developing attributes for backlog prioritization that drive profitable growth. In terms of what we've been doing at one of our clients using
Throughput Accounting this means increasing revenue without significantly increasing investment and decreasing costs without impacting throughput (or the capacity to deliver).
Luke explained that to effectively
prioritize the backlog for profit a
set of attributes should be identified for the stories in it. A weight is assigned to each attribute representing the degree of influence the attribute has. A 1 or a 0 is assigned to the attribute, which is multiplied by the weight. Using binary numbers activates the weight rather than amplifies it. The backlog is sorted by the resulting numbers. Attributes can be broadly grouped as follows (there may be others):
1. Stakeholder PreferencesInternal stakeholders might be sales, marketing, customer service. And, of course, the product or 'system' itself because it has its own needs (repayment of debt, performance, maintenance, etc) and should therefore have its own voice to encourage continuous investment in its architecture and upkeep. External stakeholders might be customers, integration and/or development partners, distributors. Obtain stakeholder preferences by leveraging attribute weighting and collaborative
innovation games to enable continuous prioritization of the backlog.
2. Strategic AlignmentThe backlog must support the larger corporate and portfolio goals. Associate corporate strategy attributes to the backlog and identify which stories directly support the strategy.
3. Driving ProfitThe business model for driving profit comprises a
value exchange model and a
profit engine. The value exchange model defines the mechanism by which value is converted to money. Here are some value exchange models:
- Time-based access - Revenue earned by granting the right to use the product for a defined period of time, e.g. licensing, rental, subscription.
- Transaction - Revenue earned by charging for completion of units of work, e.g. completing a credit card payment on behalf of the card holder.
- Meter - Revenue earned by constraining the use of the product, e.g. the number of concurrent users or pay-as-you-go mobile phone cards.
- Percentage of revenue gained (or costs saved) - Revenue earned by taking a cut of the profit, e.g. a royalty payment.
- Hardware - Revenue earned by charging an amount for the hardware required to use the software, e.g. dongles.
- Service - Revenue earned by providing a service, e.g. technical support, upgrades.
- Data or Content - Revenue earned by creating unique data and charging for access to it.
The profit engine defines how the product's relationship with the market is structured to drive increasing exchanges of value. E.g. credit card provider networks are widely available and card providers drive common standards (for the card and card readers) to lower costs and offer additional services such as anti-fraud to drive transactions.
A prioritized backlog should be consistent with the product's value exchange model and profit engine. It should be possible to identify the stories that contribute to driving profit, e.g if a product's value exchange model is transactional then a story aimed at reducing processing time per transaction could assist profit by lowering operational costs. A prioritized backlog should also balance stakeholder demands and be strategically aligned with the portfolio and corporate strategy. So, each iteration should convert value into money by delivering something that generates revenue and grows profit. Every stakeholder should receive something that demonstrably satisfies their needs and the product, portfolio and corporate goals.
Labels: agile2008, business value, enthiosys, luke hohman, product management
Links to this post
A 'Nut it out' Norm
Via
Diana Larsen.
I really like the idea of having a
team norm in place to help deal with interpersonal conflict.
The norm would require the people involved in the conflict, as part of their membership of the team, to work together (with the help of a facilitator; aka Scrum Master) to find the root cause of their conflict. Basically get in a room and work it out before the conflict gets bigger and pulls the whole team down. The people involved are required to bring their analysis and agreement to the next retrospective and report it to the team so that everyone learns from the experience.
Labels: agile2008, conflict resolution, retrospective, team norms
Links to this post
Lack of humble pie leaves bitter aftertaste
A cornerstone of the agile community is collaboration. However, I came away from Agile2008 feeling slightly deflated. Over the past few months one of our teams cited the lack of respect as the root cause for the breakdown in collaboration they were experiencing. A lack of respect is in itself a symptom of something else more fundamental - the absence of humility. Humility is not self-debasement but rather the ability to get over ones own ego and false pride. The humble person genuinely listens with interest and without conceit to other peoples' points of view. Humility creates context for the open exchange of information and ideas regardless of the difference in experience of the people involved and sets a stage for shared learning.
What happens when humility departs? Collaboration breaks down, communication becomes broadcast, people talk at and past one another. I wonder what the perception of people new to the agile community was of the conference experts and aficionados? I witnessed a number of conversations around the open spaces where some experts demonstrated an outward disinterest. The interactions seemed empty, devoid of meaningful engagement. Is this a side-effect of excessive pride, the feeling that nothing can be learned from people who are not seen as part of the clique? We're all vulnerable to attacks of pride, myself included. The worst thing was, in that environment, I sometimes found myself demonstrating the same behaviors and it left a bitter taste in my mouth. It would appear the effect is contagious. Is this some kind of competition for kudos?
Perhaps it's time people took a step back and did some introspection before engaging with the wider community again. Mary Poppendieck pointed out the difference between smart and wise. Smart people provide intellectual horsepower whereas wise people go further, they also ask for and offer help, they demonstrate humility. Maybe the agile community needs a bit more wisdom and a bit less 'smartness'.
Labels: agile2008, humility
Links to this post
Agile2008: Discovering what business value is and what to do about it
Joe Little's
session was interesting. Basically, you need to define what business value is for your product and that definition may evolve over time.
I've always used the
chartering session to derive an implicit definition for business value through the identification of success criteria for the product. For example, we're currently developing portals for a client and, since The Business considers itself to be in an investment phase, what's valuable to them at the moment is audience acquisition rather than revenue generation. (If they can attract and retain users in the present deflated market when it turns upward the revenue will be generated as a bi-product of having acquired a large user base.) So, measurable success criteria for the product are X registrations per month, Y page views per month, Z unique users per month. And business value is defined in those terms - registrations, page views, unique users, visits, etc.
Joe suggested using business value points, similar to
story points, which are a measure of the relative magnitude of value (and to use the
Fibonacci sequence to distribute value across a scale). I like the idea and need to chew on it for wee while but I'm thinking it could be useful in the prioritisation technique we're developing for 'following the money'.
Labels: agile2008, business value, joe little
Links to this post
Show me the running tested features
Ron Jeffries said if you get
running tested features in front the customer/users they'll start using it. If you get running tested features in front of the customer/users every week there comes a time when they say, "Hey, we can actually start using this now". We experienced this at one of our clients. We put running tested features in front of the customer at the end of the first week. They loved it. After 9 weeks they were pleasantly shocked at the richness and coherence of the running tested features available and decided to 'go alpha'. After 15 weeks they were ecstatic and decided to 'go beta'. After 18 weeks they decided to make it official and removed the beta badge.
The Business should always be saying "Show me the running tested features".
Labels: agile2008, ron jeffries, running tested features
Links to this post
Marketing should be held accountable
First, this advert made me laugh. Then I got annoyed. "Agile squared - Agility meets Visibility." When you read that tag line what does it say to you? When I read it, I interpreted the message to say that visibility wasn't part of being agile in the first place and that the tool is the saviour for keeping things visible. Bah!
If your tool helps keep things visible then say it helps keep things visible. Be specific. Be clear. Don't let your marketing beast suggest otherwise. If you're a tool vendor and you really think you're being agile and are building stuff for people who are being agile then surely one of your values is open and honest communication? It worked for Dudley Moore. Remember "Volvos. They're boxy but good".
I guess there's another universe me and the other
Crazy People should be living in.
Labels: accountability, agile2008, honesty
Links to this post
Agile2008: James Surowiecki on The Wisdom of Crowds
James Surowiecki kicked off
Agile2008 with his keynote speech on
Wisdom of Crowds. And he did it without a Powerpoint deck. "Awesome", as the Canadians say. I read the book about a year ago and the talk was still fascinating.
A group is often more intelligent than the most intelligent person in the group. This doesn't just happen. There are 3 conditions necessary for a group to be smart:
- The group must be able to aggregate the judgments of individuals into a collective judgment.
- The group must comprise a diverse set of people who demonstrate cognitive diversity, coming at the problem from different perspectives, to avoid everyone making the same mistake.
- Individuals in the group must act independently, like individuals, and think for themselves to avoid groupthink. People need to offer up their own judgments and not succumb to peer pressure.
The more homogenous a group becomes the dumber it gets. A team that's been together long enough for people to become friends outside work is a group that is probably becoming homogeneous in some respects. I
tweeted recently about seeing a team that has been together for a long time start to demonstrate familial traits like bickering and squabbling. The best group decisions emerge from constructive disagreement and conflict but squabbling is not the kind of chemistry needed to leverage the wisdom of crowds in a team. Regularly introducing new people to groups is an effective way to avoid ossification of the group so we've taken steps to break the team up and form a number of new teams into which we've introduced new people.
Labels: agile2008, james surowiecki, wisdom of crowds
Links to this post
Conference junk
Sponsor marketing junk from 3 conference bags. Freebies! I'd rather not have it please.
Labels: agile2008
Links to this post
