Agile 2011, the annual summit for all things Agile, is this week. KANA’s own Yukari Huguenard, Agile Program Manager extraordinaire, will be in attendance, along with some 1,600 Scrum evangelists, veteran practitioners and befuddled newbies.

For KANA, as you know, Agile is much more than a software development method. The Agile approach is the heart & soul of Service Experience Management. Agile is adaptation; SEM’s core is the Adaptive Desktop. Agile is about going from moping about change to loving change; SEM is an instrument for change in minutes, not months. Agile relies on retrospecting to improve; SEM delivers the Design-Orchestrate-Listen feedback loop to drive continuous learning. Still, Agile is, in fact, our method for coding SEM, and our team lives Scrum, sprint by sprint.

When you rely on and believe in a Method, you focus, day in and day out, on making it work. You don’t (if you want to succeed) stop very often to contemplate your navel. Sometimes, though, circumstances dictate taking pause. SEM and Agile are core to KANA’s strategy. So, too, is M&A. Acquisitions bring a flow of new teams to our engineering community. These teams are usually Agile in their own way, yet not KANA Agile. Consequently, each integration unleashes fresh perspective, bringing hard questions, new ideas and, in some measure, basic challenges to our Agile way.

Recently, the conversation within KANA R&D has focused on a subject central to Scrum’s future. Bluntly put, new folks question whether KANA’s approach to Agile is hypocritical because it bookends a call for self-organizing teams with pressure to achieve shipment of high-level capabilities within a release. If teams are truly empowered, how can someone outside the team ask for release “commitments”? If teams are supposed to manage their own work agley, how can they be “accountable” for shipping anything in particular, anytime in particular? This topic is peppered across the Agile 2011 agenda, front & center as bastions of the “old way” like the Project Management Institute embrace Agile (PMI).

Seen thru the lens of literalness, the impression of hypocrisy is easy to discern. What the individual engineer hears is ‘the team is self-organizing‘. What the customer hears is ‘Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.‘. If teams can do whatever they want, whenever they want, how ever they want, how the heck does the customer get satisfied?  But, if customer satisfaction requires proximate delivery of certain capabilities within a given time span, and with more or less given resources, doesn’t imposing those constraints on a team sweep away genuine autonomy?

The tension between the developer’s nirvana of being left alone and the customer’s wish for 100% predictability can be mammoth. Account Managers find it incredible that they can’t promise clients that feature X or bug Y will arrive on date certain. Agile can appear to be a fancy name for R&D abrogating all accountability. Engineers are handed “control”, and then see their capacity to operate independently flicker into illusion under the pressure to deliver “early and continuously”. Agile can appear to be a managerial tease.

How come Agile is increasingly popular if this is so rough? Agile arose where life is easy. Start-ups have no contractual obligations to clients. At Google, there are “no deadlines”. There is a portion of the R&D world where the production of velocity is enough, the specific content of that velocity is secondary and the tyrant Time has been banished. But, most  enterprises cannot endure Engineering as a black box that randomly belches forth wonderful new stuff, independent of quarterly financial goals, Launch Calendars, and client expectations.

KANA distinctly does not operate in no-deadline paradise. Our clients have expectations and business-driven schedules. Our field force wants some degree of visibility into what’s coming. We operate, in short, under enormous pressures for “predictability”. Yet, the answer is not to pound the table and imagine that our wish to have predictable delivery of software makes it possible to have predictable delivery of software. Engineers are everywhere the same: they can’t deliver quality code to the clock. The fact that the illusion of control is so tantalizing isn’t a valid excuse for chasing a delusion.

For Jim Highsmith, Manifesto signer, the key to resolving the tension between predictability and adaptability is ‘Riding a Paradox‘.

Success means “facing the tensions of opposing models and instead of choosing one at the expense of the other, generating a creative resolution.” Agile is a common-sense compromise between pretending development is a predictable assembly line and seeing Engineering as an Artist’s Colony engaged in random acts of creativity.

Customers need visibility into roadmap outcomes. Teams need to be self-organizing. Agile is capable of reconciling the Customer for and the Creator of Software, if both realize that the perfect is, in fact, the enemy of the good. Seth Godin has it right: ‘embracing constraints is a beautiful thing’. Half the battle in being Agile, in other words, is sitting comfortably on the awkward contradiction at the heart of Agile.

So, KANA’s Agile means:

• the Customer accepts the inherent unpredictability of software development
• the Engineer accepts that if the business can’t operate, there is no self-organizing team

Living within these constraints has been, I confess, the subject of a lot of retrospecting and a good deal of introspecting. I imagine more of both is in store within our team before we ride Paradox elegantly. In the meantime, we try to honor both the need for predictability & team autonomy by an ever-improving set of compromises.

Our Attributes of Self-Organization:

• Teams determine how much any Feature costs, thereby dictating scope.
• We ask teams to order, in their own way, “business needed” work scoped for a release.
• We empower teams to push any work they desire from the current sprint to future sprints.
• We are okay with teams pushing minimum (not externally committed) work to future releases.
• We work with teams to establish a sizable buffer between externally committed work and their historical velocity.
• Teams have complete autonomy to decide how to break user stories into tasks.
• Teams have no formal leadership.
• Teams have almost complete autonomy to decide how they design, test, and code review their work.

Our Attributes of Visibility & Predictability:

• We ask teams, over the course of a release, to commit to delivering  a “baseline” of  “capabilities” that match to the company’s contractual or client-facing commits, but are down-sized to build-in a substantial buffer below historical velocity.
• Teams  work the set of  user stories necessary to business milestones ahead of those that are not.
• Scrum Masters work with teams to make people and work adjustments necessary to achieve baseline commits, if these are not occurring naturally.
• We have standards for done is done.

Do we ask KANA engineers to commit to delivering some capabilities within a Release? Yes.

Do we ask KANA’s clients to accept adaptation in our roadmap? Yes.

Is this Agile? Highsmith’s answer is emphatically yes:

“I have heard from many managers that some Agile teams don’t want to answer questions like: how much is this going to cost, and how long is this going to take? The response from some of these teams is ‘that’s not agile’. The fact is that companies need some scope and schedule nailed down. It is important to have multi-level plans: company, capability and story, to establish feasibility and broad constraints defining success. There is a difference between iteration and oscillation.”

There is no hypocrisy in saying we need both “predictability” AND “agility”, just a day to day challenge of leadership.

(Mark Angel is EVP and CTO, KANA)

 

 

 

 

Related posts:

1. SEM is Agile
2. The Agile Embrace