Thoughts after agile training: strengthening values, reducing the cost of honesty, and growing apps

I recently completed ScrumMaster training ably presented by Lyssa Adkins. Throughout the two-day class we appreciated Lyssa’s Zen-like, enabling, style. If her name is familiar, it’s because Ms. Adkins is the author of the book Coaching Agile Teams, one of the leading texts on the subject.

I’ve participated on agile projects, but so far only in a piggish/chickenish role, once in a three-week stint as a consulting architect and twice as the project manager serving as interface to the non-agile organization.

To me Ms. Adkins rocks at making students very introspective and critical of their past project experiences.  These lessons stand out:

Strengthening values

Agile methods, as Ms. Adkins presented them, are absolutely uncompromising.  The foundation values of the technique are Commitment, Openness, Respect, Courage, and Focus.  When these values are sound, motivated teams deliver creative products on time. Sacrifice of these values results in proportional losses in team cohesion, creativity, and productivity (or “velocity” in agile-speak). The result: stressed teams deliver mediocre work after project delays.  The consistent implication was that if you take care of the values the mechanics will follow.

That squares with my own project experience. I suspect I’m hardly unique in being lucky enough to have served in various roles on a few very successful projects: among them a military medical data warehouse, bank integration involving a Fortune 500 company, and a raw materials tracking project for another Fortune 500 company.  Without exception these projects involved a mutually supportive, committed, co-located, and rather rowdy team having fun doing good work. Those other projects that did not go so well suffered various combinations of teams that were not-so-mutually-supportive, not-so-committed, remote (either geographically or in terms of focus), or starchy.

Reducing the cost of honesty

Another feature of the agile method is that it is divided into two- or three-week iterations. Setting aside the technical challenges for now, if a team doesn’t keep its promises the project only loses two or three weeks.

Anyone who has been around the block in application development has probably been on the death march.  Everyone on the project is working long hours in a stressful atmosphere to meet an objective that they know isn’t possible, but official channels stubbornly report an optimistic “green” to those outside the project for weeks or months after the team raises alarms.

The reasons for project difficulties that result in the death march vary widely: scope shifts that come too late to be built into the plan, unanticipated technical complexities, failure to achieve optimistic early targets, and more.  Whatever the cause, management sees the rosy picture as the path of least resistance and avoids acknowledging increasing project troubles as long as they can.

Proponents of the agile technique recommend total and complete candor in reporting outside the project at each iteration break.  This in effect reduces the cost of honesty for the project manager.  The assessment and planning break between iterations allows everyone the chance to readjust expectations for the next three weeks.   Over time, planning becomes more accurate as the organization learns how to set correct objectives and the team learns how to meet them.

Grow (rather than build) your applications

OK, now for those technical challenges. My field is data management, and the steepest hill to climb is how to deliver real business value in each three-week iteration.  In his recent post on the topic Ben Harden outlines how this can work for data warehousing and BI.  Scott Ambler provides a detailed treatment of agile best practices for data warehousing here.  Both recommend appropriate requirements and architecture prep work followed by cyclical delivery of real business value with each iteration.  Data modelers will be particularly interested in Mr. Ambler’s evolutionary approach, which evolves the right components of the model just in time rather than building it all up front.

 

As for me I’m looking forward to being a pig not a chicken.  I want to have fun delivering value frequently to delighted business customers. Let’s get started!

 

2 thoughts on “Thoughts after agile training: strengthening values, reducing the cost of honesty, and growing apps

  1. Wendy

    Great article. A previous team practiced agile methodology for 3 years. Current management is initiating sprints. i appreciate this fresh outlook, thank you!

Leave a Reply

Your email address will not be published. Required fields are marked *