cooper

Journal   A blog about design, business and the world we live in.

Things I learned at Agile Up To Here

by
on | Comments (5)

(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:

  1. After 25 years, it’s time to lose the Windows computer and get a Mac.
  2. Good agile developers are self confident; confident enough to trust interaction designers to do interaction design without distrustful oversight.
  3. There are lots of programmers who understand that relational databases are not the only approach to solving problems.
  4. It is time to build software.
  5. Test-driven-development isn’t fully understood. In fact, software testing isn’t fully understood.
  6. 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.
  7. Getting good software built demands the contributions of many different personalities, competencies, and roles, most of which are new and as-yet ill-defined.
  8. 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).
  9. Even this jaded old fart can still get excited about changing the world.
  10. There are many undiscovered and unfilled product niches on the Web, and one of them is “quality”.
  11. People want a leader with a vision.
  12. 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.
  13. 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.
  14. 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.
  15. Story-mapping is a major component of the bridge between interaction design and agile development.
  16. Story-tracking software isn’t quite there yet.

  • Data-miners think differently. I don’t think like a data-miner.
  • The Union Pacific Railroad, headquartered in Omaha, is not as “Dilbert-y” as it might seem.
  • There’s an app for that.
  • Pointy-haired managers are soooo counter-productive.
  • While I cling to my tree-based books and papers, bit-based books and papers are actually more capable in many ways. Is my nostalgia based on familiarity rather than quality? Did you just feel the Earth move, too?
  • Social programming.
  • While everyone expounds breathlessly about browser-based apps, they still spend the lion’s share of their time using native, client-side apps.
  • Software patterns are a powerful tool.
  • Sometimes there’s a necessary part of a program that is just ugly. You can refactor or reconceptualize it, but instead of shrinking it, you’re just moving the ugly part around. I call this the “Irreducible Nugget of Ugliness”, or INU.
  • I love inventing new TLAs.
  • While easier than it used to be, it’s still hard for an old software guy like me to keep his hands off.
  • Some people are perfectly content to not know about the personas and they still get good work done right.
  • There’s nothing new under the sun.
  • At a granular level in software development, what used to be easy is hard, and what used to be hard is easy. At a broader level, creating good software still remains one of the most difficult things you can attempt.
  • The power of web development and modern tools is so great that it tempts even me to de-emphasize the user’s goals.
  • I worry a lot about applying an indelible Sharpie to a precious whiteboard.
  • Face time is vital when you are creating. If you are creating a product, you need face time with the product team; if you are creating a company, you need face time with everyone in the company.
  • Flickr is a steaming pile of software.
  • The only way to really get to know individual people is by devoting attention and time to them. The only way to really get to know your craft is by devoting attention and time to it. This is most definitely not a coincidence.
  • There are still a few bugs in the system.
  • The road to mastery is simple: just imagine the problem-set as being far bigger than everybody else does, and then give it attention appropriate to its size.
  • When you’re in the groove, there’s no 9 to 5.
  • When you finish something, ring a bell.
  • Dale Emery (@dhemery) said “I can give you a silver bullet, but be aware that you might be the werewolf.”
  • Candy remains a powerful motivational tool in the software world. Or maybe it’s just that the brain requires lots of cheap energy.
  • When you own something, you lose a lot of perspective about it.
  • Product ownership is far too complex and important to be left to amateurs, even if they actually own the product.
  • It’s okay to sit down during a Stand-up.
  • When you are really good at doing some job, you are usually unaware of the important nuances that make you so good.
  • Establish one really big goal, then establish lots of little, intermediate tasks that will get you to your goal. Then celebrate each task as you achieve it.
  • Model-View-Controller.
  • At a certain point the barriers to entry fall so low that no excuses withstand scrutiny.

    • 5 Comments

    Thomas
    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?
    Givas
    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?
    Andrew Binstock
    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.
    Alan Cooper
    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
    David C. Dunkle
    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

    We're trying to advance the conversation, and we trust that you will, too. We'd rather not moderate, but we will remove any comments that are blatantly inflammatory or inappropriate. Let it fly, but keep it clean. Thanks.