Xp Agile Universe Oh Four

We are interested in bullet-point rundowns of the activities, including tutorials and workshops. Leaders, please let your attendees describe your session. This is not meant to be a reproduction of the proceedings.

We are especially interested in anything powerful or surprising that you learned along the way. Was there something unexpected in a tutorial or workshop that caught your attention and has stuck with you?

Thanks!

• Kids can build a treehouse together, so we don't need to "learn" teamwork skills
• Technical expertise is the least important predictor of team effectiveness
• Personal responsibility is a learned mental process
• "If I'm on a bad team, was it bad before I got here?"
• Personal learning only occurs when acting with responsibility
• You don't "have" to do anything, so say "I want to do...."
• You cannot move others along the path to responsibility, so focus on yourself.

• Reaching the tipping point requires crossing the chasm
• We need desperate pragmatists to buy our services, so they can be the reference accounts for other pragmatists
• There is no correlation between IT investment and productivity improvement (McKinsey)
• We need to take a Whole Product approach
• Focus on competitive industries when competition drives productivity improvement
• Make sure the customer succeeds - it's not enough simply to deliver our service
• The XP Bill of Rights could be interpreted to relieve developers of their responsibility for overall success!
• MakeChaosTheCompetition, AND NOT WATERFALL!

• Kepler did the work to justify Copernicus' theories
• In order to sell to skeptics, we need to be skeptics
• Look for evidence of the value of XP, rather than spouting the party line
• Does Agile work? An unqualified "yes" or "no" has no meaning; so qualify your answer
• Negative evidence incidates that we're not yet selling the Whole Product (as describe in Crossing the Chasm)

• Keynotes are about themes, and not about bowing down to God-like figures
• Although XP may not have crossed the chasm, TDD has done so: it is taught it schools, and "second wave" books (like JUnit Recipes) discuss TDD without the sales pitch
• Customers don't just want features, they want a cohesive set of features that makes a product
• Problems exist in those regions of the software where we have not put attention on that cohesiveness
• Customers choose business value over avoiding business loss, and testers are good at avoiding business loss due to software failure
• Specification by example, or example-driven design, drives out the "obvious" business rules that a real practitioner might think is not worth mentioning, but is nevertheless important!
• "We have trained people not to report bugs, because there is no point."
• The foundations of testing skill are independence of thought, critical thinking and seeking error; but these are often turned into lack of involvement, cynicism and removing flaws (rather than emphasizing the good and suggesting improvement)
• Testers are not trained to suggest improvements, as the bug report forms don't encourage it
• Should testers play the role of product managers?

• We have three to four decades of evidence supporting Agile methods!
• Historically, every discipline starts with the wrong paradigm (such as medicine and bloodletting)
• A new paradigm starts to take hold when the old school dies out (literally!), so expect to fight the good fight every day of your life!
• New product development has a profile of high requirements change, and we have evidence that software is new product development, rather than manufacturing/engineering
• Winston Royce's 1970 Waterfall paper is an essay, and so contains personal views and opinions, and not evidence
• The Mercury project (1961) came close to being an XP project
• Marketing teams in the drug industry don't expect a drug for leukemia by 2Q05, like software marketing teams do
• If you want a project to fail, simply make it last three years - no such project appears ever to have succeeded
• The greatest ROI comes from investing in skill

• XP teams seem not to care about models, but as they require communication, modeling happens
• Understanding the domain is the most critical complexity on a project
• Not all models are UML diagrams, although diagrams communicate something about the model
• Deeper understanding of the model fills in the gaps between features to create a full system
• Models not reflected in code are irrelevant
• We should continually refine models, looking to make implicit concepts explicit
• Somehow we turn "We want to express models without losing ourselves in the details" into "We want tools that allow smart people to farm out work to the rest of the group"
• We want to raise the level of abstraction in programming, and not create executable UML
• Writing a test is expressing a model

