JavaOne 2006: Scott Ambler on Agile

I’m at Scott Ambler’s session on Agile methodology. It’s quite
good. Once the audio of it gets online, I highly recommend all you
folks using Agile in large organizations look at. The message is this:
chances are, you could be doing a lot better, and your people probably
don’t want to or don’t know how to tell you that.

“Stupid”

The first thing about Ambler, is that he uses the word “stupid” all
the time. There’s nothing wrong with that: there’s a lot of that going
on in software development, and we as a community need to be more
vocal and repetitive at pointing it out, hopefully to people who
aren’t already in the choir.

Agile Sieves

The presentation essentially lays out a method of evaluating the
practices in software development, each time asking the question,
“does what you’re doing help you shift software? If not, stop doing
it.”

For example, he said that when he goes to visit teams, he asks them
these two questions:

• Show me your tests and run them right now.
• Who are your stake-holders?

Chances are, the teams at most large shops couldn’t answer those
questions effectively, esp. the second. In fact, I would argue that
stake-holder management and process is the weak length in Enterprise
Agile. Product management is extremely difficult and much more different
when you’re an Agile organization.

The Troubling Role of Non-technical Product Owners

When you look at Scrum, for example, the role of product owner is
the single point of requirements and product decisions. That’s the
ideal, of course. Typically, these roles aren’t filled by people who
are technical enough to direct the feature set of software. Someone
stood up and asks Scott, “but the marketing people don’t know to add
features like scalability, clustering, and other technical things, so
how does this work?”

And in what’s been the typical line from Scott, he said, “sure,
you’ve got to make sure your stockholders are smart people. If you’re
stupid, you’ll get burned. Welcome to software development.”

Practices

In addition to laying out simple ways to evaluate the effectiveness
of a teams development practices, he presents several practices and
muscly rhetoric for each (you can go look up the academic arguments
later if you want).

For example, he’s quite big on pair programming. He says, “If your
manager is preventing you from doing pair programming, figure out how
to make him get to go fetch you a cup of coffee or do something
useful.”

Notes & Highlights

Here are some good quotes and points:

• “SOA? That’s CICS with XML! That’s 1970’s stuff and we’re still
  thrashing on it.”
• “Stop playing politics and start doing your jobs.”
• “A really serious problem with your organization is if you think
  traceability matrixes are going to help you. Put a bullet in your head
  now.”
• One of the problems with Agile is that it forces people to do their
  job. So managers and business people and developers have to do their
  job, and this is what companies struggle with.
• “You’ve got to be a generalizing specialist. The problem with
  specialists is that they do their job…whether they need to or
  not. If you’ve got a use-case specialist, they write use cases whether
  you need them or not.” When you have specialists who don’t know the
  context of the software they’re working on, they don’t know how to
  most effectively do their job (or not do them!) to write and ship good
  software.

Disclaimer: Sun and IBM are clients.

Technorati Tags: agile, conferences, javaone, javaone2006, programming, projectmanagement