You are currently browsing the monthly archive for January 2011.

The “Language Hunting Proficiency Scale” is an adaptation of the ACTFL Proficiency Guidelines for language speaking proficiency. In typical Languge Hunting style, it can understood in a fun, easy, “obvious” way using a party paradigm:

ACTFL Level LH ‘Party’ Level LH Description
Novice Tarzan at a Party Single words, short vocab lists
Intermediate Getting to the Party Ask questions and get answers to get needs
met:  “where/when is the party?”, “what should I wear?”, “what
should I bring?”
Advanced What happened at the party? Recount experience, tell story: “Tarzan drank too much
jungle juice and threw a chair out the window, the cops came and took
him to the drunk tank and I had to bail him out”
Superior Why do we have parties? Discuss social, economical, political, culture nature
of why we have parties

Last month, both Mark Seemann and David Bernstein published a critique of TDD based Read the rest of this entry »


Anywhere you turn these days, people discussing agile development are talking about “delivering value.”  The value mantra resonates with customers and product managers, who want more of it, and developers, who would like to deliver more of it.  But wanting to deliver more value and actually delivering value consistently are two separate things.

As an industry, we work very hard at finding ways to improve our processes.  But sometimes improving the process isn’t enough; sometimes new insights are needed that introduce fundamentally different processes.  For example, TDD (Test Driven Development) went beyond how developers wrote code and how testers then tested that code.  It evolved the process by asking how a developer could know that their code would pass the necessary tests and reordered the sequence of activities (test, then code).

Similarly, I’d like to propose a fundamental change in how we engage customers and product managers to define product requirements.  If we shift from ‘what should we build?” to asking “what we need to build to show value was realized?”, then we will start:

  • Driving the customer conversation, and hence the software, towards the realization of value
  • Creating more innovate software and providing clearer product vision

Read the rest of this entry »

A former work colleague of mine, Steve, recently posted on facebook his enthusiasm during a “hack night” at his current company.  Max Guernsey, who I appreciate greatly as a current work colleague and progressive agile thinker, took exception to the phrase. I assume because it means dirty code and non-sustainable pace (working nights).  Here is part of the dialog:

MAX:  There are two words that seem to me like they should never be associated with what we do in a professional capacity…

STEVE:  wrong choice of words…it’s our autonomy day(s)… a time to work in a beneficial/needed/interesting/G5 project outside the scope of our normal areas of responsibility.

MAX: “Autonomy day” sounds as awesome as “hack night” sounds terrifying.

STEVE:  i wouldnt put too much meaning in when people say hack night…i’ve heard the term much more in the open source stack…it doesn’t have the negative connotation that it does in the .Net world. hack usually means (quality) work outside of (quality) day-to-day work.

I actually think that “Hack Night”, with all of it’s negative connotations, is an assertion of People over Processes (Individuals and interactions over processes and tools) from the Agile Manifesto. A hack implies a blatant disregard for process “rules” in order to produce a quick result (“working software”).

It is a heyoka/coyote technique for balancing our discipline of following the processes to which we elect to commit by periodically questioning those commitments and processes.

Think about it.  What or who exactly are you escaping in order to be “autonomous”?  Your own rules?

It also teaches that learning outcomes may not require all of the tools in our toolkit, and our processes are always contextual.

Marty Nelson

The Agile Architect

Latest Tweets