SATURN 2010: Notes from Jim Highsmith’s Keynote

These are my notes from Jim Highsmith’s keynote at SATURN 2010. I hope that others who are here will add their notes in the comments below.

Jim Highsmith, Architects: Anchors or Accelerators to Organizational Agility

Philippe Kruchten introduces Highsmith as “the bridge-builder from Flagstaff, Arizona.”

Talk covers what architects can do to make their organizations more agile. It’s the business need that matters: what are the principles, based on the business needs for the system?

Highsmith’s keynote begins with anecdote on development of successful development of SketchBook Pro. They were successful because they had

  1. an adaptable project. Kept technical debt low and were able to be efficient.
  2. agile, adaptive people who were willing to change.
  3. an agile adaptive process.
  4. a chief architect who anticipated needs and built them into the architecture.

“Architects can be the customers of the future,” Rebecca Parsons, ThoughtWorks.

What is agility and should your organization have more of it?

“Without exception, all of my biggest mistakes occurred bacause I moved too slowly.” – John Chambers, Cisco CEO

Plans are wonderful, but they’re a starting point.

What is most important for your organization, responsiveness or efficiency? Is it more important to respond to change than to have efficient operations? Adaptability is responding to unanticipated change. Best to keep cost of change low so you can respond.

When opportunities are small, you have to be able to take advantage of them quickly.

Traditional iron triangle of project management is scope, cost, schedule; agile triangle is value (releasable product), quality (reliable, adaptable product, delivery of future value), and constraints (scope, schedule, cost)

Martin Fowler says architecture is “the hard stuff” — deliver today, adapt tomorrow. Architecture enables adaptation over time.

Are architecture and agile development compatible?

There is a distinction between being agile and doing agile. “There is a difference between being half-assed and half-done.” Agile is half-doing things, sharing, and then getting feedback; iterative development.

Agility is the ability to create and respond to change, the ability to balance flexibility and structure. What’s hard about agile is finding the balance point, e.g., deciding on what constitutes just enough documentation–not too much and not too little.

Core agile values

  • delivering value over meeting constraints
  • adapting to change over conforming to plans
  • leading the team over managing tasks

Are architecture and agile development compatible?

Of course they are.

How architects can accelerate agility to become customers of the future: Be relevant to the people who are actually delivering software. An application-level architecture must know how to code. Don’t look at rework as lost effort. Balance pre-work and rework. Overdoing pre-work is just as bad as having too much rework. “We’re not against documentation, we’re for collaboration.” If you want to get architecture ideas into heads of developers, you can’t do it primarily through documentation. Lesson: take an evolutionary approach to architecture. Make architecture relevant to the development staff.

“Architectures evolve in spite of all our planning.”

Stewart Brand, How Buildings Learn: The way buildings change depends on usage, and you can’t predict usage.

Architects must be architects of time as well as structure. “Time pacing is one of the least understood facets of strategy in unpredictable industries” (Shona Brown, Competing on the Edge: Strategy as Structured Chaos)

Architects are the writers of acceptance tests for migration. Be architects of structure, time, and transition.

Architects should create agile design guidelines. What are the principles behind agile adaptive structures? Anticipated and unanticipated change–responsiveness–keep cost of change low.

Rick Dove, Response Ability: “An organization or systems structure that enables change is based on reusable elements that are reconfigurable in a scalable framework.” Principles:

  • self-contained units
  • elastic capacity
  • self-organization
  • facilitated reuse

Reference to The Spider and the Starfish, Brafman and Beckstrom, starfish as exemplar of adaptability.

Technical debt and legacy systems: Slowly the technical debt of a system builds as new functionality is added. Need a systematic technical-debt reduction strategy. As technical debt increases, customer responsiveness nosedives. This leads to three strategies, all bad:

  1. do nothing, it gets worse
  2. replace application
  3. incremental refactoring, commitment to invest (difficult politically)

Architects need to develop a technical-debt prevention and reduction strategy.

— Bill Pollak, SEI


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s