(Apr 24, 2017)
Based on our Scrum Gathering 2017 talk, we discuss the impact on real software development of growing focus on the 'enterprise'.
(Jan 14, 2015)
Actions have consequences. It may be best to be OK with that.
(Nov 22, 2014)
This is an NSFW rant regarding the whiny, mewling *bastards* who bitch, whine, and complain about Agile methods, Scrum, and similar topics.
(Sep 8, 2009)
When terms like Agile or Scrum or TDD get watered down, everyone loses.
(May 7, 2009)
Anything as hokey as this title needs to be preserved. Really.
(Feb 2, 2009)
Many teams seem to get in trouble because they do not have good technical practices. In Scrum terms, they can't get "Done". Is Scrum flawed because these teams do not "discover" such practices?
(Feb 1, 2009)
Some people think that there is a necessary trade-off between internal code quality, and getting things done rapidly. I believe they are quite mistaken.
(Jan 30, 2009)
The amount of context focus is too damn high!
(Jan 15, 2009)
How many times do I have to tell you this???
(Sep 18, 2008)
Pressure only works if I get them done: otherwise it just frustrates me, makes me feel bad, makes me slower still.
(Jul 7, 2008)
Code that slows us down is bad design.
(Jun 11, 2008)
Recent discussions on the lists inspire me to take a radical position. Or maybe it's my life. Or an accident of birth. Anyway: Agile Software Development requires software development.
(Oct 20, 2006)
Dogbert teaches us all a management lesson. He's even offering a diploma. Is that better than a certificate?
(Jun 4, 2006)
A comment from Alan Shalloway, on the Lean Development group, points the way to fame and fortune!
(May 2, 2006)
An allegory? Sarcasm? Humorous pastiche? You decide.
(Mar 12, 2006)
I wrote this answer in response to a question on one of the Yahoo groups: "What is the list of documents produced when you are implementing a pure Agile project?" Martine Devos liked it, so I decided to preserve it here in hopes that someone else might like it as well.
(Nov 10, 2005)
It seems like every development project begins with the date, and we're held responsible for "making the date". Making the date is a management responsibility, not a development responsibility. Here's why.
(Oct 21, 2005)
Delivery of the running, tested, features the customer wants is the purpose of the development team. Sometimes the work we signed up for won't quite fit into the iteration. What should we do?
(Jul 29, 2005)
There's a recent thread on the Scrum list about how an executive or highly-placed manager could get Agile going. I've been one of those guys, and I know a bit about Agile, and here's how I'd proceed. First, focus management attention on cyclic delivery of running tested software. Second, provide the resources to learn how to do that.
(Dec 28, 2004)
These questions were recently asked on the XP group, in the context of a review of Mike Cohn's User Stories Applied. The answers are a function of the whole project, not just User Stories.
(Oct 20, 2004)
It's time to revisit the topic of Big Visible Charts. Display important project information not in some formal way, not on the web, not in PowerPoint, but in charts on the wall that no one can miss. [Updated: Velocity Charts]
(Sep 24, 2004)
It's important to take grammar seriously, even if she has been dead for years.
(Sep 21, 2004)
To every Card, turn turn turn, there is a season, turn turn turn, and a time for every Suit under heaven. It's not the Suits, it's the Game.
(Jun 14, 2004)
Nearly every metric can be perverted, since up- and down-ticks in the metric can come from good or bad causes. Teams driven by metrics often game the metrics rather than deliver useful software. Ask the team to deliver and measure Running Tested Features, week in and week out, over the course of the entire project. Keeping this single metric looking good demands that a team become both agile and productive.
(Jun 23, 2003)
The YAGNI principle says that we should not build any code that we do not currently need. But some parts of our systems benefit from being built from data rather than from code. Therefore if we follow YAGNI we could never build such code. But wait? What about the rules of simplicity?
(Apr 2, 2003)
Frank Gannon wrote this column for New Yorker, if I'm not mistaken, back in 1987. I think it deserves another run. I wrote a year ago for permission to publish, but so far cannot find the copyright owner. It's about flowers and gardens, so perhaps it's appropriate for this Valentine's Day. (Frank found this page somehow and has kindly granted his permission to post the article, which appeared in Atlantic, not New Yorker. Thanks, Frank!)
(Oct 8, 2002)
Wyatt provides a detailed, exciting, and valuable diary of a project moving towards Extreme Programming. Highly Recommended.
(Sep 5, 2002)
We're often afraid that if we don't do enough design up front, our program may bog down and become hard to maintain. This will cause expensive rework, or worse, project cancellation. Simple design with refactoring isn't rework. You may proceed without fear.
(Aug 22, 2002)
Some of the XP practices may be things we want to do all the time. Some we may wish to do only part of the time. When we are really skilled in use of a technique, we're best equipped to decide when to use it. Here are some exercises that may help build skill. And make up your own exercises. Let us know about how they work. Added: Planning Etudes.
(Aug 13, 2002)
Using a simple deck of cards, examine how Extreme Programming gives you a new and better way of managing software.
(Aug 2, 2002)
All too often, they change the priorities and our project gets cancelled, or put on "hold", before it's done. This is frustrating, demoralizing, and wasteful of resources. Ship it before they can stop you! This maximizes the value of your work, and reduces stomach acid, all at the same time.
(Aug 1, 2002)
When you're in a group that serves many customers, your backlog list tends to become infinitely long. You're not sure whether to report on things that aren't being done, or to pretend they are being done, or what. Don't keep a backlog list at all. The result could be greater clarity for your customers, and far less hassle for you.
(Mar 20, 2002)
It is said that by meditating on the words and actions of the masters, we may be enlightened. Sometimes it's just entertaining.
(Jan 21, 2002)
Maybe it's just the name: Extreme Programming. Maybe it's something we said. Whatever the cause, there are lots of misconceptions about XP. From time to time we'll try to correct some of them here.
(Jan 20, 2002)
Bryan Dollery reports on an interesting conversation between Achilles and the Tortoise. This one is about design, or the lack of it, in XP. Thanks, Bryan
(Jan 20, 2002)
Fear is good if there's a tiger in the room. Not so good if there's a bug in the software.
(Jan 16, 2002)
Ellen Ferlazzo, of Sprezzatura Systems, took my rant on documentation seriously. Ellen says that if you do it right, you can deliver the documentation at the same time as the software. I was willing to give the writers an extra iteration. Rock on, Ellen!
(Nov 21, 2001)
Here's a bit of a rant I wrote some time back, talking about how to write the manuals for an XP project by using writers as part of the team. It's a serious proposal, written with tongue a bit in cheek.
(Nov 21, 2001)
"Outside of a dog, a book is man's best friend. Inside of a dog, it's too dark to read." --Groucho Marx Outside your extreme programming project, you will probably need documentation: by all means, write it. Inside your project, there is so much verbal communication that you may need very little else.Trust yourselves to know the difference.
(Oct 21, 2001)
Test everything; eliminate duplication; express all ideas; minimize entities:These few simple rules, applied locally, can help a high quality global design to emerge.
(Oct 7, 2001)
Kent Beck has described XP as designed to go with people's natural instincts. In this short series of articles, we'll take a look at how XP accomplishes goals without a need for lots of discipline or management pressure. In this article, the topic is documentation.
(Aug 30, 2001)
The XP Circle of Life helps keep projects alive. A key aspect of this cycle is the Acceptance Test. Acceptance Tests are critical to communication among team members, especially between customer and programmer.
(Aug 21, 2001)
When unexpected defects arise, it can take a long time to isolate the problem. This can have large and unpredictable impact on the team's progress. Extreme teams release software frequently, keeping their unit tests at 100 percent. The result is smoother progress toward completion, fewer unhappy surprises, and continuing improvement in quality.
(Dec 4, 2000)
An XP approach may deliver more value throughout the entire project.
(Aug 1, 2000)
Houses aren't software. You can build software incrementally.
(Sep 1, 1999)
A somewhat hokey tale about the XP variables, Resources,Scope, Quality, Time.