Samizdat homepage

Slides Dmitry Borodaenko presented about Samizdat ath the Euruko 2003

• The dealer gives the customer all the chips for this iteration
• Then the customer "shuffles" the cards and lays them down
• As each one is laid down, development uses a different color of chips and places the number of chips that story costs.
• If the customer is okay with it, they then take an equivalent number of chips from their "stack" and place it to the "bet" pile.
• If the customer isn't okay with it, the story can be split (kind of like "double down" in blackjack) and/or cards can be "reshuffled"
• At any time, the customer may "reshuffle"
• When the customer is out of chips and is okay with the current "bets" and card order, the planning session is adjourned

 Below is a quote from Dave Pollard, the former Chief Knowledge Officer from
 Ernst & Young. It is a great paragraph because is is truly representive of
 why enterprise knowledge managment solutions failed. He is talking about the
 fact that knowledge managment systems have to be personal content management systems first.

 Quote:

 I believe personal content management tools are the place to start, because
 since the earliest days of business, the principal way of sharing information
 has been peer-to-peer, the most valued 'repositories' of business information
 have been personal filing cabinets, and the principal schema for organizing
 work has been the personal desktop. It makes sense, therefore, that tools
 that facilitate and reflect these well-established 'knowledge processes',
 information sources and networks should be much more successful than the complex,
 centralized, hierarchical knowledge management tools and repositories that have
 been foisted on users for the past decade.

 End Quote:

 It is a great quote because how is it possible that anyone could believe that
 a centralied hierarchical tool could work when it was in no way related to how
 people did and have done knowledge work since the beginning.

• Eliminate waste: Spend time only on what adds real customer value
• Amplify learning: When you have tough problems, increase feedback
• Decide as late as possible: Keep your options open as long as practical, but no longer
• Deliver as fast as possible: Deliver value to customers as soon as they ask for it
• Empower the team: Let the people who add value use their full potential.
• Build integrity in: Don’t try to tack on integrity after the fact - build it in
• See the whole: Beware of the temptation to optimize parts at the expense of the whole

Link

This from a lean manufacturing consultant:

Find the simple path to what works and follow it, always looking for a simpler path.

Patrick D. Smith

In this document we show you the Ruby version of the Smalltalk code published in the pink book.

For developers, XP allows you to focus on coding and avoid needless paperwork and meetings. It provides a more social atmosphere, more opportunities to learn new skills, and a chance to go home at a decent hour each night. It gives you very frequent feelings of achievement, and generally allows you to produce code that you feel good about.

For the Customer, XP creates working software faster, and that software tends to have very few defects. It allows you to change your mind whenever you need to, with minimal cost and almost no complaining from the developers. It produces reliable estimates so you can coordinate your schedule easier.

For management, XP delivers working software for less money, and the software is more likely to do what the end users actually want. It cuts risk in a couple ways: 1) It allows you to "pull the plug" on development at almost any time, and still have highly valuable code, and probably even a valuable working (if incomplete) application. 2) It reduces your dependence on individual superstars, and at the same time can improve employee satisfaction and retention.

The biggest disadvantage: It’s hard. It’s difficult to get many developers to accept the practices, and it takes a lot of discipline to keep doing them all. Customers may not like the idea of having to be so involved. Management may expect fixed-cost, fixed-scope estimates, which XP teams often refuse to create (because they are usually incorrect with any methodology).

Also, certain people may feel their jobs are being threatened, particularly architects, testers, and project managers. "Cowboy" coding "superstars" may dislike the reduction in fame, attention, and adreneline from "saving" the project at the last minute.

But there are similarities: software is developed in stages, it is created in a process amenable to change, and it’s developed in a team. Lean manufacturing is a different approach than a traditional assembly line, and offers some lessons for software development. xp123.com/xplor/xp0312/index.shtml

Both of these images are wrong. Hacking and painting have a lot in common. In fact, of all the different types of people I’ve known, hackers and painters are among the most alike. www.paulgraham.com/hp.html

I’ve been thinking about the problems of applying XP to whole organizations. Turns out this is ground thoroughly covered by the lean production folks.

Here is a paper I found helpful: www.nwlean.net/no_harm.zip The premise is that every step of the transformation must pay for itself.

Getting people to understand that their problems are tractable can be hard, I’ve found. Rob Mee was talking to a guy about TDD on a gig of ours recently. "Sure, yeah, TDD is a great idea." "Why don’t you do it?" "It’ll make us go slower." "But it makes you go faster." "Yes, of course, but it’ll make us go slower." "But it’ll make you go faster" *iterate N times for annoying large N* "Okay, it makes people go faster everywhere but here."

Amongst other things this article tells you when best to have children :-). groups.yahoo.com/group/extremeprogramming/files/when%20should%20we%20test.pdf

(Source: Ron Jeffries in the XP-mailinglist) Well, Don't do Code Reviews, do Pair Programming. Frankly, code reviews are /so/ much worse than pair programming that a dose of them would make me fly to pair. Let's see if we can replicate my experience.

Here's one path through a network of a million decision points:

To do code reviews, everyone has to read the code beforehand, unless you're doing a walkthrough, see below. I'd ask everyone to come together physically to the review. Then I'd ask them to report truthfully how much time they spent reviewing the code. Early on, I would report truthfully that I had spent zero or very little time, in hopes of getting others to admit the truth. When they admit the truth, I'd dismiss the meeting and reschedule it.

Then, after a while, the only alternative is a walkthrough, since no one is preparing effectively for the review. So we do walkthroughs for a while. They are intensely boring, and few people stay involved. Note in your mind the people who are present but not involved. At the end of the session, say, holding your hand up, "Who else had a real problem staying engaged with this walkthrough?" If there's honesty in the room, hands will go up. Prompting may be necessary. Then: "Any ideas?"

Surely someone will think of "doing this in smaller groups or one on one". Try it. Ask the team whether "we should empower the one-on-one folks to change the code, and under what circumstances." Don't mention that this is pair programming.

Try an experiment. You're "interested in collaborative programming". Interested parties should come to the room to help. On the screen, start writing a program. Ask for help with it, get the room to pair with you. Get stuck (no need to fake this if you are me). Someone will start telling you what to do. Don't get it (no need to fake this either). Get them to come up and do it ... grabbing the chair that is accidentally beside you, while you move over.

Note that reviews often find things. Observe how many of them are resisted by the original programmer, or are "too much trouble to fix now". Build a few BVCs relating to time spent prepping, in the meetings, number of useful suggestions (by person if you can do it without problems), number of changes made in response to suggestions, ...

Code reviews are intensely painful, in my experience, and we were trained by Freedman himself. There will be no need to set them up to be perceived that way, though it will take honesty among the group to express it. After doing enough code reviews, which take way more than half the groups' time by the way, a team who has heard of pair programming should be begging to pair. About all you have to do is make sure that no one treats the review session as nap time, and that you are /early/ in recognizing the people who think it's a waste of time. Because they're right.

Basically it’s an ad for Whiteboard Photo. ;-)

The Cook’s Tour offers an excellent howto to get yourself and your customers into the test-writing mode.

An intro article by Bill Wake.