Jerry Weinberg's The Secrets of Consulting

This book is a collection of stories and memorable rules... it is unlike anything I've read before, and is hard to absorb in one stretch--I'll probably have to go back to the "listing of laws, rules, and principles" to jar my memory every once in a while. Yet one of the beauties of Weinberg's storytelling ability is that the names quickly bring me back to the story, then back to the lesson.

So, this book says it's about consulting, but he has a very loose definition of the word--consulting is giving advice. The most important thing I got from Weinberg is to never, ever give unsolicited advice. Then, even when asked for advice, it's best not to respond directly, but rather help the person discover it him/herself.

I love his names, like Rudy's Rudebega Rule, the Law of Raspberry Jam, his insistence that as a consultant, he plays more of a role of being illogical, funny, unpredictable than anything else... He seems to have great facilitation skills, great timing "know when pays more than know how". There have been several things I do as a coach that are supported by his rules. I'll list my favorite rules below:

• the First Law of Consulting--there always is a problem
• the Second Law of Consulting--"no matter how it looks at first, it's always a people problem"
• the Third Law of Consulting--if you solve the problem too fast, it's going to be embarrassing
• the Fourth Law of Consulting--"if they didn't hire you, don't fix their problem"
• the Orange Juice test--"we can do it, and here is how much it will cost"
• Brown's Brilliant Bequest--listen to the music and the words
• the Buffalo Bridle--you can make 'em go anywhere, as long as they want to be there
• the Credit Rule--don't worry about who gets the credit
• the Duncan Hines Difference--it tastes better if you add your own egg
• the First Law of Trust--"no one but you cares about the reason you let them down"
• the Fourth Law of Trust--"the trick of earning trust is to avoid all tricks"
• the Five Minute Rule--"clients reveal the answer to their own problem in the first five minutes"
• the Ten Percent Solution Law--"if you happen to achieve more than ten percent improvement, make sure it isn't noticed"

corollary to the Law of Rasberry Jam

Weinberg's Law of Raspberry Jam states that the thinner you spread it, the thinner it gets... it's hard enough to change oneself, harder to influence a team, harder still to influence a class, and yet harder to influence readers of the book. I'd say that a corollary to this is that pop culture, which as whole doesn't respect the source of the ideas, is condemned to keep re-inventing the wheel. It's funny, because one would hope that a really good idea would spread like wildfire, but it can't--it spreads like raspberry jam instead. By the time the masses catch wind of it, it's been reduced to a jingle or technical buzz word.

where the Agile Skills Project needs to go next

There's something new happing in the agile community, despite the fact that some celebrities in our field are waiting for innovation in a post-agilist era, or saying that there's nothing new at the conferences. The transformation is subtle, but very important. In short, it's the creation of local agile implementations that value people over process, community over employers, dedication to the craft and cooperative relationships.

A lot of practitioners are getting experienced enough that they can exploit self-organization to reach out to people in contexts different from their own. Mostly these practitioners are lower profile than the signers of the agile manifesto, but they're not typical early-late majority adopters either, because they're innovating in the wake of the first wave of agilists. They're running their own open-spaces, creating local user groups and conferences, networking internationally, and doing the best they can to learn from one another. Some might call this massive adoption 'crossing the chasm', but in fact they are creating their own flavors of agile at home, based on the learning that comes from participating in the agile community, from previous experience, from corporate and government requirements, and local cultural needs. The agile conferences have been key to building this community, but they're still spread out in time and space in ways that aren't sufficiently accessible for the masses of people that are trying to do agile these days. In addition, the face-to-face conferences have provided sufficient context for people to start working together remotely. The open source world has long leveraged collaborative work at a distance--the agile community, not so much.

So here's what I see...

There are currently over 700 subscribed to the Agile Developer Skills list, which in my mind is the core of the Agile Skills Project. To me it shows that practitioners are coming together in unprecedented numbers to talk about how we might better learn from each other, to define standards by which we will hold each other, and how we'll acknowledge each other's discoveries and hard work. This is low bandwidth collaborative work and can't compare to what we learn at conferences or with consultants, but there's something new afoot.

Next we need these people to take ownership of various places on the wiki, talking about quests, or certifications, or courses; building on the skills inventory, etc. We'll need people who want to build the web application that logs quests and qualifies certifications and course material our classes.

Mostly what we need is people who are willing to tell stories about their development practices, their conclusions on what works and what doesn't, and then peer-reviewed comments on these stories. I hope to see that soon!

deliberate reflection and the Agile Skills Project

Recently I read something from Robert C Martin suggesting that it's only through deliberate efforts that we improve our craft (hence his series of Katas)... today I bumped on the following from Alistair Cockburn.

In The Reflective Practitioner, Schön follows the working habits of architects and engineers. In that book, we see people making predictions as to what their situation will support; then they do some of their work and watch what the situation actually produces, and from that, they alter their understanding. They update their understanding of the problem and the proposed solution according to the changed situation and their new learning. This “reflective conversation with the situation” is just what the Wright brothers did in designing their airfoil.

Craft implies skill in working in a medium, mental or physical. There are many materials in an engineering project and therefore many skills or crafts to become adept at. Some people need people management skills, others need mathematical skills, others need visual design skills, and so on.

Each skill and material brings its own specialized vocabulary. Ceramicists “wedge” clay and study the shrink rate of different glazes compared to clays. Civil engineers work with the tensile strength, fatigue rates, and thermal expansion of their materials. Writers look for flow and development in their texts. Programmers look at cohesion and coupling, testability, clarity of expression, and computational complexity in their algorithms. Testers work with test coverage and probabilities of occurrences. User interface (UI) designers work with cognitive-motor task switching times, recognition times, color scales, and user work patterns. Project managers work with people and are concerned with what builds or tears down trust, community, and initiative.

In each case, craft practice requires practitioners to have a reflective conversation with the material, using the specialized vocabulary. They work with the constraints offered by the materials, the vocabulary, and the project.

