See also XpAgileUniverseTwoThousandFour ---- If you attended XP/Agile Universe 2004, please share your experiences. If you didn't get to go, this page should give you some of the highlights. This year's theme seemed to be '''Crossing the Chasm''' 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! ---- Keynote by Christopher Avery, "Ultimate Agility" (Monday morning) * 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. ---- Keynote by Mary Poppendieck, "Crossing the Chasm" (Monday morning) * 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!''' ---- Keynote by Bob Martin, "Kepler's Care" (Tuesday at dinner) * 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) ---- Keynote by Brian Marick, "Undoing Testing in Agile Projects" (Wednesday morning) * 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? ---- Keynote by Craig Larman, "History and Evidence: Iterative and Evolutionary versus the Waterfall" (Wednesday morning) * 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 ---- Keynote by Eric Evans, "Domain Driven Design" (Wednesday morning) * 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 ---- Workshop "Getting Leaders on Board" led by Mary Poppendieck * 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! ---- General impressions and reactions. -- RonJeffries 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. '''Bob's talk''' was also inspiring as usual. I take strong issue, however, with the idea that in order to sell to skeptics we need to be skeptics. In order to sell to anyone, we need to sell them what they want. If skeptics want skepticism, then I suppose we could figure out a product for that, but skeptics probably do not want that. At some metaphysical level, perhaps they want something to believe in, but I'm not going there. 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