January 06, 2012

Pittsburgh Ruby Talk: Software process

Who? Andrew Clay Shafer, @littleidea (puppet, conferences, involved/writing on devops)

When? 5-January-2012

What? Great, inspiring talk on software process, different types of agile and their core meanings (rather than the headlines people echo, often mindlessly) coming from someone who has obviously thought about these for quite a long time and internalized some deep lessons.

(these are my minimally translated notes from the meeting, they won't all necessarily make sense out of context)


  • first impression: hated it
  • scrums: felt like lots of STUFF, not much getting done
  • beware the expert
  • some people say 'agile', they mean 'scrum'
  • Salt Lake Agile Roundtable: Alistair Cockburn (!!!) runs it, 2-5 on the first thursday every month (during work, it's serious!)
    • mix of companies (novell, motorola, startups) and people
    • went there to get ammunition, but what he found was more interesting (smart people discussing ideas)
    • image from Crystal Clean (context for everything) (size vs criticality)


  • frequent delivery
  • reflective improvement
  • close/osmotic communication (speed with which ideas can move thru organization)
  • personal safety (willingness to put yourself out there)
  • focus
  • easy access to expert users (your customer!)
  • automated tests, configuration management, frequent integration

Context matters

  • criticality
  • size
  • scope
  • schedule
  • contractors (interfaces and coupling; who does the interfaces? -- how big is your tribe? ==> conway's law)
  • distributed

MVP: Mimimally viable process

  • XP: Jedi of agile (if only Kent Beck would come out of the swamp)
  • Lean: Mary Poppendeck (first person to bring lean into software; mostly about building businesses and building pipelines of value)
  • Kanban: (feel it's the most useful way to build software right now)
    • focus on quality
    • reduce WIP
    • deliver often
    • balance demand against throughput
    • prioritize
    • attack sources of variability to improve predictability
    • visualize the flow: if you see a bottleneck, you can stop the line and get the whole team involved
  • Lean startup: read "Four Steps to the Epiphany" before "Lean Startup"


  • hardest thing to do: inspect and adapt
  • cargo culting: all ceremony, no substance
  • ARxTA (Brian Marick): We believe Agile software development is being dumbed down... (full quote)
  • Working software is the primary measure of progress (like from the Agile Manifesto)
  • OODA loop: Observe, Orient, Decide, Act; Building vs Planning: but why are we building it?
  • David Hussman, Dude's Law: Value = Why / How
  • @ salt lake thing: moratorium on talks on estimation, it's too hard


  • hardest thing in software is capturing the vision
  • Antoine de St Exupery quote ("...vast and endless sea")
  • user story is a promise to have a conversation, not a spec!
  • backlog is a ghetto... where stories go to die
  • story mapping: write stories that capture the whole value (embrace the epics, we need to know this stuff!); what's the minimal span of those stories? this is the 'walking skeleton' => do enough to get the skeleton moving


  • we design systems, why don't we design teams?
  • different strokes (meh)
  • CAP theorem: applies to people, too! -- if you require consistency, you give up availability: meeetings are global locks (is P related to co-location vs distributed?)
  • Six laws of reliability (Joe Armstrong, Erlang): isolation, concurrency, failure detection, fault identification, live upgrade, stable storage => apply this to process (live upgrade => bringing on new people)
  • FSOP cycle (flying by the seat of our pants):
    smart people FSOP >
    successful patterns emerge >
    patterns recognized and adopted as process >
    structures created to drive/moniotor process >
    process becomes painful >
    smart people reject the process >
    (start from beginning)


  • really like kanban
  • like XP tech practices
  • focus on quality
  • everything depends on context, but in context make policies explicit (this is fuzzy to me -- true that everything depends on context, but there's a tension with too much +/or the right kind of policy, e.g. "what's in your coding standard doc?")
  • if something doesn't feel right, you're doing something wrong; might be that thing, might also be you...
  • if you aren't getting results, change something
  • if you're changing too much too often, you won't get good results
  • measure (but don't get caught up in vanity)
  • process is a competitive advantage, passion is a competitive advantage, but don't let process kill passion
  • smart people solve problems

Q + A

Q: heard it said that scrum is kind of training wheels for kanban/lean, true?
A: more reason for people to sell scrum; kanban is easier!

Comment: Agile manifesto says "people over process", but agile people are obsessed with process!

Next: Ella's latest
Previous: Physical precision