It is this deliberate, reflective, intentional improvement that we're trying to support with the Agile Skills Project. Do you have something you'd like to contribute? What can we create together? Sign up for the Agile Developer Skills (http://groups.google.com/group/agile-developer-skills) group, and let's talk!

Domain-Driven Design

It's been a while since a colleague (thanks, Nolan) recommended this book, but I finally read it: Domain-Driven Design by Eric Evans. The author talks about a kind of code debt I'd intuited a long time ago, but could never describe in words--a semantical mismatch between the mental model used to explain the code and the language used by domain experts. This book is important because with an alignment between the code and the domain, we can automate at higher and higher levels of abstraction, and therefore reap the benefits of rapidly increasing productivity. This is the greatest value of custom software--the domain-specific objects that reflect a team's understanding.
In Philadelphia, our team focused our code by naming projects, classes, and methods in ways that business stakeholders would recognize. This made it so we shared a ubiquitous language, as Evans calls it, a clear set of names that make sense to both developers and stakeholders. Something we didn't do enough of, though, is refactoring as the terminology evolved. We did practice merciless refactoring, but it was driven primarily by technical needs. Evans also mentions that the natural language of domain experts will be imprecise and self-contradictory, so it's important to be able to create, together, a new language that is unambiguous. Humans are especially adept at creating language, and the process of using our new shared vocabulary will propel us to simplification--we naturally find easier ways to say things. By implementing these verbal shortcuts in the code, it is simplified as well. The resulting deep model will constantly evolve as our understanding of the domain improves, and our communication about the domain will become more and more precise. In fact, the communication can become so precise that Evans reports an end of the "mystifyingly unexpected requirement changes". The new language used to describe the domain model can be so powerful that it's a selling point for marketing purposes, it's a market differentiator!

The following are points I underlined in the book, but may not make much sense to anyone else:

When we're working on a domain model, name things to reflect intention, rather than implementation. Evans also likes "closure of operations" because they perform operations that bring along no other dependencies (closure means input/output are of the same type).
Evans presents many ways to simplify the domain model, for example:

• by constraining many-to-many associations with a clarifying attribute
• minimizing the number of associations
• making associations uni-directional

If the code is in need of significant refactoring, prioritize by clarifying the core domain first.
He also discusses entity objects, value objects, and services, the last should optimally be an operation that does not fit in either an entity or object, it takes some entity or object as a parameter, and it's stateless.
The Repository pattern is a way to keep caching/data store and retrieval from polluting the domain model. Essentially, the repository objects will act as if they are a permanent in-memory collection of persist-able objects, with even some helper methods for quick retrieval of often-run queries. Repositories are made to retrieve existing objects, while factories create new.

Agile Besançon

So tonight we held the first meeting of what I’m calling Agile Besançon… it builds upon some organizing work that Ludovic, Olivier, and Regis have done in the past—going back as far as the coding parties that Olivier held at his house.  Tonight’s meeting was held in a conference room at Temis Innovation, the incubator for the startup I work for, Smartesting.

Ludovic and I facilitated a discussion on Managing Multiple Projects at Once. Conventional Agile wisdom recommends against multi-tasking, and against running multiple projects with the same team, because task-switching incurs a heavy performance cost.  Still, some teams cannot get their management or their customers to focus—so how can they cope?

We started the meeting with a brief check-in, describing how we hope to have monthly meetings where we can play, practice, and discuss topics/skills that we don’t normally address during our work day.  Then we showed how we planned to use the time for the evening—check-in until 7:15pm, game until 8:15pm, and retrospective until 8:30.  We all introduced ourselves with name, job title, and company affiliation, 11 in total, 3 companies represented. 

Ludovic and I had invented a group exercise to help people warm up to the ideas we’d be presenting—the object of the game was to use an assembly-line of workers to build paper airplanes—15 copies each of 2 different models.  We started with a 5-minute prototype phase—and the Acceptance Test for completion was that the plane had to be able to fly across the room.  After a brief pause, we gave each team (of 4) 5 minutes to build their planes—but they were forced into a Taylorist production model—one person rips out a page from an old magazine, next person puts one fold into the sheet, next two people are plane builders—of the kind of plane they had prototyped.  In 5 minutes each team had built about 6 planes—and we then talked for 5 or 10 minutes about what we noticed.  Then each team had a 5-minute huddle on how to improve the assembly line, followed by another 5 minutes of production.  This time each team produced 16 planes—but one team focused on model A, while the other team built both types.  Only one team noticed a hidden requirement written on the whiteboard—that the customers only pay for completed batches of 15 planes.  Afterwards, we talked about the strategies the teams used to speed up (moving more people to the plane-building role, thanks to Theory of Constraints), and we talked about what might help them reach the goal of selling both plane types.  Someone suggested re-negotiating the batch size requirement—and we said that is an excellent way to deal with multiple projects—that as soon as we can get to small releases (minimally marketable features), it’s not as penalizing to switch off to another project—but to switch before releasing means shelving the unfinished investment and therefore indicates waste.  We followed this discussion with a perfection game on the game itself:

The notes, translated from French, indicate that we should keep the:

• short iterations
• brief reflection after each iteration
• simple materials
• prototype phase

For next time we might consider changing:

• construction targets—different objects, like a boat and plane, or simple folds instead of more precise objects
• don’t run an acceptance test for everything?
• the number of projects (have more than 2), and find a way to get people more actively involved in decision-making/collaborating
• making different objects worth different prices, maybe depending on the construction cost

Points of confusion, open questions:

• what was the overall goal?
• how can we help people be more collaboratively involved?
• deliver airplanes?

We ended the night with a quick Blond-ROTI chart (Return-On-Investment):

   

Translated, on a scale of 1-10, people rated the following:

• Worth it to come to the meeting tonight:  8
• I learned something: 5-8
• I will change something tomorrow: 1-7
• I’m ready to lead a discussion for the next Agile Besak: 2s and 8s
• I’ve encountered this problem: 1s and 9s
• Would it be interesting to have more of us: 8-10
• I will invite someone the next time: 9-10
• I’m ready to come the next time: 10
• There should have been more experience reports [tonight]: 10

Agile Developer Skills Workshop--Day Three

Today is the culmination of the three-day workshop... I think the team has really gelled with a common purpose and shared values. I had to leave early, so will only report on the morning--but stay tuned because soon we'll have something sufficiently well polished that we don't have to hide our candle under a basket.

So, with the caveat that the group may quickly change direction (we're all agile, right?), I'm happy to report on where I think we're going. We'll be creating the Agile Skills Project, an ongoing, open, and not-for-profit entity that will do the following. But first--who is the "we" that follows? Assuming that you're at an experienced practitioner level, it probably includes you:

• create an "agile skills inventory"--a list of skills that are important to being a good agile team member (note, this is not just for coders), a definition of those skills, and even links to existing learning materials (books, web sites, courses, classes) that may help one acquire these skills. These skills will be mapped to the Seven Pillars, and specific ones will be selected as fundamentals that every well-rounded agilist should know


• provide a way for individuals/teams/orgs to self assess against the inventory--this can be an index into where they should focus self improvement efforts, or what kind of help to seek, paid or unpaid.


• recognize progression along the agile skills inventory--the intent here is to celebrate the successes we make in our life-long learning; the risk would be that people could misconstrue this as an endorsement of a particular competency, which it is not. We see several levels of progression through a skill: exposure/awareness, attempted, successful execution, refined execution, advanced the state-of-the-art. From the "successful execution" level and up, there would be third party verification that the skill was indeed performed correctly.


• characterize learning materials--we'll be able to map existing courses, certifications, conference sessions, books, etc. back to how much they cover the agile skills inventory. This will give a nice "nutritional content" to these learning materials, and help people see the objective value these materials provide


• collect experience narratives--at some point, all this work should tie back to the correlation between delivery and skills. This will provide data that correlates successes and failures to how we do the work.


• review experience narratives--With experience narratives, we'll be learning from practitioners in the field, and be able to improve the Agile Sklls Inventory accordingly. As a nice byproduct of experience narratives, we'll have a paper trail of what progress individuals have made in their learning journey.
  

Agile Developer Skills Workshop--Day Two

So imagine an organization, run by the agile community (or a large subset of it--at least the people that have shown a trustworthy commitment), that is in charge of defining the set of skills we find useful in being a member of an Agile Team. This group would be involved in:
-defining an Agile Skills Inventory (e.g., Active Listening, Story Splitting, Test-driven development)
- providing a repository for reference courses
- defining self/peer assessments
- defining a quest ecosystem
- experience reports
- characterization of external courses (for a fee?)
- rating of trainers for a particular course

Well, this is what we're trying to imagine, and here's how we attacked it today--in several sessions. The group asked me to help facilitate (thanks, Pat, it was a great honor! though I'm not sure if I did in fact keep us on task):



We pondered what value this system would produce, so we talked a bit about supply and demand:




Then we talked about the idea of "a quest ecosystem", or points, or merit badges, or achievements, and ultimately thought it could be called tokens. Basically, we'd like to acknowledge the work people do to improve their developer skills:




Then we tried to clarify what this Agile Skills Project would be all about:




Essentially, what we see right now is that the community would own and maintain the ever-evolving definition of agility, then certify training organizations/courses/study material against the standard. To help developers, these 'certifications' would characterize the courses; alternative free methods would also get characterized as well--so then it's up to the developer to take a course or teach oneself.

To further help the community, we'd have a 'token' system, by which team members could go on learning 'quests' or exercises, which would be recorded in a web site as an experience report. This report would be rated by peers and generate points for both the reviewer and reporter. These points would not be fungible, would have no external worth, but could be used to help people categorize their own strengths and weaknesses, to prioritize further learning quests.

One of our group members took some of the initial 7 pillars work (technical excellence, collaboration, product understanding, supportive culture, business value, confidence, continuous self improvement) and made a wordle picture:

Agile Developer Skills Workshop--Day One

Today a group of interested and interesting folk (I'll get a list of the 14 attendees soon) met in Ann Arbor to discuss the Agile Developer Skills idea. We started with a quick outline that I hoped would move us from a group to a team--a list of what motivated us to show up at the meeting, a reality check on what our goals were and if our sphere of influence was sufficient to make it happen, a list of customers, and then a discussion of a business model that could sustain this system.











We soon moved into a mindmap of our various motivations:

























Then we brainstormed on a list of personas that may be our "customers" or stakeholders.

Then we discussed possible goals / to-do items / outcomes of this workshop.

The next steps are to filter the list of proposed outcomes and to review, in detail, potential "generally accepted curricula" that could be used in various courses.

Agile Developer Skills Workshop--Homework

In the wake of announcements from the Scrum Alliance and Microsoft on a "Certified Scrum Developer" program, that would cost around $4-5k per developer, Ron Jeffries and Chet Hendrickson are hosting a discussion on how we, as a community, can support skills development for developers/agile team members. In preparation, I hosted an open space discussion on the topic at Agile Tour Besançon, and a parallel session ran in Agile Tour Philadelphia. The community has long resisted any developer certifications, for many reasons:

• existing schemes don't seem to measure the most important skills
• certificate possession doesn't seem to correlate with skill
• certification has been expensive
• etc.

When I spoke with other developers, the following topics came up:

• how is any test/class going to show if I'm good at my job?
• who is going to pay for the test/class?
• why should the Scrum Alliance or Microsoft or WAQB or any company be able to define agility?
• what happens if people get the cert and I don't?
• etc.

I also had a nice conversation with Laurent Bossavit about the topic. He suggested that at the workshop we ban the word certification--that way we'd have to reveal the motivations for wanting the program at all. He feels like certifications are a replacement for a system of trust--but once money gets thrown in, we need a way to justify the system--a way to explain what people are paying for. One motivation for creating a system would be to show who in the community is worthy of emulation... to show what behaviors are valuable, what practices are effective. In any case, this system should be community owned, democratic, and should value/reward life-long learning, while still fostering innovation towards better ways of developing software.

competing with free products

TestObsessed just Tweeted about how to compete with free products: http://www.businessinsider.com/how-to-compete-with-free-products-2009-9

Short version: beat free with ad-sponsored.

focus on the customer

Thanks to Poppendieck's book Implementing Lean Software Development, from Concept to Cash, I read about google philosophy:

Focus on the user and all else will follow.

Lean demands that we identify what our customer needs, then we deliver just that. She talks about how the Quicken team entered a mature market of complex accounting software, simplified it, and delivered value to their customers. She mentions Google, Dell, Zara--all companies that have risen to success because they have the right focus.

set-based engineering

Since research/design is often very risky, the Toyota Product Development system integrates several processes to manage the risk. They use strict time-boxing, with multiple parallel research tracks trying to succeed, and at the end of the time box they can choose from all successful options. Their lead engineers are responsible for not only technical success, but business success, and their engineers stay on the same team for a long time, and are expected to excel in their craft. The teams, and individuals, are given objectives but are not micromanaged.

Why isn't it waste to design things we won't use? It's because waste has to be regarded in context of the whole system--and failing to deliver an acceptable design is a much bigger waste than optimizing the whole.

Agile 2009 Gordon Pask Awardees

This year's Gordon Pask Award winners were Gus Power, Simon Baker, and David Hussman. Ultimately we'll read more about it at http://www.agilealliance.org/show/1656

genchi-genbutsu

According to Mary & Tom Poppendieck's Implementing Lean Software Development, genchi-genbutsu means "go, see and confirm". I think it's a very powerful image for software development--when we have first-hand experience of what our customer values, we're more likely to understand its essence and to successfully make a minimalist implementation. It also sets up the relationship for us to ask customers directly about design tradeoffs. So, go, see what your customers are really doing, and find a way to make that go more smoothly--but ask them first about your ideas, to make sure you've understood the process.

Poppendieck's version of Shigeo Shingo's seven wastes

The lean community has categorized the following as the seven wastes of software development:

1. Partially Done Work (it delays feedback, thus increasing the risk we didn't catch mistakes; our investment cannot turn a profit if it's undone; we risk falling out-of-synch with other people that continue to work on the previous version)
   
2. Extra Features (this is overproduction and the worst form of waste because it's at the top of the food chain, i.e., it inevitably included all the other forms of waste somewhere in the process of creating the feature)
   
3. Relearning (if we already paid for one developer to discover something, why pay another developer to do the same thing? still, it's very difficult to have a usable system of documentation that explains why we chose what, when)
   
4. Handoffs (tacit knowledge--that which can't easily be explained verbally or on paper--forces the recipient of a handoff to re-do part of what we've done)
   
5. Task Switching (task switching increases the time-to-completion of the most important task on our plate, or causes waste in terms of unfinished work or relearning)
   
6. Delays (when developers have to wait for a customer's opinion, they may guess or pause. Either way, it's waste.)
   
7. Defects (in my opinion, defects may be on par or worse than Extra Features as waste... we've gone through all the work of making a feature, and then have to revisit it, re-test, and re-deploy.)
   

favorite ideas from Poppendieck's Implementing Lean Software Development

When I read paper books, I underline and dog-ear the pages. Then I come back a bit later and blog about what I read--it's a way to reinforce what I got out of the book. Here's a summary of the ideas that most struck me this summer as I read Implementing Lean Software Development, from Concept to Cash by Mary and Tom Poppendieck. Quote-marks indicate direct citations.

• Toyota's productivity is "consistently four times that of its competitors, and quality is twelve times better", says Jeff Sutherland in the forward.

A little history

• The book begins with a 2-page history of the industrial revolution. Starting with the late 18th century French invention to use standard, interchangeable parts for firearms, the US ran with the idea to create mass manufacturing and economies of scale that had never been precedented. Then in the early 20th century Taylor applied the idea to people--making the work of automobile assembly line workers so easy they could be trained in 10 minutes, and therefore be easily replaced. This was in strong divergence with what happened in the loom industry in Japan, where the automated looms required a lot of expertise to maintain and tune--here, individual skill was highly valued and teams were preserved, even as companies were torn down and restarted.
• Just after WWII, the Toyoda family (future creators of Toyota) felt the need to catch up with American mass manufacturing, but they did not have access to the wealth of resources required to benefit from economies of scale. Instead, they aimed for "just-in-time flow", which gave them the advantage of driving down the cost of variety in their products. The Poppendiecks say that this is "the only industrial model we have that effectively manages complexity".

The Manufacturing World

• Jidoka -- autonomation -- "Toyoda automated looms... detected when anything went wrong and shut down automatically". This sets the stage for a "stop the line" mentality, mindfulness, safety and quality.
• When there are mistakes, it's not the worker's fault--it's the process which has room for error. Fix the process so we can't make mistakes.
  
• Plant managers were all expected to spend some time on the line.
• It is the creativity and practical knowledge of the line workers themselves that drives continuous process improvement
• Lean is infectious--Toyota and Dell have extensive supplier networks, and freely exchange information and training to support the supply chain. They define contracts in a way that align the interests of both companies.
• Peter Drucker states that "a company that maintains a single management system throughout the entire value stream will see a 25 to 30 percent cost advantage over competitors"
• BAA built terminal 5 at Heathrow airport with a novel kind of contract, including target cost and a risk/incentive pool. Whenever a subcontract finished, contractors got paid the target cost plus anything that was left over in the incentive pool. This aligned the interests of both parties, and work went more smoothly.
  

How does this apply to product/software development?

• the Toyota Product Development System is designed for "generating and preserving knowledge for future use"
• in product development, it is not waste to explore multiple options/technologies--they call this "set-based concurrent engineering"--these options allow us to evaluate trade-offs appropriately when the time comes to make a decision
• "repeatable and reliable speed is impossible without superb quality"
• the Kano model states that to impress customers, we need to satisfy basic needs, as well solve problems they weren't even aware of
• "behind every great product there is a person with great empathy for the customer, insight into what is possible, and the ability to see what is essential and what is incidental"--Martin Cagan of the Silicon Valley Product Group
• chief engineers at Toyota play a product owner role--they are responsible for the business success of their vehicle family, and they do first-hand research (genchi-genbutsu "go, see and confirm") of their potential customers as well as pay attention to marketing research and dealers
• inspection to prevent defects is necessary; checking to catch defects is waste
• just-in-time decision making is critical to effective risk management. The longer we wait to commit to a particular path, the more we know about our options--but if we wait too long, some options vanish. Establish, up-front, when key decisions need to be made, and then adhere strictly to those timeboxes. See set-based design.
• "above all, team members must be mutually committed to achieving a common purpose"
  

Software development

• "unused features are the worst kind of waste in software development". Justify every feature!
  
• "great software grows out of a mind-meld between a person who really understands the business and a person who really understands the technology"
• simplify--both the product and its implementation
• part of the design must incorporate the concerns of operations staff--people that will support and maintain the application
• seek a "product" funding model, rather than a "project". Products are funded incrementally, evaluated on their return on investment, and are released incrementally. Like landscaping or gardening, custom projects are never done. When a "product" is championed by business leaders, it is more likely to have business value.
• Don't automate a complex process. Simplify the process, then code it.
• When a lot of work needs to happen quickly, we need "self-dispatching" work--that is, remaining work items need to be evident to everyone on the team, and people need to see the overall status of the group
  

Intra-team politics

• a discussion often changes once a "decider" has been selected. Make it clear who that decider will be, and then watch the arguments unfold.
• it's important that proposed changes in a system are done scientifically--so we can evaluate the old against the new (PDCA)
  

Value stream mapping
A value stream represents the work we do starting with a customer order and ending with delivery of that value. The map needs to be detailed enough to uncover problems, but should also abstract sufficiently so we can see the big picture

• long delays indicate queues--we want to get rid of queues because they represent an unfulfilled need, a warehouse of undelivered value that wastes money to sustain, and they inhibit feedback from the customer
  
• process loop-backs indicate churn--if you're re-prioritizing, re-checking, re-designing, re-doing, it's waste!
  

Reducing cycle time

• balance the workload
• minimize the items in process
• minimize the size of work items
• release regularly
• limit work to capacity
• use pull scheduling

Lean capitalizes on everyone's brainpower

• Lean can only be realized when there is true respect for people in the workplace. At Boeing in 1988, the 777 project started with the premise of "working together"--and this fundamental respect for people ended up creating a work environment that shares many attributes with Toyota's lean process.
  
• Deming wrote about how to use people's full potential in the workplace: "appreciation for a system (synergy of parts), knowledge about variation (problems come from the system itself), theory of knowledge (Plan Do Check Act), psychology (skill, pride, expertise, confidence, cooperation)".
  
• Also see Deming's 14 points to increase quality.
• Deming said that a company's purpose is to create products that please the customer so much that they'll keep buying more products--that is, to make a sustainable system, focused on long-term relationships
• In a lean organization, problems aren't recurrent--they aren't systematic--because as soon as a problem is detected as systematic, the system is changed
• "standards are viewed as the current best way to do a job, so they are always followed"--anyone who finds a better way is expected to change the standard documentation
• 
  

industrial tourism

A mentor of mine once said that insanity comes from isolation--that without close connections to people outside ourselves, we miss out on reality checks, and start doing things that are crazy, just because in our particular situation it seems to make sense. I think this insanity arises at both a personal and group level. I think the companies that encourage employees to reach out and network with other professionals end up finding more ideas and integrating more successful ways of working.

One means of networking I hadn't heard of before I came to France was first introduced to me by my colleague, Olivier--"tourisme industriel", or industrial tourism, a year ago, as a way to accelerate learning and improve the team's experience. Just this past week we had two "tourists" come in to observe our dev team--and while they didn't have a lot of experience with Agility, it was refreshing to have a new pair of eyes on our process--their questions came much more freely than an intern's or a new team member's, I believe, since they weren't expected to integrate these practices--they were simply here to find out if it made sense for them. I'd be really interested in trying this back in the States on a long-term basis, but the companies I'm familiar with would likely be too concerned about intellectual property to try it. Because of the questions from the tourists, we took a few minutes yesterday to do a special retrospective on whether we should change anything in our process. The tourists noticed that our connection with the XP client was excellent, that our adhesion to the Pomodoro breaks was lacking, and that the idea of deploying to prod was valuable.... Well, no changes came out of this retrospective--we're going to just keep going with our half-hearted Pomodoros, because we think it makes sense in our particular situation ;)

the coach's customer

Naresh Jain just sent out a pointer to this Business Efficacy eBook, and its 14 pages are well worth the read. The main take-home messages for me are:

• In every coaching opportunity, find ways to deliver value to the recipient--otherwise, your changes will not stick around for long. As a coach, I'm constantly asking people around me to leave their comfort zone, to do things I believe are possible, but they don't. But if I can find their currency, this change will be something they value.
  
• Each individual has different motivators, of course! Each person has different ways they like to be acknowledged. Tailor your interactions!
  
• Timing is everything--we're shooting for specific goals and we need to reinforce good behaviors; the amount of effort or time we put in to this isn't important, it's the results!
  
• The coach needs to stay focused until the recipient has made the new practice a habit, and will create opportunities to practice if necessary!
  
• The coach needs to provide clear expectations.
• We don't care about volume, breadth, utilization, effort, or percent done. We are focussed on a narrowly defined objective.
• A coach encourages learning by asking questions more often than lecturing. Often the difficulty is in applying what we've learned to our daily habits. Ask the team/individuals about what's going on, or how principles might apply to specific behavior.

To capture this all in one phrase, I'd say the coach needs to help teammates succeed, in their own individual definition of success.

Pomodoro Technique Illustrated by Staffan Nötenberg

In addition to Francesco Cirillo's book on the subject, Staffan Nötenberg adds experience and supporting research in the Pomodoro Technique Illustrated. Here are my favorite ideas:

• Procrastination, forgetfulness, and being overwhelmed in our lives can be replaced by energized work
• Our brains have a lot of natural rhythms and tendencies. There's a reason why sports stars have quirky game-day habits. Let's capitalize on our brain's natural strengths!
• Follow a ritual for winding up the Pomodoro... it frees your mind for more important things. Capitalize on building good habits!
  
• Our brains are not good at task switching, because we have limited "working memory"
• Our brains are very good at finding associations. Many memory techniques teach us how to build those associations.
• There are two ways to understand time: sequential vs duration. Sequential is more intuitive for children, and is less anxiety-prone for us adults
• To get into flow, it's helpful to have the right environment: clear goals, sufficient challenge/interest, alertness, immediate feedback, and the sense of control.
• Analysis paralysis is a symptom of having too many choices. If we limit our task selection to the beginning of each pomodoro, we don't lose time constantly rehashing what to do next.
• The difference between a to-do item on an Activity Inventory and what's on the Today list is commitment. Maybe other people assign items for our to-do list, but when we do Pomodoro, it's our choice to schedule things for Today, and it's our goal to get those items done...and our satisfaction to succeed. It's critical that the commitment is realistic!
  
• Each Pomodoro day has the following stages: planning, tracking (something, each pomodoro), recording (consolidate to Records Sheet), processing (analyze the data), visualizing (retrospective).
• The key to memory is rehearsal. If you want to remember something, review it now, a day later, a week later, a month later, and then again 3 months later. This will strengthen the neural pathways so the info is easy to reach. As part of Staffan's daily retrospective, he draws a mind map of what he learned during his primary task of the day.
• There's something about commitment that adds fire to our work. Use this catalyst by planning the day with a Today list, and use a Now List at the beginning of each Pomodoro to keep focused.
  
• The daily retrospective is important to keep us learning.
• Interruptions occur. Negotiate to keep them from interrupting your flow. If it's really urgent, you'll have to void your pomodoro. If you do anything that is not on to your "Now List", the Pomodoro is void (unless it didn't interrupt your flow and it took less than 10 seconds).
• External Interruption Negotiation--inform the other party you're in the middle of a pomodoro, and will be done in X minutes; ask if you can get back to them then; add it to your Today list or Activity Inventory
• Tracking: Staffan records interruptions (' for internal, - for external), unplanned items (U), estimation error (boxes for initial estimate, circles for re-estimates, and triangles for 2nd re-estimates)
  

Breaks

• At a minimum, each break begins with getting away from the active task--i.e., standing up from my desk!
• Giving ourselves regular breaks brings multiple benefits: ability to reprioritizate tasks, tendency to view the larger context and discover new associations, and clear delineation between work and rest.
• Flow is incompatible with a perspective of the big picture. So we need something to wake us up, regularly, to ensure we're still on the right track.
• Much of the discipline in Pomodoro is about setting up artificial rewards... I get a 5-min break if I work for 25, I get an X on my sheet if I don't get distracted, etc.
• Short breaks give our brains a pause from a bombardment of stimulus. Get away from machines and texts! Otherwise you're likely to develop "attention deficit trait"--i.e., you're stealing focus away from the next pomodoro.
• Breaks are critical to get us out of flow-mind, and allow us to switch to overview mind--where we're capable of making changes to priority/schedule/plans. It may be hard to be disciplined to stop when the bell goes off, but if instead we realize this is a wake-up call, it's no longer something being imposed upon us... it's our choice to be able to reevaluate where we should be going
  

Pomodoro for teams

So our XP team has been using some twist of the Pomodoro technique for about a month now. I actually haven't found anything significant about using Pomodoros in a team, so I'm going to share what we're doing, and what problems we're having, to see if you have any ideas.

We use "one pomodoro to rule them all", which means one timer for the whole team. I've read this is an anti-pattern, but I don't see a compelling reason to use more than one pomodoro. We see a lot of advantages in having one pomodoro... everyone has a pause at the same time, so pair swapping is easier, team meetings are easier, etc. If someone's pomodoro is interrupted, someone decides not to participate in this pomodoro ("check-out"), they just wait until the next pomodoro starts to rejoin the synchronized timer. As a team, it seems like we're happy to use Pomodoros--our team communication is up, our productivity, our focus, our check-in/out is all better.

Our biggest problem with Pomodoro right now is in sticking to the 25 minute window--when the timer rings, inevitably someone stops, but most of the team keeps working for another 2 or 4 or 5 minutes. When the 5-minute pause is over, 3 or 4 people approach the story board and start goading others into joining them. This can easily make a 5 minute pause take 10 minutes, at which point we have a mini-standup meeting to verify that we're not blocked or overbudget on any story cards, that we're progressing well, and to verify no one needs extra help.

We've talked, as a team, about why people aren't taking breaks, why people are late to show up after the break, etc. Maybe this pain is why it's considered bad form to use "one pomodoro to rule them all". If we keep just one timer, though, what else could we do to fix our tardiness?

call for nominations--Agile Alliance's Gordon Pask Award

The Gordon Pask Award

The Gordon Pask Award recognizes two people whose recent contributions to Agile Practice make them, in the opinion of the award committee, people others in the field should emulate. In order that people might emulate them, the Agile Alliance will fund each recipient's travel to two different suitable conferences on two different continents. In order to grow the next generation of Agile thought leaders, we give the award to people who have not yet become conference speaking regulars, in part because they have not yet developed a widespread reputation as a top practitioner.

Who is Your Mentor?

We need your help to identify the next two Gordon Pask Award winners. Please send your nominations to pask-nominations@agilealliance.org, including the nominee's name, email address and a short summary of your reasons for making the nomination, limited to 200 words.

In the spirit of Gordon Pask's work (see below), we expect you to nominate someone you've learned from directly, face-to-face. You might also consider asking for additional people to add their names to your nomination. More names don't necessarily carry more weight, but they do give us more people to ask about the nominee. Previous winners can be found at the Agile Alliance's site http://www.agilealliance.org/show/1656. Award founder Brian Marick comments that the selection process is always difficult: "We always worried a lot that it would feel arbitrary... I’ve gotten complaints that it’s too much of a programming award and not enough of a management award and that could well be true." There are always many qualified nominees, who are ruled out when the committee asks “Does this person actually need our help?”

We will accept nominations until August 1, 2009.

About the Gordon Pask Award

Laurent Bossavit, a 2006 recipient, says "one of the more appealing traits of the agile community [is] that it provides room for new voices to be heard and to offer original contributions". This is a community that fully embraces the notion that through face-to-face conversation comes enhanced understanding... a community that believes that thoughtful critics and new enthusiasts alike have something to offer. This emphasis on discourse is partially inspired by the work of Gordon Pask and other cyberneticians, who practically "had no effect. Eventually they retired, or died, and that was kind of the end of it. The first wave of people failed to build up the next wave," according to Brian Marick. The Agile Alliance's support of this award shows a strong commitment to nurture growth and discovery in the agile arena, and to further emphasize its significance, currently it is the "only award that the Agile community gives," says James Shore (2005 recipient).

Agility is a Social Phenomenon

This is a community of artisans, constantly trying to hone their skills by taking notes from one another. Bossavit says "I benefited a lot from the writings of the 'official' founders of Agile, many of them among the original signatories of the Manifesto... [but I] couldn't have learned about XP, Scrum and all that solely from reading books or articles. Rather, my understanding grew from the opportunity to participate, interactively, in several communities. These included on-line communities such as Ward Cunningham's Wiki and the XP mailing list, and real-life gatherings such as the european XP200x conference, the various XP Days, and so on. I have a huge debt to Jerry Weinberg... for fostering a community of people passionate about 'peopleware', about the human, sociological, psychological aspects of software."

Agilists are finding better ways to work, to learn, and to teach. 2005 recipient James Shore says he learns by "trying things and seeing if they work", but that's not all. He gained a lot of insight by working with his local Agile User's group. He says, "I'd bring in my problems and we’d talk about them and I’d say, 'That can’t possibly work' and I would go away and try it and come back and say, 'Well, you know… that worked. Here’s what I did and now here’s the new problem I’m having,' [something] I wish more people would do." Regarding learning by doing, he goes on to say that, "training some times works... you can pick this stuff up from books... [but] following a leader who has done it before; having them work with you directly is by far the most effective way of getting it in to place quickly". Instead of training sessions in lecture format, 2005 winner J.B. Rainsberger says that he "tells people stories... which helps them understand". If you go to any of the agile conferences, you'll find games, workshops, debates, and other engaging, interactive formats focused on improving communication. Not only are the user groups and conferences lively. "Agile is bringing back the freedom, creativity and innovation back to software development. It is making life easy and enjoyable for software craftsmen. And I'm glad to be a part of such a movement," says 2007 winner Naresh Jain.

Gordon Pask--Improved Understanding through Discourse

The Gordon Pask Award embeds a special message for the Agile Community. "Lots of big names are projecting a very dogmatic and rigid view about Agile. In my experience Agile is nothing on those lines," says Naresh Jain. The problem with mass-broadcasts from "big names", from a Gordon Pask perspective, is that we lose out on the collaborative learning. It's not to say that a rigid view of Agility is incorrect. James Shore says: "we can’t just say we won’t do that piece of Agile. [Instead of asking] "How are we going to solve that problem in a different way?", I see people saying, 'That’s hard. We’re just not going to worry about that piece of it.'" He clarifies that newcomers would be "better served by... seeking excellence than trying to fit in." Trying to fit in by following the letter of the law will not give us the gains in productivity promised by Agile. "The big wins are not in doing work in two-week Sprints. The big wins are increasing your communication, working simultaneously, because simultaneous phases are also a way of improving that communication so that you don’t have a throw-it-over-the-wall mentality."

Kent Beck talks about self-similarity in nature--that is, design patterns that work well, often are replicated in various sizes and environments. The fact that communication helps us improve our effectiveness on the job, as well as in the Agile community, is a self-similar pattern mastered by award recipient Kenji Hiranabe. He says that it was not he who won the award in 2008, but it was the strength of the community in Japan that brought the award to him. This obvious valuing of community before self is also repeated in their conference marketing: "we prepared 'Pair discount' pricing and strongly recommended the attendees to come with their boss or clients. The result was 75% of them came in pairs! I believe it is a sign that engineers, managers, and clients have started talking to one another to make this software development world better... Along the way of introducing Agile to Japan, they came and formed a good community."

Now it's your turn. Nominate someone that has helped you out... better yet, collaborate with a few colleagues, face to face, to discover who to nominate. It takes less time than reading this article!

Drexler-Sibbet Team Performance Model

Thanks to George Dinwiddie for the pointer to this image (actually, I don't know the etiquette here in terms of referencing an image from another site...), but anyway, this model can help a team gell.  Read more at George's blog.

software has no intrinsic value

After Kent Beck's musings on how to find paying customers for his work on JUnitMax, and on capital efficiency, I started wondering, well, if we won't buy from Beck, who will we buy from? Maybe no one--in fact, recently, I've stopped buying software. It comes embedded in the gadgets I buy, or it comes OEM with my new PC, or is available on a free CD that accompanied a gadget I just paid for. Even with all this "free" software, the first thing I do with a new toy is try to make it work with my computer without installing any of the bundled software at all... and speaking of minimizing my need for software--the first thing I do with a new PC is uninstall as much as I can get away with. Why do I uninstall? To me, each unused application is waste, risk, in short, rubbish--so I clean up aggressively. It's not that I don't have any software at all. Every once in a while I do need software that wasn't given to me, so I'll evaluate a few freebies online, and ultimately choose some product that does the job well enough.

Note the change in focus here--I'm talking about getting a job done. There's no intrinsic value in the software itself--but there is potential to accomplish a task, and therein lies its value. Yet it's rare that my needs correspond exactly with the software's behavior. So if it doesn't do exactly what I need, and there's a free one that is just about as inadequate, why not go for the free option?

I'm not alone. The prevalence of free web software (from list serves to social networking to banking), plus the thousands of open and closed source software products that are available free download, suggest that there may not be much time left for people that are still trying to sell their software.

Now for the irony--I've been paid for years as a 'software developer' for in-house applications, and there are lots of other workers getting paid to contribute to free software. Where's the money coming from? Where's the value? As I've already said, it's not the software. The value comes from getting the job done better. The less software involved, the better (per James Shore's spag code debt model). I think, then, my job isn't to write software. My job is to solve business problems... to figure out what the business really needs, to deliver value, with as little technology/effort as possible.

Greiner Curve--organizational growth challenges

As organizations grow, they need different kinds of leadership. The Greiner Curve can help you anticipate these changes:

Growth through creativity --> leadership crisis (small team, informal leadership)
Growth trhough direction --> autonomy crisis (single level of management)
Growth through delegation --> control crisis (middle managers)
Growth through coordination --> red tape crisis (executive managers)
Growth through collaboration --> growth crisis (matrix organizations, partnerships with internal groups)
Growth through alliances

Porter's Five Forces

Another interesting idea from MindTools.com:

In business, power comes from these five forces.

Supplier power: more suppliers, less power for each one
Threat of new entry: if it's a profitable business, someone is likely to jump in to compete
Buyer power: big buyers can dictate terms (think Wallmart forcing Coke to give them a discount 10% lower than any other buyer, or Amazon taking 70% of newspaper revenues)
Threat of substitution: if there's another way to meet the customer need, maybe the customer will use that solution instead
Competitive rivalry: competitors tend to drive down the price to the "marginal cost of production"

Geert Hofstede cultural dimensions

While stereotyping can be misleading, sometimes it's practical. I just learned about Geert Hofstede's cultural dimensions study, started in the 1970s, where he categorized different cultural values. I was surprised, for instance, to see that the French have a lower rating for gender roles than Americans, but then again, my house is in the Mount Airy section of Philadelphia, a progressive haven that is not at all typical of the U.S. Still, this study rates dozens of countries along four or five axes, and may help us understand what is more valuable to people in different cultures:

PD: hierarchal vs cooperative leadership/power
IDV: individual vs community
MAS: clear, different gender roles vs gender equality
UAI: avoid uncertainty, like formal structure vs informal and tolerant of risk
LTO: long-term orientation, value family and education vs valuing shorter feedback and innovation

capitalize on learning styles to communicate effectively

When you're planning a meeting, retrospective, discussion, or training session, try to incorporate activities for each topic that cater to people that learn in different ways. While there may not be a scientific basis for the following categories, considering them can make your presentation more likely to engage more of the audience. The following are the Felder/Silverman learning style axes:

Sensory    <-->  Intuitive
Visual     <-->  Verbal
Active     <-->  Reflective
Sequential <-->  Global

These learning styles show a preference for:
Sensory: feeling/detail
Intuitive: theory
Visual: pictures
Verbal: words
Active: experiments
Reflective: plan
Sequential: details or steps used to build the big picture
Global: use the big picture to figure out where the steps should fit

Key characteristics of a performing team

Thanks to Gary Derbier for this concise summary... a performing team has these characteristics:

• everyone takes care of themselves
• everyone fully connects with each other
• everyone unanimously agrees on one objective and how to achieve it... this unanimous agreement should be so strong that every member of the team believes that this objective is the best real option, right now for reaching both our individual and group goals
  
• everyone expects that perfecting the team will perfect the product
  

Once a person has been part of a performing team, it is hard to enjoy team work without it.

Herzberg Motivation-Hygiene Theory

Today I read a bit about the the Herzberg Motivation-Hygiene Theory, which in a nutshell, expresses that there are two levels of needs for employees. If we want people to stick around, we have to prevent job dissatisfaction by meeting:

• their basic needs (keep the work environment sane, fair, with competitive benefits)
  
• their motivational needs (job satisfaction comes from challenge, recognition, autonomy, interesting work, and room for growth)

I used to say that a good manager does two things: gives employees autonomy (read: room to make mistakes), and challenges employees to grow. I'm finding out there are some prerequisites to this, and am trying to learn how to verbalize them.

deleting your way to success

Every once in a while, we get a story card that allows us to simplify a requirement or interface, and we get to "delete our way to success"... that is, we end up removing more code than we add, and maybe we don't end up adding any code at all. Today that's what my pair and I did for the first half of our card, and it's so liberating. We don't need to think much about code rot, tests, or any of it... just remove and verify we didn't break something else. Quick win!!!
Thanks to my colleague from Philly, Nolan, for coining this phrase!

effective delegation

Esther Derby's when to stand back, when to step in touches upon delegation. I'd like to comment on that, by merging some of what www.mindtools.com had to say about it. When we delegate, it's necessary to:

• describe the need/ultimate goal
• encourage sign-up for responsibility
• define authority depending on skills, how critical success is, and whether there's room to clean up any mistakes--should this person act independently, review plans with you, or review intermediate outputs before proceeding?
• once you've given out authority, you must hold back, even if mistakes are about to be made... being given the room to make mistakes is how we learn
  

my favorite lines from Derby/Larsen's Agile Retrospectives

A retrospective needs to happen in several phases:

• setting the stage (why are we here, time line, and check-in)
• data collection (put all the facts in front of the whole team)
• interpretation (as a group, look for patterns)
  
• decisions (propose options, then decide on what can be done by whom, when, and define acceptance criteria for the work)
  
• closure (ensure tasks have been assigned, thank participants)

The authors have lots of hints on how to facilitate group discussion (now we'll see if I can do all this in French):

• ask the group to build working agreements, and then just remind them to follow their own rules when necessary
• at every meeting, get every person to speak in the first 5 minutes
• check your assumptions... ask people what they think! pose clarifying questions to make sure you understand!
• to help everyone have a voice, incorporate small group work in the meeting
• retrospectives are for creative thinking--so do use innovative meeting formats
• when the facilitator speaks, this often stops group discussion
• when the group is stuck, ask them questions, e.g. about when they saw a similar problem in the past
  
• when things get heated, try asking "what is going on?/what just happened?"
• use a change in venue when the team bombs an iteration

They also present lots of group exercises, that I won't repeat here... I keep the book handy for retrospective preparation. These are a few general hints for leading group activities:

• most people can't absorb multi-step instructions
• debrief every activity
• after giving instructions, ask for questions
• shuffle time--it takes a few minutes every time we switch tasks in a meeting to get everyone on board with the next meeting--it could be 15 percent of the time!

tour de témis (taay-mees)

To promote shared vision in a team, to anticipate or ease over problems, and to help individuals deal with stress, I set a goal to spend at least 10 minutes in conversation with each team member every week. In practice, sometimes I only average 5 minutes, but I start out with something like the following.

Hey, Joe, wanna take a tour de témis? Joe may not be available, but if so, we step out of the team room and find somewhere quiet--outside or inside depending on the weather and mood. Then I'll ask one of the following questions, and record responses on an index card:

What are the strong points/weak points in the team?
What do you think about how we've been using timeboxing for meetings this week?
What will you do next week to help us finish the iteration by Thursday afternoon (instead of our normal Friday)? Do you think it's a good idea to finish early?

Then I use Appreciative Inquiry to dig deeper into what is going on with each team member.

story observer

The "story observer" role is something new to me--maybe only exists in my current team--but anyway, at least once a day this person walks around the room to remind pairs to consider whether they're blocked, ensures they're clear about the goal of the end-user, and asks whether they're still in scope of the story card. This observer, I suspect, is not necessary in a gelled/disciplined team, but in the early stages of forming, I think it can be helpful.

fixed-cost vs fixed-scope stories

When I first joined my current team, the team culture was that a story card's scope was non-negotiable. In accordance with the classic tradeoff triangle (scope-time-cost), that means they were constantly exceeding the story card estimates. I slowly distinguished between two types of ways of looking at a card, and I learned something in the process.

Fixed-scope: We understand the end-user's need, and we'll spend however much time it takes to meet that need. In this case, we value a well thought-out solution over feedback--so we should choose this only when end-user needs are well understood. The end-result of this process is a story card that is done-done, and the subject will likely not be revisited.

Fixed-cost: We understand the end-user's need, but the schedule is more important than functionality. We'll cut out features, robustness, or complexity so that we can deliver something that at least partially satisfies the end-user's need. As a by-product of this process, we'll write new story cards for everything that we temporarily cast aside. In this case, we value timely feedback from the timebox over completeness--so we should choose this option when we're unsure of the best solution or when doing research.

Pomodoro your way through Tuckman's FSNP model

As I mentioned previously, Agile can't be done without a performing team (Tuckman's Forming, Storming, Norming and Performing model), and I think this explains why I've been having so much difficulty getting our team to be more productive. We're more a loosely-coupled group of two-and-three person teams, each with different work styles and objectives. I've been working on bringing us together for 8 months now, and I've tried a few things. To clarify, when I say I, it really does mean we. That is, usually when I see something I don't understand, I go to another team member to find out if I'm the only one who saw it or not, and to find out if it's a problem. Often I work directly with my manager (Olivier) to get a feeling of the value/impact of the problem. Other times I work through the team, by asking the group a question during stand-up or a retrospective, or by speaking to people individually. Through this process, my original take on the situation is inevitably enhanced, and ultimately we build a new vision on how some of our work will be done.
The first thing I tried was to use retrospectives to find real pain points in the team... but not everyone agreed on what the highest priority items were. Then I tried using positive reinforcement of goals that I'd chosen. I wish I could say we chose these goals but there was no common consensus, so these goals were usually the collaborative output of Olivier and I, or the output of several team members... but for simplicity's sake I'm saying that I worked for the following. Please note that most of these changes were introduced to the team one at a time, and allowed to become habitual before moving on to the next item:

• more pair-swapping
• shorter story cards
• avoidance of black holes
• lighter-weight story card estimation
• emphasis on TDD rather than Test-After
• up-front face-to-face discussion with the client for every story card
• introduction of fixed-cost story cards
• focus on fewer changes so we can do those few well
• Agile Thought of the Day

None of this really created a gelled team, in fact much of it was probably just a distraction from our real problem (at least from my current perspective). It probably wasn't a waste, since these changes have become a valued part of our daily work, and have also helped to establish a level of trust in the work I'm doing. Still, this more effective group work didn't translate into a performing team. Why?
I felt like if I could get everyone to see and focus on one single problem simultaneously, that would become the shared vision that defines a performing team. I concluded that I needed to construct an unambiguous definition of success... which, again, I pushed for. I believe it would have been more effective to have the team define this success, but I couldn't get the group to agree on one goal. So, I said that an iteration was not a success if we hadn't moved all the story cards over to the DONE column by the end of the iteration. I shared this vision consistently and regularly at stand-ups, my turn as story-observer, at retrospectives, and with my pair. Slowly the team adopted this vision... slowly means it took 10 weeks! Since then, however, there's been clear consensus on whether an iteration is done or not... yet that didn't make a gelled, performing team! Now what?
I needed more information, more ideas. So I started doing one-on-one interviews with every person (12 total) in the team, every week. That's been effective at understanding how people feel, and in making other types of changes (like finishing our iteration before 8pm Friday nights... now we're done Thursday afternoon or Friday morning). So with these interviews, I discovered I wasn't alone in feeling like we weren't a gelled team... people wanted closer cooperation, stronger teamwork, but we just didn't know how to get there.
As I said before, XP Day France was a great opportunity for me. I now know we need to get through forming, and I figured that if I shorten the cadence, we'd learn quicker, we'd have more pressure, and communicate more... all setting up fertile ground for team forming and agile growth. So I suggested we try the Pomodoro technique (as a team) last Thursday. Afterwards, we decided that the practice was too complicated to evaluate in just one day, and Olivier decided we should try it for an iteration. Well, that iteration began this Monday, and few people actually read the free 40-page book (hooray--some people are giving it an honest shot), but for the rest I've been using the first long pause of the day to explain the practice in more detail.
Everyone uses the same, 25 minute timebox. After each pomodoro, we pause, then have a mini-standup, where the sole objective is to find out how the team is going to attack the remaining story cards. If someone is blocked, we might send help to that pair; if someone has something interesting to share, they do; otherwise, we may resume the task we were on before. The object is to efficiently select the most important tasks that remain.

The breaks are ad-hoc, and may involve a team-building game, drawing on the white board, or a walk outside. This has become self-organizing already--different people propose games or set up the timers. Just to note, we play games that stimulate the creative, left-brain, so that when people go to sit back down they're more likely to see creative alternatives in the new pomodoro.

On a larger scale, the objective is to add so much discipline that we start to storm.

I'm hoping that before this month is over, our team will just be able to sense when a pair goes dark, will know when to swap pairs, will know how to focus on the core need inside a story, and will hum like a hive, producing a continuous flow of honey (err, business value).

Alan Cooper's Keynote speech at Agile 2008

I've just been reading Cooper's keynote address from Agile 2008, and have found several interesting insights. First, he argues that we shouldn't be iterative in the implementation stages of software development... we should be only incremental. I see the waste of being iterative at the implementation level, but I don't know how to validate software reliably without deploying to the customer... but that is where he says Interaction Designers come in. They know how to reliably define the customer needs, how to interpret discussions, and then to translate them into what the developers can understand. Hmmm...



Then he starts talking about some of their training, training I know I don't have. Interaction Designers learn about common reasoning flaws, like (the following is paraphrased from Cooper's slides 82 and 83):

• Loss Aversion


• Value Attribution (initial perception counts more than contradictory evidence later)


• Commitment Bias


• Pygmalion Effect (self-fulfilling prophecies)


• Tyranny of small decisions (too much choice is paralyzing)


• Evolutionary Psychology (we're not machines, and don't always act logically)


• Abilene Syndrome (groups make choices that no one in the group even wanted)


• Memory Distortion (bad things are easier to recall)


• Hawthorn effect (just paying attention to people improves their performance)


• Stockholm syndrome (hostages fall in love with captors)

Interaction designers are designed to distill "requirements" into a clear definition of business need. I can identify with this idea, as I've heard of teams that thrash from one set of whimsical story cards to the next. When I worked in Philly, we had a product owner who was also visionary, who strongly defended the vision against customer requests that were inconsistent with this vision. At my current position we've been saying that we need that vision to be more effective, but no one is playing the role.

Next he argues strongly for prototyping. He says a prototype is necessary for validating the design... and it should be built in a very agile, lean fashion. Then once it's done, rebuild the whole thing from the ground up... I thought that refactoring was supposed to avoid rebuilding to such a large extent. There's a lot to think about here.

before you can do Agile

Before you can do agile with a team, you need a team! At XP Day France last week, a colleague and I started talking shop with Yves Hanouille, who re-introduced Tuckman's model of team growth to us. I've been frustrated for a while, trying to figure out how to get us to follow our own rules, and even suggested throwing out all the rules and starting over. Now I think we need to get through Storming before any of these rules have meaning... You can probably find better info online, but these notes will help me remember the key goals of each phase :

Forming: agree on goals/vision as described by leader (team lead is directive at this stage). Members hold back their own opinions in order to be polite, they mostly work independently on tasks.

Storming: (directive leader) there's a lot of competition for ideas, the team begins to select a leadership model, and roles are clarified

Norming: (collaborative leader) members compensate for each other, agree on rules/standards, and hold each other accountable

Performing: (collaborative leader) interdependent individuals with established conflict resolution mechanisms.

A group in N or P will fall back to S under stress, in which case the team lead will need to be directive again.


So I think a team needs to be at either N or P to do agile. It's possible that at F or S the directive leader of the group will impose an agile process... but it won't be self-organizing!