Showing posts with label think team. Show all posts
Showing posts with label think team. Show all posts

pair programming presentation at XP Kiev

It was my pleasure to speak at the XP Kiev conference recently. I spoke about Pair Programming, or more accurately, about not programming alone. It really is about Pair Programming despite the picture of me fishing at the beginning! Here's the video :-)

[フレーム]

the psychology of computer programming

is an excellent book by Jerry Weinberg. As usual I'm going to quote from a few pages:
I've read this book twice before, once here, and again here.
We must deal with one other problem, which is important because of a seldom questioned view of programming - a view which this book will spend a great deal of time questioning. That view is that programming is an individual activity.
Now that hardware has grown cheaper whilst labor has grown more expensive, group members are much less likely to share a machine and system than there were years ago.
The requirement to develop capability cannot be met adequately by a single person. We learn much faster and much better with the active cooperation of others.
Has anyone ever thought of asking appplicants whether or not they like programmming?
With adults, however, the barriers to learning have usually become internalized, and the average adult learns very little of left to his own devices.
It is a well-known psychological principle that in order to maximize the rate of learning, the subject must be fed back information on how well or poorly he is doing.
Such companies are sitting ducks for anyone who comes along with a fancy package of promises - and with lots of sitting ducks, can the hunters be far behind?
An increase in salary only motivates for a short time it is the raise, not the salary level which is a symbol of current value.
To a surprising degree, the only time we fail to learn is when there are negative forces set up against it.
Because the machines are rigid, the people who use them must, if they are to be successful, supply more than their share of flexibility.
We are trying to make the machine help people take advantage of the immense psychological resources they have in overcoming their immense psychological shortcomings.


teams

Back to quotes table-of-contents

From Quality Software Management: Vol 3. Congruent Action
In all Steering (Pattern 3) organisations, the team is the fundamental unit of production.

From The Psychology of Computer Programming
In the end though, it's their method of learning that distinguishes teams from groups… team members always have a common goal, regardless of the product - the goal of helping each other learn to perform better.

From Pair Programming Illuminated
Widespread use of pair programming involves a cultural shift in values of the organization - away from individual and toward team recognition and goals.

From Wooden on Leadership
I rarely assigned one player to a basket. Basketball is a team sport, and I felt it was unwise to allow players to practice by themselves. Always I wanted them to be interacting with their teammates.

From Situated Learning - Legitimate Peripheral Participation
The fact that the work was done in an interaction between members opened it up to other members of the team.

From The Fifth Discipline
The total absence of meaningful practice or rehearsal is probably the predominant factor that keeps most management teams from being effective learning units.

In great teams conflict becomes productive.

From Peopleware
Most organizations don't set out consciously to kill teams. They just act that way.

The structure of a team is a network, not a hierarchy.

From The Deming Route to Quality
Time and again I see the benefits of using a team.

Teamwork characteristics ... cannot be determined if you interview ... one at a time.

From The Mythical Man Month
The Mythical Man Month is only incidentally about software but primarily about how people in teams make things.

From Toyota Production System - Beyond Large Scale
In modern industry, harmony among people in a group, as in teamwork, is in greater demand than the art of the individual craftsman.

From The Starfish and the Spider
The Toyota assembly line... if an employee stopped the line a pleasant "ding-dong" would sound and teams would carefully study what was going on.

the power of example

Last week I attended another excellent Jerry Weinberg course in Albuquerque. Here's one of the nuggets I learned. It's related to the famous Solomon Asch social psychology conformity experiment.

