(Originally posted 2003.May.07 Wed; links may have expired.)
Brad Appleton, on the XP mailing list, recommends "appreciative inquiry" http://www.appreciative-inquiry.org/ and http://www.thinbook.com/chap11fromle.html. This technique lets people feel they and their ideas are appreciated, and focus on what's right rather than on what's wrong.
On Hal Macomber's blog Reforming Project Management, he wrote on Tuesday, April 29, 2003:
My favorite management author is Ken Blanchard author of The One Minute Manager and dozens of other books. [...] Blanchard implores people to focus on positive feedback. In his book Whale Done! he goes into how trainers never use negative feedback when working with dangerous animals. If killer whales can be trained to do the spectacular things that they do with only positive feedback, then why would we want to use negative feedback with the even more dangerous human beings?
Apparently, "Whale Done!" is also on video, dvd, etc... http://www.rctm.com/app/Product/71727.html
Sunday, April 12, 2015
Saturday, April 11, 2015
Feedback, the Secret of Agile Development
(Originally posted 2003.May.10 Sat; links may have expired.)
A paper of mine, about feedback in Agile / XP projects, has been published on the AYE Conference website: http://www.ayeconference.com/Articles/Secretofagile.html. That paper concentrated on testing and customer involvement, but there is more feedback possible: there is feedback from members of the developer team, management, QA, and other stake-holders associated with the project.
The Standish group, in their Chaos Report, reports that the top three project success factors, in order of most important to less important are:
Other success factors that also support my point are:
In typical waterfall projects, user involvement is only at the first and last stages: requirements gathering and final testing (and sometimes users are not involved even in those two stages!). This obviously isn't enough, since IT projects, according to the Standish group, are only successful an average of 12% of the time.
Agile methods aim for success by requiring more user involvement through the life of the project: the practices of On-Site Customer and Frequent Releases, among others. User involvement also helps with maintaining realistic expectations and getting those requirements clearly understood.
Even with user involvement, there are project failures from lack of management support. Most of the stories of unsuccessful projects I've heard at BayXP are due to lack of executive management support - failure to get buy-in from the rest of the company. In some cases, the project was on-time and on-budget, but the rest of the company rejected the process and/or the people involved.
Successfully adopting XP requires a company culture compatible with its values, and many companies just don't have that culture. To get to XP, the company would need a culture change, which requires skilled, dedicated, change artists and a company-wide perceived need for change. Thus, Industrial XP does a Readiness Assessment to see if there is a culture fit.
Agile methods have smaller project milestones, a proven success factor, as well as frequent releases. Getting the product out in front of real users not only enables more feedback, but can be financially rewarding as well, by reducing time-to-market or opening a new market. For internal projects, "small releases" to some portion of the end-users is a proof of concept, demonstrating to management the viability of the project.
Competent staff is a sticky point. No method can work well if the people don't know how to do it or don't understand it. Many XP project failures result from staff that had no training on the practices and didn't practice all of the recommended practices. I've already written that XP's test-driven-development requires testing skills and refactoring skills that both inexperienced and experienced programmers may be lacking. Training and practice, whether by intensive, disciplined, self-training, or training from good teachers, is necessary for those new to XP.
Lack of competence in test-driven-development shows up in unexpectedly-failing acceptance tests, bugs slipping through to users, and decreasing velocity (features done per iteration). Developers puzzling over the bug-reports, unhappy users and managers, and increasingly-unmaintainable code probably realize that something is going wrong, but without a coach or someone experienced in software development, may not know how to fix it. In the worst cases, they ignore this feedback and deny that anything is going wrong.
Industrial XP's additional practices - Project Chartering, Project Community, Test-Driven Management, and so on - address the factors of ownership and clear vision. If the project starts to drift off course, members of the project community can point to the Charter and Manager-Tests and ask "why are we moving in this direction?" IXP's practice of doing Retrospectives regularly (mini-retrospective each iteration, as well as larger ones at longer intervals) will also help with clear vision of the objectives and ownership of the process, providing feedback to the participating members of the project community.
The hardest kind of feedback to specify in a "process" is personal feedback from people in the team, whether in pair programming, retrospectives, or otherwise.
Naomi Karten's book on Communication Gaps can help.
Many people I respect recommend What Did You Say?: The Art of Giving and Receiving Feedback by Charles N. Seashore, Edith Whitfield Seashore and Gerald M. Weinberg.
Norman L. Kerth wrote the definitive book on Project Retrospectives, but you shouldn't try to do a large retrospective without a skilled facilitator. Read the book to see why.
The larger community is also a valuable source of feedback and learning. Go to your local Agile or XP group meetings, join or at least read the XP, IXP, and/or TDD mailing lists. Read the books. Read the web. Go to conferences if you can.
A paper of mine, about feedback in Agile / XP projects, has been published on the AYE Conference website: http://www.ayeconference.com/Articles/Secretofagile.html. That paper concentrated on testing and customer involvement, but there is more feedback possible: there is feedback from members of the developer team, management, QA, and other stake-holders associated with the project.
The Standish group, in their Chaos Report, reports that the top three project success factors, in order of most important to less important are:
- User Involvement
- Executive Management Support
- Clear Statement of Requirements
Other success factors that also support my point are:
- Realistic Expectations
- Smaller Project Milestones
- Competent Staff
- Ownership
- Clear Vision and Objectives
In typical waterfall projects, user involvement is only at the first and last stages: requirements gathering and final testing (and sometimes users are not involved even in those two stages!). This obviously isn't enough, since IT projects, according to the Standish group, are only successful an average of 12% of the time.
Agile methods aim for success by requiring more user involvement through the life of the project: the practices of On-Site Customer and Frequent Releases, among others. User involvement also helps with maintaining realistic expectations and getting those requirements clearly understood.
Even with user involvement, there are project failures from lack of management support. Most of the stories of unsuccessful projects I've heard at BayXP are due to lack of executive management support - failure to get buy-in from the rest of the company. In some cases, the project was on-time and on-budget, but the rest of the company rejected the process and/or the people involved.
Successfully adopting XP requires a company culture compatible with its values, and many companies just don't have that culture. To get to XP, the company would need a culture change, which requires skilled, dedicated, change artists and a company-wide perceived need for change. Thus, Industrial XP does a Readiness Assessment to see if there is a culture fit.
Agile methods have smaller project milestones, a proven success factor, as well as frequent releases. Getting the product out in front of real users not only enables more feedback, but can be financially rewarding as well, by reducing time-to-market or opening a new market. For internal projects, "small releases" to some portion of the end-users is a proof of concept, demonstrating to management the viability of the project.
Competent staff is a sticky point. No method can work well if the people don't know how to do it or don't understand it. Many XP project failures result from staff that had no training on the practices and didn't practice all of the recommended practices. I've already written that XP's test-driven-development requires testing skills and refactoring skills that both inexperienced and experienced programmers may be lacking. Training and practice, whether by intensive, disciplined, self-training, or training from good teachers, is necessary for those new to XP.
Lack of competence in test-driven-development shows up in unexpectedly-failing acceptance tests, bugs slipping through to users, and decreasing velocity (features done per iteration). Developers puzzling over the bug-reports, unhappy users and managers, and increasingly-unmaintainable code probably realize that something is going wrong, but without a coach or someone experienced in software development, may not know how to fix it. In the worst cases, they ignore this feedback and deny that anything is going wrong.
Industrial XP's additional practices - Project Chartering, Project Community, Test-Driven Management, and so on - address the factors of ownership and clear vision. If the project starts to drift off course, members of the project community can point to the Charter and Manager-Tests and ask "why are we moving in this direction?" IXP's practice of doing Retrospectives regularly (mini-retrospective each iteration, as well as larger ones at longer intervals) will also help with clear vision of the objectives and ownership of the process, providing feedback to the participating members of the project community.
The hardest kind of feedback to specify in a "process" is personal feedback from people in the team, whether in pair programming, retrospectives, or otherwise.
Naomi Karten's book on Communication Gaps can help.
Many people I respect recommend What Did You Say?: The Art of Giving and Receiving Feedback by Charles N. Seashore, Edith Whitfield Seashore and Gerald M. Weinberg.
Norman L. Kerth wrote the definitive book on Project Retrospectives, but you shouldn't try to do a large retrospective without a skilled facilitator. Read the book to see why.
The larger community is also a valuable source of feedback and learning. Go to your local Agile or XP group meetings, join or at least read the XP, IXP, and/or TDD mailing lists. Read the books. Read the web. Go to conferences if you can.
Friday, April 10, 2015
Wright Interview
(Originally posted 2003.Jul.11 Fri)
I picked up a tape of the Mike Wallace Interviews of Frank Lloyd Wright the other day. It consists of two 25-minute interviews that were recorded around 1957, when Wright was around 88 years old. The first interview says a LOT about 1950's art of "the celebrity TV interview" and not much about Wright. The second interview was better, but neither one lets you hear Wright say anything specific about any of his buildings.
"My name is Mike Wallace; the cigarette is Philip Morris". In the first interview, Wallace is apparently trying to get to know "Wright, the man" by asking controversial questions like "what is your opinion on organized Christianity?" and "What do you think about mercy killing?" and questions about the "Mobocracy". Wright answers the questions very carefully and reasonably, well aware that he's on nation-wide TV. Unlike modern-day interviews, the interviewee isn't prompted or allowed to tell stories about his life.
Sometimes the first interview degenerates into asking about other celebrities: "What do you think about Salvador Dali?" and Picasso? Wallace tries to get Wright to say something about Charlie Chaplin's "anti-Americanism" (Chaplin was forced to leave the US because of accusations of Communistic tendencies), but changes the subject when Wright mentions McCarthyism. The last question of the first interview is: what do you think of Marilyn Monroe's architecture?
Quote from the first interview:
In the second interview, (several months later, back by popular demand) Wright is more comfortable, and can express his philosophy at more length. Still almost nothing "concrete" about architecture, though.
Quotes from FLW in the second interview:
On the New York skyline:
Answering "can you give me something to live by?" (the question young students ask of Wright):
I picked up a tape of the Mike Wallace Interviews of Frank Lloyd Wright the other day. It consists of two 25-minute interviews that were recorded around 1957, when Wright was around 88 years old. The first interview says a LOT about 1950's art of "the celebrity TV interview" and not much about Wright. The second interview was better, but neither one lets you hear Wright say anything specific about any of his buildings.
"My name is Mike Wallace; the cigarette is Philip Morris". In the first interview, Wallace is apparently trying to get to know "Wright, the man" by asking controversial questions like "what is your opinion on organized Christianity?" and "What do you think about mercy killing?" and questions about the "Mobocracy". Wright answers the questions very carefully and reasonably, well aware that he's on nation-wide TV. Unlike modern-day interviews, the interviewee isn't prompted or allowed to tell stories about his life.
Sometimes the first interview degenerates into asking about other celebrities: "What do you think about Salvador Dali?" and Picasso? Wallace tries to get Wright to say something about Charlie Chaplin's "anti-Americanism" (Chaplin was forced to leave the US because of accusations of Communistic tendencies), but changes the subject when Wright mentions McCarthyism. The last question of the first interview is: what do you think of Marilyn Monroe's architecture?
Quote from the first interview:
"I don't think Architecture is for the Mob, it certainly isn't for education. Education certainly knows nothing of it. And very few architects in the world know anything about it. I've been accused of saying I was the greatest architect in the world, and if I had said so, I don't think it would be very arrogant because I don't believe there are many, if any. For 500 years architecture has been phony... in the sense that it was not innate, it was not organic, it didn't have the character of Nature."
In the second interview, (several months later, back by popular demand) Wright is more comfortable, and can express his philosophy at more length. Still almost nothing "concrete" about architecture, though.
Quotes from FLW in the second interview:
"I would like to make architecture appropriate to the Declaration of Independence, to the center-line of our freedom; I would like to have a free architecture. I would like to have architecture that belong to where you see it standing, an architecture that was a grace to the landscape rather than a disgrace."
On the New York skyline:
"[It] never was planned; it's all a race for rent, and it is a great monument I think to the power of money and greed, trying to substitute money for ideas. I don't see an idea in the whole thing anywhere, do you?"
Answering "can you give me something to live by?" (the question young students ask of Wright):
"The answer is within yourself. In the nature of thing that you represent as yourself. Jesus said it, I think, when he said the kingdom of God is within you. That's where Architecture lies, that's where Humanity lies, that's where the future we're going to have lies. If we're ever going to amount to anything, it's there, now, and all we have to do is develop it."
Thursday, April 9, 2015
Waste Not
(Originally posted 2003.May.13 Tue; links may have expired.)
The Standish group, in their Chaos Report, reports that 85% of the features implemented in the average IT project are NOT not used by the customer.
If you knew which features the customers were really going to use, You could avoid wasting 85% of your budget, and you could ship 85% earlier, getting revenue sooner. Sounds like a win-win for both customer and supplier.
This applies to shrink-wrap software as well as in-house projects. id software (if I recall correctly) released limited-features (free) early versions of their breakthrough game Doom to get feedback from their users and get them addicted to their software.
How do you find out which features the customer really need? Ask them. Get them involved in the product with early releases. If possible, get a representative customer involved in the planning and feature definition.
Eliminating waste (like that unnecessary 85%) is one part of Lean Manufacturing. Like myself, Kent Beck did not view "manufacturing" as an appropriate metaphor for software development until he started reading about Taiichi Ohno's Toyota Production Method. Here's a small write-up: by R.Balakrishnan.
Lean Manufacturing, like XP, often encounters what seems to be irrational rejection (even after demonstrating success). On the XP mailing list Kent Beck writes:
Beck also points to a paper [a zip file containing a pdf] on adopting Lean Manufacturing which is titled "First, Do No Harm!" by Michel Baudin. The paper recommends converting to Lean with pilot projects that show rapid improvement and pay for themselves. At no time should converting to Lean cause a drop in revenue or delays in delivering product. Baudin also points out that you can't convert to Lean instantly, because it requires learning new skills. Not unlike the new skills needed for XP.
The Standish group, in their Chaos Report, reports that 85% of the features implemented in the average IT project are NOT not used by the customer.
If you knew which features the customers were really going to use, You could avoid wasting 85% of your budget, and you could ship 85% earlier, getting revenue sooner. Sounds like a win-win for both customer and supplier.
This applies to shrink-wrap software as well as in-house projects. id software (if I recall correctly) released limited-features (free) early versions of their breakthrough game Doom to get feedback from their users and get them addicted to their software.
How do you find out which features the customer really need? Ask them. Get them involved in the product with early releases. If possible, get a representative customer involved in the planning and feature definition.
Eliminating waste (like that unnecessary 85%) is one part of Lean Manufacturing. Like myself, Kent Beck did not view "manufacturing" as an appropriate metaphor for software development until he started reading about Taiichi Ohno's Toyota Production Method. Here's a small write-up: by R.Balakrishnan.
Lean Manufacturing, like XP, often encounters what seems to be irrational rejection (even after demonstrating success). On the XP mailing list Kent Beck writes:
I'm reading Lean Transformation, which is full of stories of dramatic improvements in manufacturing quality and productivity that are immediately dismantled as soon as the consultants leave the building, even at the eventual cost of the jobs of the people doing the dismantling. Which is to say, you are not alone.
Harvard Business Review has an article this month about Bill
Bratton, who has turned around 5 police organizations, including the
whole of NYPD. You should read the article, but the sequence I took
away was:
Put the managers in direct contact with the problem
Focus you resources on the single worst problem
Enlist powerful allies
Marginalize or eliminate naysayers
Beck also points to a paper [a zip file containing a pdf] on adopting Lean Manufacturing which is titled "First, Do No Harm!" by Michel Baudin. The paper recommends converting to Lean with pilot projects that show rapid improvement and pay for themselves. At no time should converting to Lean cause a drop in revenue or delays in delivering product. Baudin also points out that you can't convert to Lean instantly, because it requires learning new skills. Not unlike the new skills needed for XP.
Wednesday, April 8, 2015
These are not opposites
(Originally posted 2003.Jul.07 Mon; links may have expired.)
Is "passive" the opposite of "aggressive"? In software development, is "disciplined" the opposite of "agile"? I don't think so.
A passive person may be inactive, but still denies or resists others and context, just like an aggressive person. (Virginia Satir "self, other, context" concepts.) A healthier alternative to passive is "accepting" -- not active, but not in denial. A healthier alternative to aggressive is "assertive" - actively protecting one's self, but not denying the rights of others nor denying the reality of the context.
Dr. Barry Boehm (with Richard Turner) has a book coming out titled Balancing Agility and Discipline: A Guide for the Perplexed. The title does not reassure me that Boehm really understands agile development (in spite of the fact that he invented the "Spiral Development" model - an incremental/iterative process). We know that XP is the one of most disciplined of the agile methods, and that no process will work well with undisciplined people. The blurb from the back cover sounds better than what the title suggests:
Fine, but then it goes back to saying these are opposites:
Alistair Cockburn, on the XP Mailing list, says this about "agile":
Cockburn also wrote:
Brad Appleton came up with a nice definition of agile (notice the first letter of each point):
Is "passive" the opposite of "aggressive"? In software development, is "disciplined" the opposite of "agile"? I don't think so.
A passive person may be inactive, but still denies or resists others and context, just like an aggressive person. (Virginia Satir "self, other, context" concepts.) A healthier alternative to passive is "accepting" -- not active, but not in denial. A healthier alternative to aggressive is "assertive" - actively protecting one's self, but not denying the rights of others nor denying the reality of the context.
Dr. Barry Boehm (with Richard Turner) has a book coming out titled Balancing Agility and Discipline: A Guide for the Perplexed. The title does not reassure me that Boehm really understands agile development (in spite of the fact that he invented the "Spiral Development" model - an incremental/iterative process). We know that XP is the one of most disciplined of the agile methods, and that no process will work well with undisciplined people. The blurb from the back cover sounds better than what the title suggests:
Agile and disciplined: These apparently opposite attributes are, in fact, complementary values in software development. Plan-driven developers must also be agile; nimble developers must also be disciplined. The key to success is finding the right balance between the two, which will vary from project to project according to the circumstances and risks involved.
Fine, but then it goes back to saying these are opposites:
Developers, pulled toward opposite ends by impassioned arguments, ultimately must learn how to give each value its due.... The authors describe a day in the life of developers who live on one side or the other. They expose the bureaucracy and stagnation that mark discipline without agility, and they liken agility without discipline to unbridled and fruitless enthusiasm.
Alistair Cockburn, on the XP Mailing list, says this about "agile":
"Agile" is a value-set, a prioritization of whatever you think it means over
other things.
Therefore, it is not so meaningful to ask, "Can agile be used in this
situation?" Rather, the question is, "How agile can we be in this situation --- How can we be agile in this situation?" ... and then you get various interesting answers.
Picking up the theme of the value sets from my previous append, one might
look at a missile guidance system and say, "time to market not crucial.
people-centric not crucial. cost not crucial. correctness is crucial." In that situation, one could look to blend correctness-prioritized development with agile-prioritized development to get an appropriate mixture of the two.
Cockburn also wrote:
Consider "agile" development as a particular specie of development, e.g., a
Bengal tiger. Then asking "what is the opposite of agile development?" is like
asking "What is the opposite of a Bengal tiger?" Is it an elephant, a mosquito, or perhaps a non-Bengal tiger, or a Bengalese non-tiger?
Brad Appleton came up with a nice definition of agile (notice the first letter of each point):
- Adaptive - plans, designs, and processes are regularly tuned and adjusted to adapt to changing needs and requirements (as opposed to predictive methods that attempt to develop comprehensive and detailed plans/designs/requirements "up front").
- Goal-driven - focus on producing end-results (working functionality) in order of highest business value/priority (as opposed to being task-driven, document-driven, process-driven, or risk-driven).
- Iterative - not just iterative, but *highly* iterative, with very short development cycles, very frequent releases, and exremely frequent+regular feedback.
- Lean - simple design, streamlined processes, elimination of redundant information, and "barely sufficient" documentation and methodology.
- Emergent behavior - quality systems (requirements, architecture, and design) all "emerge" from highly collaborative, self-organizing teams following an initially minimal set of simple, generative rules, and working in very close interaction with stakeholders.
Tuesday, April 7, 2015
Dinosaur Brains versus Survival Rules
(Originally posted 2003.May.14 Wed; links may have expired.)
Way back in 1989, there was a book I read called Dinosaur Brains by Bernstein and Rozen. I thought it was a good read at that time. Their thesis is that irrational behavior, including territoriality, fear, flight, and aggression, are remnants of our reptilian ancestry, and the book gives advice on appeasing and working around these behaviors. By the way, the book is still in print, in paperback.
The problem with this idea is that reptile behaviors are hard-wired... they can't be changed. A better idea is "survival rules" that we learn as children (or later) and apply in sometimes inappropriate situations. When we identify our survival rules, we can modify them.
Wayne Strider's book Powerful Project Leadership talks about survival rules, as does Jerry Weinberg in Becoming a Technical Leader: An Organic Problem-Solving Approach and More Secrets of Consulting: The Consultant's Tool Kit.
An example I read about on a mailing list recently was pair programming. Someone (I think it was Robert Martin, but it could have been Joshua Kerievsky, or someone else), described a programmer that had some difficulty adapting to pair programming.
To make her comfortable with it, she would study the task/problem for some time by herself before pairing. The writer observed that she wasn't comfortable with being asked questions that she didn't know the answer to. Eventually, she got comfortable with pair programming, and no longer needed to study before pairing. It seems to me that her survival rule was something like "I can't show anyone that I don't know the answers" and she successfully modified the rule.
Way back in 1989, there was a book I read called Dinosaur Brains by Bernstein and Rozen. I thought it was a good read at that time. Their thesis is that irrational behavior, including territoriality, fear, flight, and aggression, are remnants of our reptilian ancestry, and the book gives advice on appeasing and working around these behaviors. By the way, the book is still in print, in paperback.
The problem with this idea is that reptile behaviors are hard-wired... they can't be changed. A better idea is "survival rules" that we learn as children (or later) and apply in sometimes inappropriate situations. When we identify our survival rules, we can modify them.
Wayne Strider's book Powerful Project Leadership talks about survival rules, as does Jerry Weinberg in Becoming a Technical Leader: An Organic Problem-Solving Approach and More Secrets of Consulting: The Consultant's Tool Kit.
An example I read about on a mailing list recently was pair programming. Someone (I think it was Robert Martin, but it could have been Joshua Kerievsky, or someone else), described a programmer that had some difficulty adapting to pair programming.
To make her comfortable with it, she would study the task/problem for some time by herself before pairing. The writer observed that she wasn't comfortable with being asked questions that she didn't know the answer to. Eventually, she got comfortable with pair programming, and no longer needed to study before pairing. It seems to me that her survival rule was something like "I can't show anyone that I don't know the answers" and she successfully modified the rule.
Monday, April 6, 2015
Tesugen.com on Documentation
(Originally posted 2003.Jul.04 Fri; links may have expired.)
Peter Lindberg wrote:
Peter Lindberg wrote:
The assumption that lies behind the question You have documented this, haven't you? is that code is inherently unreadable and that there must be a manual to explain it. Many projects indeed are like that. Many projects have grand vapor architectures that exists only in the minds of those who have devised them, and can't be found anywhere in the code. Any document in such a case only reflects the vapor architecture, and is of little help to understanding the code. Let's hope there are still survivors to answer your questions.and
My goal donor asked me, You have documented this, haven't you? to which I replied, No, except for the 570 or so automated test cases Malte and I have written during the course of the project. Each test case captures a micro-scenario in the life of the system, by setting up the objects involved, telling them to do something together, and verifying the outcome. And the fact that they are executable means that a programmer new to a team, besides having an explanation of the code to read, written in code itself, can execute that codee to see if the system still works. So it's better than documentation.
Sunday, April 5, 2015
Extreme Planning
(Originally posted 2003.May.06 Tue; links may have expired.)
Extreme Programming has planning at several levels.
Release Planning, where the entire project is divided into small user-centered features (stories), written onto index cards, estimated by the developers, and prioritized by the story-writer. The story-writer tentatively assigns the stories to iterations (tentative, because the amount of work that can be done per iteration is only a guess when they do their first release plan), with an end-user release planned in three months or so, when enough features will have been implemented to make a release worth-while.
Iteration Planning, where a set of stories is selected by the story-writer (just enough to fit into one iteration as measured by the previous iteration). The developers flesh out the stories with the story-writer and (in some teams) break down the stories into tasks, writing the tasks onto index cards. Many teams put the cards and tasks are put on the wall.
When two developers get together to pair program, they may break down the task (or story) that they are working on into list of tests to do, and a design in UML or whatever notation they think best. This may be written on index cards or a white board. Then they implement one test at a time in test-driven-development.
I asked on the IXP mailing list if people had used the Extreme Programming's Planning techniques (sometimes called the Planning Game) for organizing home chores or other non-work things. Yes they have.
Jiva DeVoe planned a cross-country move on index cards, including estimates, posting them on the wall, etc.
Joshua Kerievsky tells us that Francesco Cirillo, who does XP training in Italy, uses XP-style planning to organize and execute a weekly dinner, with student volunteers doing most or all of the cooking.
Amy Schwab planned a wedding using her techniques of "project community" and "adaptive project methodology". She wasn't familiar with XP planning, but she also used "cards on the wall" (post-it notes instead of index cards). She let go of traditional project "control-oriented" planning, and let family and friends be in charge of "their own quality of experience."
Diana Larsen tells us that http://www.shesintouch.com/ does home chore planning similar to XP's planning, including using index cards, estimates, and measured velocity (and training workshops) [and this predates XP by 20 years].
Extreme Programming has planning at several levels.
Release Planning, where the entire project is divided into small user-centered features (stories), written onto index cards, estimated by the developers, and prioritized by the story-writer. The story-writer tentatively assigns the stories to iterations (tentative, because the amount of work that can be done per iteration is only a guess when they do their first release plan), with an end-user release planned in three months or so, when enough features will have been implemented to make a release worth-while.
Iteration Planning, where a set of stories is selected by the story-writer (just enough to fit into one iteration as measured by the previous iteration). The developers flesh out the stories with the story-writer and (in some teams) break down the stories into tasks, writing the tasks onto index cards. Many teams put the cards and tasks are put on the wall.
When two developers get together to pair program, they may break down the task (or story) that they are working on into list of tests to do, and a design in UML or whatever notation they think best. This may be written on index cards or a white board. Then they implement one test at a time in test-driven-development.
I asked on the IXP mailing list if people had used the Extreme Programming's Planning techniques (sometimes called the Planning Game) for organizing home chores or other non-work things. Yes they have.
Jiva DeVoe planned a cross-country move on index cards, including estimates, posting them on the wall, etc.
Joshua Kerievsky tells us that Francesco Cirillo, who does XP training in Italy, uses XP-style planning to organize and execute a weekly dinner, with student volunteers doing most or all of the cooking.
Amy Schwab planned a wedding using her techniques of "project community" and "adaptive project methodology". She wasn't familiar with XP planning, but she also used "cards on the wall" (post-it notes instead of index cards). She let go of traditional project "control-oriented" planning, and let family and friends be in charge of "their own quality of experience."
Diana Larsen tells us that http://www.shesintouch.com/ does home chore planning similar to XP's planning, including using index cards, estimates, and measured velocity (and training workshops) [and this predates XP by 20 years].
Saturday, April 4, 2015
Fitting In and Standing Out
(Originally posted 2003.Jul.03 Thu; links may have expired.)
A quote from Seth Godin's Purple Cow:
A quote from Eliyahu M. Goldratt's Theory of Constraints:
Extreme Programming is one of those "Purple Cows" that Seth Godin talks about -- it is "remarkable". Its value comes from not fitting in with what the majority of programmers do. It does more testing and more design, and requires more discipline. The documented bug-rate reductions of projects that converted to XP and their improved time-to-market are actually not believed by many, if not most managers, even when the project is within their own company.
"Selling" XP also has to recognize the manager's fears of not fitting in. Heed Weinberg's Laws of Consulting: "In spite of what your client may tell you, there is always a problem. No matter how it looks at first, it is always a people problem.... Never promise more than a ten percent improvement. (If it were possible to achieve more than a ten percent improvement, there must have been a problem, but there isn't a problem, so...)"
I'm looking to the "project community" practices of IXP to help keep an organization from rejecting XP. Retrospectives and Readiness Assessments that include more than just the programmers. Management Tests. The IXP value of Learning.
A quote from Seth Godin's Purple Cow:
If you're remarkable, it's likely that some people won't like you. [...] Criticism comes to those who stand out.
Where did you learn to fail? If you're like most Americans, you learned in first grade. That's when you started figuring out that the safe thing to do was to fit in. The safe thing to do was to color inside the lines, don't ask too many questions in class [....]
A quote from Eliyahu M. Goldratt's Theory of Constraints:
We assume that the openness of these functions [marketing, distribution, etc.] will be enhanced by the positive results achieved in the other functions [production and material...]
What we found out was this is certainly not the case.
[...] The emotional resistance, which already exists, prevents almost any meaningful dialog. The only way to open the Throughput channel in these case was through personnel changes.
The lesson today is loud and clear. Before any function can go on an ego trip, demonstrating and waving results (and by that digging its own grave) -- before any function can start individual improvements, all functions should decide together on a common way.
Extreme Programming is one of those "Purple Cows" that Seth Godin talks about -- it is "remarkable". Its value comes from not fitting in with what the majority of programmers do. It does more testing and more design, and requires more discipline. The documented bug-rate reductions of projects that converted to XP and their improved time-to-market are actually not believed by many, if not most managers, even when the project is within their own company.
"Selling" XP also has to recognize the manager's fears of not fitting in. Heed Weinberg's Laws of Consulting: "In spite of what your client may tell you, there is always a problem. No matter how it looks at first, it is always a people problem.... Never promise more than a ten percent improvement. (If it were possible to achieve more than a ten percent improvement, there must have been a problem, but there isn't a problem, so...)"
I'm looking to the "project community" practices of IXP to help keep an organization from rejecting XP. Retrospectives and Readiness Assessments that include more than just the programmers. Management Tests. The IXP value of Learning.
Friday, April 3, 2015
Test Driven site, Blogger Security, Corporate Cultures
(Originally posted 2003.May.19 Mon; links may have expired.)
Dave Astels points out another TDD resource: http://www.testdriven.com/.
James Robertson points out a security issue with the blogger API: "This is why my posting API uses encryption, and why I don't support the blogger api on this blog - that pathetic excuse for an API passes usernames and passwords in the clear." My blogger friends need to make sure they change their passwords frequently.
Interesting article by Art Kleiner about multiple corporate cultures here: http://www.well.com/user/art/s%2Bb32001.html. He describes three cultures that live within single companies:
He also describes briefly how corporate cultures at the CEO level have changed over time. The most successful companies were "monopolist" until anti-trust laws were passed; "manufacturing" after that—that is vertically integrated "operations" cultures; "marketing-oriented" after the Great Depression and up to the "golden age of advertising in the 1960's"; and "finance-oriented" oriented after inflation hit in the 1970's.
Now that we are living in what seems to be deflationary times, what CEO-level culture will become successful?
Dave Astels points out another TDD resource: http://www.testdriven.com/.
James Robertson points out a security issue with the blogger API: "This is why my posting API uses encryption, and why I don't support the blogger api on this blog - that pathetic excuse for an API passes usernames and passwords in the clear." My blogger friends need to make sure they change their passwords frequently.
Interesting article by Art Kleiner about multiple corporate cultures here: http://www.well.com/user/art/s%2Bb32001.html. He describes three cultures that live within single companies:
- The first, the operational culture, is the culture of day-to-day line managers - the people who get products and services out, procure supplies, process bills, and make delivery trucks run on time. Operations people appreciate teams; they understand, as nobody else does, how to get a bunch of disparate individuals to pull together.
- If you want to find facility with deals, leverage, and capital flow, you have to look to the second corporate culture, the executive culture. Members of this culture typically include the CEO, the board, the business-unit leaders, and the finance-oriented staff.... their jobs and passions lie in shepherding the cash flow that keeps the organization alive.
- The third corporate culture, the engineering culture, is personified by engineers and technical specialists, particularly in information technology and process engineering. They are stimulated by puzzles and problems, and by the design challenge of creating an ideal world of elegant machines that operate in harmony.
He also describes briefly how corporate cultures at the CEO level have changed over time. The most successful companies were "monopolist" until anti-trust laws were passed; "manufacturing" after that—that is vertically integrated "operations" cultures; "marketing-oriented" after the Great Depression and up to the "golden age of advertising in the 1960's"; and "finance-oriented" oriented after inflation hit in the 1970's.
Now that we are living in what seems to be deflationary times, what CEO-level culture will become successful?
Thursday, April 2, 2015
Socratic Questions and Experiential Learning
(Originally posted 2003.Jun.30 Mon; links may have expired.)
One way of teaching, developed 2500 years ago by Socrates, is to ask questions and let the student work out the answers. In Theory Of Constraints by Eliyahu M. Goldratt, the author credits Socratic questions for the success of his previous book The Goal. In The Goal, a consultant helps the main character with advice in the form of questions. The reader follows the main character as he tries to come up answers to the questions; and, Goldratt says, the readers come up with the answers themselves a page or two before the main character does. (I know I did.)
Inventing their own answers motivated the readers to see if the main character came up with the same answers, and in many cases this excitement further motivated readers to apply the lesson of The Goal to their own factories.
Goldratt also talks about the stages of "science" - classification, correlation, and effect-cause-effect. In classification, we could observe that students learn things in various ways. In correlation, we could observe that some students learning via Socratic questions were more excited about their learning than others. In effect-cause-effect, we could theorize why this happens, and use the theory to make predictions which could be invalidated (or validated) by experiment.
Goldratt goes on to say that an experiment may not completely invalidate a theory, but may constrain it. For example, Newton's laws of motion are valid for speeds we see on Earth, but are constrained by other effects when the speeds are near the speed of light.
We can have a theory that Socratic questions can be effective, because someone inventing their own answers feels ownership and the excitement of invention. In some cases they've done a lot of work, and finding the answer is a big reward. However, we can also observe that Socratic questions often fail in practice... the students get irritated by that smug teacher who obviously knows the answers, but isn't giving them out. The resentment can be very strong. The questions can have responses like "Why are you asking us?" followed by arguments about motivations and agendas.
Another style of teaching that also lets the students find their own answers is called "experiential learning." In a typical case, the teacher (or, as some preferred to be called, the facilitator), sets up a "simulation" where the students can try something out in a safe environment, followed by discussion. There's no initial question, just "try this out". In the discussion afterwards, the questions could be "What do you think about X after doing this exercise" or "What were you feeling?" These are non-threatening questions, and students don't feel that the teacher already knows the answer.
In the Agile Development Conference I just attended, some of the workshops used experiential learning. In XP Coaching workshop, facilitated by Ron Jeffries and William Wake, the exercise involved some people coaching other people doing origami (from an origami instruction manual). Some other workshops also involved simulation/practice and discussion.
Ron tells us that XP Immersions that he participates in are doing more experiential learning and less lecture. Instead of lecturing about pair programming, they have the students pair program, probably followed by discussion and reflection on what happened when they pair programmed. The whole point of many training courses is to just get the students to do reflection and discussion - and this is the point of Retrospectives... enabling learning in the organization and team.
Think about learning some skill or getting answers to some of your harder problems, not necessarily a problem with technology; in your own experience, when someone told you the answer to a problem or question, did you value it as much as when you came up with the answer yourself, or practiced the skill by yourself?
One way of teaching, developed 2500 years ago by Socrates, is to ask questions and let the student work out the answers. In Theory Of Constraints by Eliyahu M. Goldratt, the author credits Socratic questions for the success of his previous book The Goal. In The Goal, a consultant helps the main character with advice in the form of questions. The reader follows the main character as he tries to come up answers to the questions; and, Goldratt says, the readers come up with the answers themselves a page or two before the main character does. (I know I did.)
Inventing their own answers motivated the readers to see if the main character came up with the same answers, and in many cases this excitement further motivated readers to apply the lesson of The Goal to their own factories.
Goldratt also talks about the stages of "science" - classification, correlation, and effect-cause-effect. In classification, we could observe that students learn things in various ways. In correlation, we could observe that some students learning via Socratic questions were more excited about their learning than others. In effect-cause-effect, we could theorize why this happens, and use the theory to make predictions which could be invalidated (or validated) by experiment.
Goldratt goes on to say that an experiment may not completely invalidate a theory, but may constrain it. For example, Newton's laws of motion are valid for speeds we see on Earth, but are constrained by other effects when the speeds are near the speed of light.
We can have a theory that Socratic questions can be effective, because someone inventing their own answers feels ownership and the excitement of invention. In some cases they've done a lot of work, and finding the answer is a big reward. However, we can also observe that Socratic questions often fail in practice... the students get irritated by that smug teacher who obviously knows the answers, but isn't giving them out. The resentment can be very strong. The questions can have responses like "Why are you asking us?" followed by arguments about motivations and agendas.
Another style of teaching that also lets the students find their own answers is called "experiential learning." In a typical case, the teacher (or, as some preferred to be called, the facilitator), sets up a "simulation" where the students can try something out in a safe environment, followed by discussion. There's no initial question, just "try this out". In the discussion afterwards, the questions could be "What do you think about X after doing this exercise" or "What were you feeling?" These are non-threatening questions, and students don't feel that the teacher already knows the answer.
In the Agile Development Conference I just attended, some of the workshops used experiential learning. In XP Coaching workshop, facilitated by Ron Jeffries and William Wake, the exercise involved some people coaching other people doing origami (from an origami instruction manual). Some other workshops also involved simulation/practice and discussion.
Ron tells us that XP Immersions that he participates in are doing more experiential learning and less lecture. Instead of lecturing about pair programming, they have the students pair program, probably followed by discussion and reflection on what happened when they pair programmed. The whole point of many training courses is to just get the students to do reflection and discussion - and this is the point of Retrospectives... enabling learning in the organization and team.
Think about learning some skill or getting answers to some of your harder problems, not necessarily a problem with technology; in your own experience, when someone told you the answer to a problem or question, did you value it as much as when you came up with the answer yourself, or practiced the skill by yourself?
Wednesday, April 1, 2015
Practices, Links, and Books
(Originally posted 2003.May.20 Tue; links may have expired.)
Esther Derby reminds us that learning comes from practice and feedback, not just training courses, and links to one of her articles at StickyMinds.
Aside: StickyMinds is the on-line forum associated with Software Testing and Quality Engineering (STQE) magazine, which published my article on adopting XP last year (July/August 2002, order the back-issue!).
Extreme Programming defines "12" practices, though different ways of counting takes it up to 13 or more. Don Wells lists way more than that at http://www.extremeprogramming.org/rules.html. You should know that "they are just rules" meaning that you won't lose your license to program if you break a rule accidentally or with good reason, though failing to follow all of the practices often makes more work for yourself and your team.
Practicing is becoming a popular topic. Ron Jeffries wrote of "etudes" and Dave Thomas is writing about "katas". Other web-logs have discussed this topic, with analogies to music practices, authors writing drafts of papers or books, and so on.
William C. Wake has posted test-first "challenges" on the XP mailing list in the past, for people to practice on, and now has a book called The Refactoring Workbook due in July. Preview chapters are on-line: http://www.xp123.com/rwb/.
On other topics, Mike Cohn is writing a book on User Stories (Requirements/Features in XP lingo) and set up a web-site on this topic at http://www.userstories.com/. I haven't read the chapters that have been made available yet, but I plan to soon.
And David Anderson recommends a book on the agile management mailing list:
Esther Derby reminds us that learning comes from practice and feedback, not just training courses, and links to one of her articles at StickyMinds.
Aside: StickyMinds is the on-line forum associated with Software Testing and Quality Engineering (STQE) magazine, which published my article on adopting XP last year (July/August 2002, order the back-issue!).
Extreme Programming defines "12" practices, though different ways of counting takes it up to 13 or more. Don Wells lists way more than that at http://www.extremeprogramming.org/rules.html. You should know that "they are just rules" meaning that you won't lose your license to program if you break a rule accidentally or with good reason, though failing to follow all of the practices often makes more work for yourself and your team.
Practicing is becoming a popular topic. Ron Jeffries wrote of "etudes" and Dave Thomas is writing about "katas". Other web-logs have discussed this topic, with analogies to music practices, authors writing drafts of papers or books, and so on.
William C. Wake has posted test-first "challenges" on the XP mailing list in the past, for people to practice on, and now has a book called The Refactoring Workbook due in July. Preview chapters are on-line: http://www.xp123.com/rwb/.
On other topics, Mike Cohn is writing a book on User Stories (Requirements/Features in XP lingo) and set up a web-site on this topic at http://www.userstories.com/. I haven't read the chapters that have been made available yet, but I plan to soon.
And David Anderson recommends a book on the agile management mailing list:
What Management Is by Joan Magretta. He's enthusiastic: "This book was nominated by no less an authority than The Economist as one of the 10 best books of 2002. That's what prompted me to read it. In summary - it is worth every cent! It's management summed up in a nutshell."
Subscribe to:
Posts (Atom)