Run in to showcase
Just before lunch on a
Tuesday we do a quick
stand-up to
bring the team up from their stories and check-in to ensure we're on track for the afternoon run in to the
showcase. The post-it notes remind us which sound plays at the alarm time (we've got some cronjobs configured on the build machine).
This is an evolution of our
previous countdown to the showcase.
Labels: showcase, standup
Links to this post
Well-factored code
We recently held a code review for a system we'll be working with intensely over the coming months. Like car parking spaces, desk moves, checkout queues and methodologies, code reviews are one of those things that tend to make normal, sane, rational people turn feral. It was important that the right tone be set so that everyone involved could engage constructively and with respect. In order to create a common understanding of what we were trying to achieve we kicked off with a discussion about what 'well-factored' code really meant, attempting to eliminate some of the subjectivity that typically surrounds this topic (checkout some of the
discussion on the c2 wiki!). I threw together this mindmap using
freemind to give us something to use as a starting point:
I'm pleased to say that the team reached consensus on the next steps to move forward after weighing up the cost and risk of the various options that the review produced and are now busy building out a backlog with their product owner for the work identified.
Amusingly, when I arrived home that day there was a new copy of
Uncle Bob's Clean Code
on the sofa which O had just purchased.
Labels: code review, feral, well-factored code
Links to this post
Planning game is getting too serious
The team has taken the idea of
planning poker a bit too far.
Labels: planning game, planning poker
Links to this post
The price of excellence is discipline. The cost of mediocrity is disappointment
- William W. Ward
To help you appreciate and understand the values you believe in, look at the people you respect. All of us have role models - those people we admire and look up to for the qualities that they possess. We may admire their intelligence, sense of family, fame, wealth, courage, positive energy, community activism or social action, high coding standards, domain knowledge, ability to catch critical bugs during testing, business and application knowledge as product owners, level of personal discipline, or simply their compassion for others. They may be famous people, family members, friends, colleagues or even fictional characters from television or movies like star trek, superman or batman.
Who are the people you look up to? Why?
What qualities do you admire in others?
In the Star Trek television series, I admire the strength and energy of their captains. They were all focused, strong and highly disciplined individuals. They are always in control of themselves. They know who they are, where they are going in life,
and they go there. I especially admire their sense of independence, adventure, duty, responsibility, leadership, team work and will power.
Make an effort each day to bring you closer to your goal, make a commitment to yourself that you will continuously strive to make a conscious decision each day to improve your discipline and aim for excellence.
Remember that the only obstacle that stands between you and your personal success in all that you do is
yourself.
Credit to Scott McMillan (The Big Game) and The Agile Skywalker.
Labels: agility, delivery, discipline, focus, star trek
Links to this post
Welcome to Agile Skywalker
I've invited our effervescent friend Nana Abban to contribute to the
Energized Work blog.
Nana joined the crew a while back and we invited him to join us at Agile2008 where he did a splendid job drawing attention to us. Those of you at the conference will remember him as Agile Skywalker. That's him in the t-shirt. And that really is his job title.
Coming up with silly job titles is our futile rebellion against the fixation one of our clients has forthem. It's also fun to try and get one past the eastern European girl who is responsible for creating the security passes.
Links to this post
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
Be honest about what you are then start climbing
The
InfoQ publication of Pragmatic Dave Thomas' talk:
Herding Racehorses, Racing Sheep introduces the Dreyfus Model of Skill Acquisition, which describes how people progress through levels of mastery in a subject:
- Novice - Novices have little or no previous experience and context from which to make decisions. They require a safe environment, context-free rules, immediate feedback and want to be told precisely what do because they don't know how to deal with mistakes.
- Advanced Beginner - Advanced beginners want information quickly because they have some context in which to place advice they've been given. They begin to formulate some principles without broad understanding but they still need guidelines to follow. They are prepared to try things on their own but they have difficulty troubleshooting.
- Competent - Competent people are able to develop conceptual models based on an increasing level of awareness of the longer term, which enables them to begin to question reasoning. They are comfortable seeking out expert advice and troubleshooting on their own.
- Proficient - Proficient people understand and apply principles and will self-correct but they still rely on some rules. They want to understand larger conceptual frameworks and are ready to learn from the experience of others but they are frustrated by oversimplified information.
- Expert - Experts are the primary sources of knowledge and information. They operate mainly from intuition rather than reason and they are continually looking for better ways. Rules degrade their performance.
As we gain experience we build mental conceptual frameworks that start to provide us with internal guidance as we learn. Moving progressively from novice through competent to expert we develop intuition about what it is we're doing and we rely less on rules and more on interactions, building context as we go.
The Dreyfus Model can help us understand and communicate with others. I think many people are dishonest when it comes to classifying themselves in the Dreyfus Model (for particular a subject). Ego probably makes them dishonest with themselves first and maybe they start to believe they are more experienced than they are. People need to be honest about what they are in the model and they need to tell others. If you're a novice and are looking for specific and comprehensive rules then you need to tell people this. You'll learn more and you'll learn more quickly when you do.
Labels: dave thomas, dreyfus model
Links to this post
Stuff I'm living now
Here are some thoughts that have been rattling around in my head for some weeks:
- Focus on the right stuff
- Deliver every week
- Get close to real users
- Continuously learn in order to improve
- Set incremental business success criteria based on empirical data
- Follow the money (generate revenue, create profit)
- Fund incrementally based on achievement of success criteria
- Maintain financial accountability
They're important so I'll try rolling them up into a more coherent post.
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