• We need to understand our client's sales cycle and plug into it, so we should build project communities that include sales and marketing
• We need to improve our negotiation skills
• Executes live by commitment and we need to understand that
• We need to understand what motivates executives (so we should speak to them!)
• Executives need to understand how we manage risk, and they need to see the positive side of risk
• We should tailor our message to our client, and get the negatives out quickly (Stephan Schiffman, _Make it Happen Before Lunch_)
• We need to listen, especially when it comes to others expressing fear
• We should explain technical benefits by analogy
• Know your sphere of influence, and include project sponsors (VPs), programmers and operations (if the rollout sucks, then the project is a failure)
• It is important to ask the question, What do you get out of this?
• Our message: Agile faces reality; Agile identifies risks; Agile provides an escape route by failing early
• Unfortunately, our message includes the notion that we don't commit to an up-front plan, so we must focus on the commitments we do make
• When requirements change is lower, push the technical benefits (lower defects) rather than the customer practices
• Q: Is open space a reference for pragmatists? A: No, because they are mostly development tools!

The conference seemed very high energy and very healthy to me. Better than last year's, and in my opinion better than ADC as well. Surely a lot of credit goes to the many people who worked to make the venue good and to create events for people to participate in. But events don't make a conference. Even the receptions and parties don't make a conference. It's the attendees and the way they interact.

Some of that interaction surely came from the interesting keynotes and talks, but I think a lot of it probably came from the spirit of the attendees, which was probably a bit happier and healthier this year compared to last.

Here are some reactions to the talk descriptions above.

Avery's talk was good, in my opinion, but not suitable for a keynote. It's worth it for everyone to hear the ideas, surely, but it didn't have the inspiring upward-looking aspects that a great keynote would have.

Mary's talk, on the other hand, was full of energy and pointing to our future. I do have a different take on the issues she raised:

• I'm not sure that we should be selling Agile at all, and I'll be talking about that elsewhere. I agree that Agile hasn't crossed the chasm, and that we need to make sure that it does. The Whole Product notion is a strong one. In terms of practical work, we can look to Josh Kerievsky's Industrial XP, for one set of starting ideas.

• I'll have to review the bills of rights, but no doubt they can be misinterpreted. As it turns out, everything we say can be misinterpreted, and surely will be. There is no intention as far as I know that programmers' responsibility -- or should we better say interest, or influence -- should not extend to the overall product. On the other hand, in their current situation, their authority does not often extend far enough to make assigning any responsibility appropriate.

• Chaos is surely an enemy. However, many teams that are in fact doing chaos think they are doing waterfall, or their management does, or their management thinks they should be doing waterfall. This notion is more slippery than has been recognized so far.

People to whom we are selling most likely want better software, sooner, cheaper, on time, on budget, stuff like that. And that's what we have to be offering.

Now to Bob's point: we do need to understand more of what is working and what is not working in agile projects. Curiousity and inquiry, yes. Skepticism? Not in my opinion. Skepticism is cold and closed. Agile is warm, and open.

My understanding of Bob's comments was that to sell to skeptics, we need to be able to understand XP from their perspective. I don't think he's saying we must permanently become the crabbed, bitter negative stereotype of a skeptic; I think he's just saying that we need to deeply understand their point of view to communicate well with them. That's ok by me; I think XP can stand up to a skeptical examination of its methods and results. -- WilliamPietri

Skepticism is a tool, not a destination. We shouldn't get too upset with it. I doubt we'd we be doing XP if we weren't skeptical of people who say "Hey, let's use this phased process - this time it will be different." It seems that warmth and openness need skepticism to thrive. -- MichaelFeathers

If a skeptic chooses a method, it's because s/he understands that method. To sell to skeptics, we need that kind of understanding. -- RcM

I thought the emphasis on qualifying success or failure in UncleBob's talk made a great deal of sense. I also liked CraigLarman's keynote. My main concern with CraigLarman's message is that Agile IS new to many people. IMHO, saying it's nothing new downplays the importance to people who've never heard of it before. I think the data is quite useful, particular if discussing XP practices with Academic institutions (which I think we need to do more). Just my $.02. -- Cheers, JasonNocks

This page mirrored in ExtremeProgrammingRoadmap as of April 29, 2006