Things I learned at Agile Up To Here
(This was originally published on Playwell, Alan's personal blog.)
Elisabeth Hendrickson has recently opened a new test-and-development training facility in Pleasanton CA called Agilistry. It’s bright and airy, well-lit and well-stocked, and it feels like home the minute you walk in. In order to publicize her new facility, she very generously hosted a week-long intensive learning exercise.
She invited eleven different people with widely varied skill sets, backgrounds, and interests. She challenged them to build a website in five days using the best practices of interaction design, agile programming, and test-driven-development. We christened it “AgileUpToHere” (#au2h) and it exceeded everyone’s expectations (you can see our results here).
Since it was my 15-year-old homophone web site that was being rebuilt, I nominally played the role of product owner, but I was an observer, an instigator, a goad, and a participant. It’s hard to remember when I had so much fun or learned so much. If you want to learn to be great, I strongly recommend Elisabeth and Agilistry.
Things I learned:
- After 25 years, it’s time to lose the Windows computer and get a Mac.
- Good agile developers are self confident; confident enough to trust interaction designers to do interaction design without distrustful oversight.
- There are lots of programmers who understand that relational databases are not the only approach to solving problems.
- It is time to build software.
- Test-driven-development isn’t fully understood. In fact, software testing isn’t fully understood.
- When even the leanest developer in the room sees really high quality BDUF (big design up front) for the first time, they get all woo-woo and want some for themselves.
- Getting good software built demands the contributions of many different personalities, competencies, and roles, most of which are new and as-yet ill-defined.
- Two programmers pairing can create more and better code in less time than one programmer can (I already knew this, but it’s always good to see it in action).
- Even this jaded old fart can still get excited about changing the world.
- There are many undiscovered and unfilled product niches on the Web, and one of them is “quality”.
- People want a leader with a vision.
- Elisabeth Hendrickson (@testobsessed) is a magical woman. To paraphrase Tom Robbins, “she’s been around the world eight times and met everybody twice.” Like a great chef or symphony conductor, Elisabeth knows how to combine the unexpected to create the sublime. She brought together a dozen people from all over the country, each with different skills, background, desires, and expectations, and then she blended them together into a cohesive, happy, effective team.
- The pre-written code I arrived with was called “legacy” with a grimace, and was quarantined until discarded. Moral: Non-TDD (test-driven development) code is properly regarded like a ticking time bomb.
- For interaction design, you can’t have too many white boards, made from porcelain-coated steel, firmly mounted to the wall. For agile development, that isn’t such a big deal.
- Story-mapping is a major component of the bridge between interaction design and agile development.
- Story-tracking software isn’t quite there yet.

5 Comments
49. This list is bonkers.
50. On the other hand, this makes clear that we don't know *jack shit* about building software yet, fully 40 years into it as a discipline. Why is that?
I'm always amazed at the comparisons people make: two developers pairing are more effective than one developer alone. Obvious and totally useless. How about two developers pairing vs two individuals? How about two individual developer working on related code? How about two developers working on the same feature at the same time with a real-time collaborative editor?
Givas noticed the same thing I did. Two paired programmers producing more good code than one programmer is not exactly a high hurdle to clear.
I trust you meant they can write more good code than *two* programmers.
Andrew,
Thanks for cutting me some slack. If I had had a colleague sitting next to me when I wrote this list, that mistake would not have survived.
thanx,
Alan
Alan's comeback FTW!
45 intrigues me. It states that Experts don't know how to create an Expert. Research has also shown that the Unskilled often don't realize that they are not Experts.
Given that our job is, through design, to turn people into Experts as quickly as possible, wherein lies the happy medium?
Post a comment