In the experiment a group of people are shown two cards. The first card has a single line on it. The second card has three lines on it labelled A,B,C one of which clearly matches the length of the line on the other card (and the other two clearly don't). Only one person in the group is the actual subject and is unaware that the other members of the group are part of the experiment. The experiment measures how likely the subject is to conform to the answer given by everyone else when that answer is clearly the wrong one. The answer is "quite a lot". But that's not what I learned. What I learned about is a variation on that experiment. One where Solomon Asch measured how the effect varied depending on how many other people's answers matched, or didn't match, the subject's answer. You can read about this variation (and some others) here. This is the punchline:

The presence of a [single] supporting partner depleted the majority of much of its power. Its pressure on the dissenting individual was reduced to one fourth: that is, subjects answered incorrectly only one fourth as often as under the pressure of a unanimous majority.

Isn't that a great example of the power of setting an example. Of how change happens one person at a time. Of courage. Of how important it is that people feel safe. People are always more impressed by the power of our example than by the example of our power.


lessons from geese

Here are some facts about Geese, borrowed from Dr Robert McNeish. They appeared in an issue of Southwest Airlines corporate newsletter.

When you see geese heading back north for the summer flying along in a "V" formation you might be interested in knowing what scientists have discovered about why they fly that way. It has been learned that as each bird flaps its wings, it creates an uplift for the bird immediately following. By flying in "V" formation, the whole flock adds a least 71 percent greater flying range than if each bird flew on its own.

Whenever a goose falls out of formation it suddenly feels the drag and resistance of trying to go it alone and quickly gets back into formation to take advantage of the lifting power of the bird immediately in front.

When the leads goose gets tired, he rotates back in the wing and another goose flies point.

The geese honk from behind to encourage those up front to keep up their speed.

When a goose gets sick or is wounded by gunshot and falls out, two geese fall out of formation and follow him down to help and protect him. They stay with him until he is able to fly or until he is dead, and then they launch out on their own or fly with another formation to catch up with their group.

trustee from the toolroom

is an excellent book by Nevil Shute (isbn 978-0-099-52998-9). A marvelous tale of courage and friendship. As usual I'm going to quote from a few pages:
At last she asked, 'Do you think my Mummy and Daddy were very frightened when the ship got wrecked?' The adult quality of the question amazed him; children were so much older than you thought they were. 'No,' he said. 'No, I don't think that they'd ever have been frightened. They weren't that sort of people. And you won't be frightened of things either, I don't think.'
He was impressed and somehow amazed by the things he did not know. These men were working as a team, doing things together quickly and accurately, things that he could only guess at. He knew that on their teamwork the safety of the aircraft depended. All his own skill and ingenuity could not assist them by one iota; the most that he could do to help them in their work was to keep right out of their way.
Technical fields, he reflected, of necessity were small; if you were an expert in one subject you could not be expert also in all the others, for no man's mind was big enough. The man who designed the radar presentation that the controller had used to talk them down that morning would not himself have been able to bring them into a safe landing, for he would not have known sufficient about aeroplanes.
Where everything was strange this seemed no stranger than the rest.
He was scared stiff. He sat there in his cricket shirt and braces with Panama hat upon his head under the brilliant sun of the Hawaiian Islands, the bread and the corned beef untasted on the desk beside him, concentrating on doing the one that he had been taught, keeping the tiddly little triangle upon the lubber line.
Towards the morning it occurred to him that anyway he should not keep his grim forebodings to himself. Two heads, or several heads, were better than one. If he shared his apprehensions with other people someone might pull some rabbit out of an unthought-of hat, might make some suggestion that would somehow make Keith's journey to Tahiti safer.
Jack shook his head. 'Ma died last year. She was always wanting to get back to the islands, but she liked the television too, so she was pulled both ways.'
'I tell you one thing,' he said presently. 'I'll leave the little generator set here, in the Mary Belle.' Jack stared at him. 'Leave that here, with me?' 'That's right. This ship hasn't got a motor. She ought to have one.'
'I think when people get older,' he said, 'they kind of get more mellow. They kind of like to give help in return for help they get.'
She had decided in her own mind that he was honest.
She paused. 'Don't refuse him when he wants to do this little thing,' she said gently. 'You've given him a lot of pleasure with your letters and the clock. Let him do this for you.'

Pair Programming Illuminated

is an excellent book by Laurie Williams and Robert Kessler. As usual I'm going to quote from a few pages

Programmers admit to working harder and smarter on programs because they do not want to let their partner down.

The pair results were also more consistent, while the individuals varied more about the mean. Individuals intermittently didn't hand in a program or handed it in late; pairs handed in their assignments on time.

Widespread use of pair programming involves a cultural shift in values of the organization - away from individual and toward team recognition and goals.

We have observed that effective pair programmers communicate with each other at least once a minute.

Interestingly enough, the more experience a developer has, the more likely he or she is to ask for help; novices are less likely to ask for help.

We used to consider a new person unproductive for their first three months. Now, we find that new people can help out almost immediately.

We still feel that a novice pair is a better alternative to a solo novice.

We believe pair programming is an integral part of XP, and it is dangerous to do XP without doing pair programming.


stuka pilot

is an excellent book by Hans Ulrich Rudel (isbn 978-1908476876). As usual I'm going to quote from a few pages:
He tells me that a large scale offensive is in preparation in my sector... approximately three hundred tanks are to be employed in this operation... The number three hundred flabbergasts me... I reply that I find some difficulty in believing it... He says to me, half in earnest, half in jest: "If I didn't know you, for two pins I would have you put under arrest for saying such a thing. But we will soon find out." He goes to the telephone and is connected with the Chief of the General Staff. "You have just given the Fuhrer the figure of three hundred tanks for operation X." "Yes I did." "I want to know the names of the divisions concerned with their present strength in tanks. I have somebody with me who is well acquainted with the position." ... the Chief of the General Staff has the bad luck to begin with the 14th armoured division. He says it has sixty tanks. Goering can hardly contain himself. "My man reports that the 14th has one!" A lengthy silence at the other end of the line. "When did he leave the front?" "Four days ago." Again silence. Then "Forty tanks are still on their way to the front. The rest are in repair shops on the line of communications, but will certainly reach their units by zero day, so that the figures are correct." He has the same answer for the other divisions. The Reichsmarschall slams down the receiver in a rage. "That is how it is!" The Fuhrer is given a totally false picture based on incorrect data and is surprised when operations do not have the success expected... The South Eastern zone with its network of communications is being incessantly blanketed by the enemy's bomber formations. Who knows how many of those forty tanks, for example, will ever reach the front or when? Who can say if the repair shops will get their spare parts in time and if they will be able to complete their repairs within the specified time?
In ministries and departments, however, mistakes are denied on principle.
Another confirmation of the truth of our old Stuka maxim: "Nothing comes off - except what you have practised."
We have long since ceased to develop practice from theory; we do just the opposite.
The fitters have their hands full, for the aircraft have been heavily damaged by flak. The life of such an aeroplane will always be limited.
Little by little I discover all the tricks. Skill is often the result of getting hurt.
I now see that perfectly plainly. We are alone to possess this knowledge; the responsibility is ours.


the lean startup

is an excellent book by Eric Ries (isbn 978-0-670-92160-7). As usual I'm going to quote from a few pages:
What if we found ourselves building something that nobody wanted? In that case what did it matter if we did it on time and on budget?
I've come to believe that learning is the essential unit of progress for startups.
If you cannot fail, you cannot learn.
Qualitative learning is a necessary companion to quantitative testing.
Pay no attention to the eight people behind the curtain.
When I could think of nothing else to do, I was finally ready to turn to the last resort: talking to customers.
That which optimizes one part of the system necessarily undermines the system as a whole.
Large batches tend to grow over time.
The paradoxical Toyota proverb "Stop production so production never had to stop."
We routinely asked new engineers to make a change to the production environment on their first day... They would ask, "What will happen to me if I accidentally disrupt or stop the production process?" ... We told new hires, "If our production process is so fragile that you can break it on your very first day of work, shame on us for making it so easy to do so." If they did manage to break it, we immediately would have them lead the effort to fix the problem as well as the effort to prevent the next person from repeating the mistake.
Switching to validated learning feels worse before it feels better... the problems caused by the old system tend to be intangible, whereas the problems of the new system are all too tangible.


my kanban 1's board game

Here's a slide deck explaining the essence of my kanban 1s board game. Jon Jaggers Kanban 1s Board Game[フレーム]
  • You can play an early session with no clips so the players can see how inventory builds up (you can also push done story-cards to the next edge's corner, rather than waiting for them to be pulled).
  • The clips that hold the story-cards are a crucial part of the game. They make it a kanban game.
  • You can limit the number of clips per edge to create a natural work-in-progress (wip) limit.
  • You can add a new rule: players can also spend a 1 to split a story-card in two, eg a 4 into a 3 and a 1 (assuming they have a spare clip).
  • You can record the day a story-card comes off the backlog, and also the day it gets to done and thus measure the cycle time.
  • You can simulate scrum-style discrete sprints.
  • You can vary the number of dice at different edges.


Smoking cigarettes, eating sweets, dropping litter, and drinking coffee

I was speaking to Olaf Lewitz at the awesome Oslo coach camp last week. We were discussing why drinking coffee doesn't create the same social dynamic as smoking cigarettes. I chatted with Geir Amdal too and quite by chance he mentioned he's given up smoking. And how approaching a work colleague and asking if they want to go outside for a smoke is not the same as asking if they want to go outside for a talk.

Then I remembered something Olve Maudal said to me recently. He said that kids being allowed to eat sweets on Sundays was not really about kids being allowed to eat sweets on Sundays at all. It was really about kids not being allowed to eat sweets on any day except Sunday. Similarly, apparently in the USA when you're driving along you sometimes see a big sign at the side of the road saying "Litter here" and then another sign a mile or so later saying "Stop littering". These signs are also not really about littering. They're about not littering in the places outside the designated littering zones.

There's a crucial difference between smoking and drinking coffee. Smokers tend to smoke in groups in designated areas because smoking is not allowed except in those areas. Coffee is different. Drinking coffee is, by default, allowed everywhere. When you want a coffee you walk to the coffee machine and make a cup of coffee. There's often no one else at the coffee machine so you take your cup of coffee back to your work desk. It is precisely this take-it-back-to-your-desk default which is why there is only rarely someone else at the coffee machine. It is a self-fulfilling dynamic.

If you want to encourage more social interaction between your team members here's what you might do:

  • Buy machines that make really good coffee.
  • Put them in a nice area with lots of space to congregate in.
  • Ban drinking coffee at work-desks.
The third step might seem a bit draconian. But it's vital. You could justify it on the grounds that spilling coffee onto expensive computers will waste money. But the real reason it to encourage developers to drink their coffee near the coffee machine. Together. To encourage communication.

Quality Software Management
Vol 3. Congruent Action

is the title of an excellent book by Jerry Weinberg (isbn 0-932633-28-5). This is the second snippet review for this book (here's the first). As usual I'm going to quote from a few pages:
Management is the number one random process element.
If you cannot manage yourself you have no business managing others.
Congruent behaviours are not stereotyped behaviours - quite the contrary. Congruent behaviours are original, specific behaviours that fit the context, other, and self, as required by the Law of Requisite Variety.
Congruence is contagious.
It takes a long time and a lot of hard practice to raise your congruence batting average.
A basic law of perception is that we tend to minimise small differences (tendency toward assimilation) and to exaggerate appreciable differences (tendency toward contrast). Thus, our perceptions make the world more sharply differentiated than it is, and we're a lot more alike than we are different.
The simplest idea about curing addiction is to stop the use of X, under the belief that X causes addiction. X does not cause the addiction, the addiction dynamic causes the addiction.
To change the addiction you'll have to use something more powerful than logic.
One of the manager's primary jobs is to set the context in which interactions takes place and work is accomplished.
Management sets the context almost exclusively through the use of language.
Culture makes language, then language makes culture.
In all Steering (Pattern 3) organisations, the team is the fundamental unit of production.
I've learned that there's simply no sense trying to solve software engineering problems, or create software engineering organisations, when I'm not able to be congruent. So I work on that first, and that's what I hope you do, too.

Waiting work wall

One of the things I do a lot when visiting software groups is simply sit with individuals as they work. Sometimes the person I'm sitting next to is a really superb developer. They finish their work fast and to a high standard and hand the work on to the next person downstream. This next person may also be really skilled but their work might just inherently take longer. If the amount of work passed on exceeds the capacity of the next person then a growing batch of work-waiting-to-be-started-by-the-next-person will naturally form and grow.


This batch of work-waiting-to-be-started-by-the-next-person is waste. That's well known and well written about. What's not so obvious and not so well written about is how it encourages silos to form. It literally forms a barrier between the increasingly separated silos that form on either side of it.


Think of each waiting-work-item as a brick in a wall. But not a long, low, queue-shaped wall that's easy to see over. Rather, a short, high wall. One that you can't see over. One that hinders communication.


The amount of waiting-work between two silos is inversely proportional to the lack of communication between the two silos. The more waiting-work, the less the communication. The less communication the more waiting-work. Round and round it goes.


So, if you have some really superb developers then beware. They might be creating a downstream wall of waiting-work around which silos are forming.



Situated learning - Legitimate peripheral participation

is an excellent book by Jean Lave and Etienne Wenger (isbn 0-521-42374-0). As usual I'm going to quote from a few pages:
The world carries its own structure so that specificity always implies generality (and in this sense generality is not to be assimilated to abstractness).
Reversing production steps has the effect of focusing the apprentice's attention first on the broad outlines…
The fact that the work was done in an interaction between members opened it up to other members of the team.
There is anecdotal evidence that where the circulation of knowledge among peers and near-peers is possible, it spreads exceedingly rapidly and effectively.
A learning curriculum is thus characteristic of a community.
Understanding and experience are in constant interaction.
Mirroring the intricate relationship between using and understanding artefacts there is an interesting duality inherent in the concept of transparency. It combines the two characteristics of invisibility and visibility… It might be useful to give a sense of this interplay by analogy to a window. A window's invisibility is what makes it a window, that is, an object through which the outside world becomes visible. The very fact, however, that so many things can be seen through it makes the window itself highly visible, that is, very salient in a room, when compared to, say, a solid wall. Invisibility of mediating technologies is necessary for allowing focus on, and thus supporting visibility of, the subject matter.

In the brain of me

Here's a video of the SkillsMatter talk I did on Thursday, titled "Stuff I'm starting to know now that I really wish I'd known 20 years ago". Its loosely based on the theme of Making The Invisible More Visible, one of my entries from the book, 97 Things Every Programmer Should Know. I completely botched what I was trying to say about courage. What I was trying to say was that courage is not the absence of fear.

My other SkillsMatter talk was based on Do More Deliberate Practice my other entry in the 97 Things Book.

This was the first run of quite a lot of new material so I was quite nervous, but I felt most of it went very well. Here's some of the feedback.
  • Fun, informative, useful
  • An interesting brain dump
  • Entertaining and enlightening
  • Very good. Thoughtful and interesting
  • Great content - very interesting
  • Great laid back presentation
  • Interesting ideas and great presentation to go with it
  • Well planned presentation, not just your standard powerpoint
  • Very good talk. Inspiring
  • Very interactive and well explained
  • Clear explanations, good analogies, funny
  • Fantastic
  • Very good. Passionate speaker. Good insights


Peopleware

is an excellent book by Tim Lister and Tom DeMarco (isbn 0-932633-43-9). As usual I'm going to quote from a few pages. I know I've snippeted this book before, but I read it again and a really good book deserves a repeat snippet.
Development is inherently different from production.
Most organizations don't set out consciously to kill teams. They just act that way.
The trade-off between price and quality does not exist in Japan. Rather, the idea that high quality brings on cost reduction is widely accepted. [Tajima and Matsubara]
The manager's function is not to make people work, but to make it possible for people to work.
The trick isn't in the technology; it's in the changing of habits.
An age-old pattern of interior space is one that has a smooth "intimacy gradient" as you move toward the interior.
Employee turnover costs about twenty percent of all manpower expense. But that's only the visible cost of turnover. There's an ugly invisible cost that can be far worse.
It's only the right to be wrong that makes you free.
The structure of a team is a network, not a hierarchy.
Everyone quickly understands that the presence of the posters is a sure sign of the absence of hard work and talent.
The more you improve the way you go about your work, the harder the work will be.
The manager of a large project in Minneapolis has refused to move his people to the new quarters. ("New in this case just meant smaller and noisier.) Administrators were simply stunned at his refusal; they had never considered the possibility.

rules of thumb

don't rush

I don't think I can put it any better than Jerry Weinberg did when I interviewed him:

Things take the time they take, not the time you hope they will take. Pushing for half-time produces half-baked.


As a self-employed software coach/consultant I get to travel a lot and visit a lot of companies. At the best companies there is a palpable sense of not rushing.

think team

Software development is all about collaborative learning. I think one of the weakest points of the Agile Manifesto is it's lack of emphasis on teams. The very first word of the four "X over Y" statements is Individuals :-( XP at least takes a firm step beyond programming as an individual activity by mandating pair programming. I look at Sit Together, a practice from XP1 and I think s/Sit/X/. In other words, whatever X is, X Together.

increase visibility

Software and the process of developing it can be, to paraphrase Douglas Adams, mostly invisible. You think more clearly when you have something concrete to tie your thinking to. You manage things better when you can see them and see them constantly changing. It's no accident that Kanban boards are as popular as they are.

Subscribe to: Comments (Atom)

AltStyle によって変換されたページ (->オリジナル) /