Agile Learning Labs

"Embrace change to add more value!" and other "aha!"s

by Hillary Johnson

Every time we run an Agile Project Management class we tweak it slightly, based on what we've learned in the last one. Inspect and adapt, as they say... err, I mean, as we say.

One thing we noticed happening over an intensive two days period is that people tended to generate many more insights than they can retain. "Aha" moments that seem memorable at the time have faded after the two day barrage of new information. How to capture the spontaneous learning as it occurs and preserve it, without disrupting the flow?

Our solution: Create an "aha!" wall where students can capture their immediate insights by putting up sticky notes at any time during the two days. These ahas formed a significant part of our retrospectives at the end of each module, and make a fantastic mnemonic take-away.

As we strive to structure our workshops to resemble agile projects as much as possible, we framed these ahas as representing the "learning value" the students were generating during each educational "sprint." Needless to say, this maps quite nicely to "business value" and demonstrates the beauty of incremental delivery in a tangible way.

This week we had thirteen very bright students show up for a two day workshop offered through the Bay Area chapter of the PMI, most of them PMPs, some with a high level of agile awareness, others new to the field.  Here are some highlights from their wall of over fifty "aha!"s. Reading over them, I think these could easily be chapter headings for a book on Agile Project Management:

Retrospective = lessons applied = improved output and flow.

Fail safely; fail softly!

Work becomes fun!

Things that are visable get more attention--and get done!

Embrace change to add more value.

If you won't need it, don't do it!

Responding to change means changing the plan.

Document to the extent that value is added to maximize ROI.

Focus on done, not doing.

Slow down to increase output.

Early delivery, early revenue = "compound interest"

A lot of the students in this class expressed an interest in returning for our upcoming Certified Scrum Master Training on August 12 & 13, which Chris will be co-teaching with the inimitable Jeff McKenna, which we have yet to formally announce. If you want to join them for some more ahas, save the date and either join our mailing list or check back early next week, when we should have details and a registration page.

Yes you are comprehensively documenting your agile project--just not in English

By Hillary Johnson

If I were re-writing the Agile Manifesto and I wanted to express agile values in terms that spoke positively to the project manager's realm, rather than defining agile in opposition to it, I'd state the third value ("Working Software over Comprehensive Documentation") like this: The best documentation is the product itself.

How did I get here? We had a fantastic yesterday, delivering our Agile Project Management workshop to 13 quite knowledgeable individuals from all sorts of backgrounds. When the group is this experienced, we always learn as much as they do, and one of my "ahas" came when Lisa Winter expressed a pain point PMPs often experience during agile adoptions, especially when the organization is large and long in the tooth:

What do you do when you're caught between the rock and the hard place? ie, you need to run an agile project in an agile manner, but you also need to provide traditional reporting upstream. Do you make like Allen Stanford or the Mafia and keep double books? Or clone yourself and give the waterfall stuff to your evil twin? I hope not!

What Lisa wanted to know was, how can I cut down on this particular form of overhead? Where do agile metrics map to traditional metrics and where don't they?

So how do these things map? Take documentation. A great deal of confusion surrounds the nature of requirements and documentation in Agile, and it’s often put forth—mistakenly—that Agile eschews documentation. While it is true that in Agile development, working software is favored over extensive documentation, this doesn’t mean you don’t document requirements—it means that you and your team document these requirements quite comprehensively indeed at the end of every sprint--but you document them in Ruby, Perl or C++, not English!

This isn't some crazy cowboy agilista indulgence. In fact, there are industries built upon this notion of product as documentation, aka copyright law. And with the recent extension of copyright law to cover software it's no longer mere analogy. The code itself is the sole document on which basis protection is granted--just as the text of The Shining is the only documentation Stephen King produced to obtain his copyright. This is why I think that, while I heartily endorse it's intended meaning, the agile manifesto's implication that comprehensive documentation is frowned upon isn't an entirely accurate statement--what more comprehensive documentation is there, after all, than working software? And if it's proof enough for Uncle Sam, it might need to be proof enough for the VP of Product Development.

But, you say, this isn't documenting requirements exactly, because it comes after the fact. Does it really? Your first working software will be delivered months, possibly years, before a traditional requirements document would have, so maybe the working software really does fulfill the requirements model after all.

Maybe the answer to Lisa's question lies in translating Agile concepts and mapping them to traditional  values, if not practices.  It might be worthwhile to demonstrate to people who are, quite reasonably, invested in their own histories and bodies of knowledge, that despite radically different approaches, the actual values--quality, timeliness, transparency, value, etc., are the same.

Or am I getting it all wrong by implying that Agile means wrapping your ankle behind your ear to make a point?

Agile Ontologies: Why the customer is always right, even when they're wrong

Craig Brown voiced a common concern project folks have in "A Downside of Agile Development?" on his Better Projects blog, writing about his fears for his company's proposed transition to Agile:

I use a few online services, and you can tell which ones have adopted the philosophy of incremental product roll-out.

Just about every time you log in, there is another feature being promoted and presented to you for consideration.  Sometimes things you were used to have moved or disappeared.

This constant change makes some products less appealing than something that is more reliable.

There are valuable lessons to be gleaned here about what Agile is failing to communicate to customers. I like to think that the customer is always right, even when they're wrong, and if they're having a problem, then there is a problem. Brown is making visible a world view problem that is hindering agile adoption.

I left a comment on Brown's blog trying to reframe the question. Here it is:

This seems more like a web design  problem than a development problem to me. A product can be designed from the outset so that you can add to it without disrupting the work flows users have established. A top level menu system whose categories are general enough that you can fit almost any new feature under them, for example, allows you to release new features iteratively and allow users to discover what they need as the need arises. The problem may lie in treating each new feature as a "release" by shifting features around and making big front page announcements ala "Now with extra cleaning power!!!!" Constant improvement is not a series of events, and every addition doesn't need to be celebrated. Most of the time, it's enough to blog the new feature and move on. This is better than saving up features and doing a faux release. Why would you make an innovative new process mimic an obsolete process? Better to adapt how you think about the product instead.

I think I only captured part of my thought process in the comment, so here's the rest of it:

The takeaway is that often the resistance to Agile, or any other new way of doing, working or living, springs from underlying assumptions that aren't being unearthed and challenged. These assumptions are not ignorant--they are unconscious, and based on experience. As change agents, it's our job to challenge and persuade, not the other way around. For a customer who has lived through Vista or iTunes 8, and maybe a buggy beta or two of their own product, announcing happily that Agile will allow you to release every week will justifiably cause panic and soulful dread. Better to say, "We can make it so you never do releases. We build and test constantly behind the scenes, and add new features without disrupting your users' workflow. You'll never have a beta or a bumpy release to contend with."

Paul Graham wrote years ago that "...designing Web-based software is like designing a city rather than a building: as well as buildings you need roads, street signs, utilities, police and fire departments, and plans for both growth and various kinds of disasters." This high-level re-imagining is what Brown really needs to hear--he needs the shining city upon the hill, and for the leap of faith we're asking him to make in joining the revolution, he ought to get it.

Someone in the audience at the Scrum Gathering keynote last week reminded us that "A good trainer can lead a horse to water, but can't make them drink. A great trainer can make them want to drink." It's not enough to offer the customer better solutions and value, we have to offer them a vision of a better world; we can't focus on delivering processes and tools; we must focus on individuals and interactions.

There's still room in monday's public class on Agile Project Management

Chris and I are at Disney World for a few days of R&R after hosting the Open Space at the Orlando Scrum Gathering, but the park will have to be pretty supercalifragilistic to compare to the conference, which was wonderful. So much engagement--250 people there, and yet it felt intimate. I left feeling I had got to know more people than I'd normally meet in a year. Check out the wiki to get to know some of them yourself.

There was a large PMI presence for the first time ever, and despite some joking by the Scrummies about feeding them to the alligators in the hotel's atrium, a lot of positive, productive interaction occurred--there was a meeting of hearts if not quite of minds... yet.

Speaking of the meeting of hearts and minds, on Monday, March 23rd, we'll be back in the Bay Area and Chris will be leading a full-day workshop on Agile Project Management at the SD Forum offices in San Jose. Lots of experiential learning in this one. We have had a great response, and you'll be joining a group that includes PMPs at large and small companies, as well as job-seekers looking to add marketable skills to their resume. Visit the TMI Website to find out more of the basics, or go straight to the registration page to see special recession-buster pricing, a course description and the gritty details.

Is there such a thing as Agile Project Management? Gosh we hope so...

... because Chris is leading a day-long public workshop on Agile Project Management on March 23rd, at the SD Forum offices in San Jose.

The question, however, is one being hotly debated between Australian PM guru Pat Weaver and assorted commenters on his blog, in a post titled Agile is NOT a Project Management Methodology. Weaver claims that "Agile is not an IT project management methodology any more than choosing to use pre-cast concrete in preference to brickwork is a construction management methodology."

He goes on to say, "What is lacking in most commentary I’ve seen on Agile is any sensible discussion on using Agile within a project environment. The critical changes to scope management, change management, cost management and time management needed to effectively deal with the fluidity of Agile, within the constraints of a project, need discussion."

Ah, good point. This is just the kind of stuff we hope to address in the workshop. How does Agile work in conjunction with project management--and how doesn't it? Weaver actually hints that traditional project management may not be all that compatible with Agile--although in a subsequent post on Managing  Agile Projects he goes into some rather brilliant detail analyzing just how agile and PMBOK can work together, concluding ultimately that they can and do go together quite well: 

...align the PMBOK to an Agile project delivery method and the overarching PM process will enhance the probability of success. Treat an Agile project in the same way as a traditional Waterfall project and the PM processes will guarantee failure!

Intrigued? Read the rest of Pat's writing, then come on out for the class! We promise to elucidate further, and cover all of the finer points of applying project management techniques in an agile environment, including:

• Estimation
• Release planning
• Prioritization
• The rhythm of iterative development and delivery
• The flow of deliverables
• Roles and responsibilities
• Communication on an agile team
• Empirical process control
• Agile metrics
• Simple tools for managing agile projects

To register for the class, click here. If you see Chris or me at P-Camp, or SD West this week, hit us up for a flyer.

This week on InfoQ - Information radiators: Is low-tech really better?

In this week's InfoQ article, Chris covers the debate over high tech vs.low tech toolsets (what Alistair Cockburn refers to as information radiators) for managing agile projects: eg, which is the lesser evil, killing a tree and taping its carcass to the wall one notecard at a time, or clicking through an annoying heirarchical menu every time you want to see your data?

The focus of the article is a discussion thread on the Xtreme Programming Yahoo Group, where topic is being contested with a great deal of heat.

There is a natural tendency among technologists to prefer technological solutions, but many of the debaters claim that experience has shown the low tech solutions to be best. Ron Jeffries says:

Display important project information not in some formal way, not on the web, not in PowerPoint, but in charts on the wall that no one can miss....A web site doesn't push information at us; we have to go look. A slide show always comes with a meeting and a lecture. A wall chart is there when we are, in our face, always visible.

This makes intuitive sense to me. I think there's something important about making the whole visible at a glance. Imagine how hard it would be to read a novel if there were one word printed per page--we read words in context, not in isolation. I think we experience projects much the same way, and it's important to always have a view of the gestalt.

The Agile Tools blog has an archival post that features pictures of several examples (as pictured) of both virtual and physical task boards. It's interesting to look at them and see which ones make you want to be on that project.

See you at P Camp

Apparently you and your entire extended family have already signed up to attend P Camp, as registration is now closed at 550 sign-ups. There is, however, a hint that it may be opened up again should host Enthiosys figure out a way to lay folks head to foot instead of end to end and squeeze more of them into the Yahoo Campus venue. We hope so, and will keep you posted!

For those of you who missed last year's camp, it is a one day unconference for Product Managers, meaning that any attendee can propose and lead a session on any topic they like. Last year, Chris led a session on Why Agile Projects Succeed (or Fail) and packed the house for an Agile 101 session. There were so many good questions he didn't get through all of his material. Here is a blow by blow description of everything that happened at P-Camp last year.

This is a superbly organized event, with a great website, a facebook group, a linkedin group, and a wiki that people actually use. Apparently someone there knows how to manage a project.

PMI Workshop: The Most Effective Tools & Techniques for Project Managers

Chris recently had the pleasure of facilitating a lunchtime workshop as part of PMI Silicon Valley and SDForum's Tools & Techniques series. A group of 23 Project Managers turned out to discuss "The Most Effective Tools & Techniques For Project Managers" using the Group Wisdom Without Groupthink (GWG) structured brainstorming method.

GWG begins with a round-robin survey of the entire group to elicit ideas, which are posted on the wall. Next, participants vote for the items they think most important and the results are arranged in tiers. Here are the results:

Tier 1: 11-15 votes

Web conference tools

Well-defined metrics

Dashboards

Scope management

Project meeting w/agenda

Proactive risk management

Brainstorming session

Project stage gate reviews w/all key sponsors

Face-to-face kick-off

Fist-of-five

Tier 2: 6-10 votes

Management by walking around

Status reports

Repeatable release process

MS Excel

Sharepoint

Resource management

Stakeholder management

Tier 3: 1-5 votes

Tools for change management

Resource allocation matrix (RAM)

Portfolio management

Acknowledge success

Post-meeting buffer

Work breakdown

Social collaboration

Effective open-ended questions

Process workflow w/visio

Requirements trackability

Setting team ground rules

Weekly status for subject matter experts (SMEs)

Short-term goals

MS Project

Adaptive project management

Project dream list

Case complete

Version control tools

Quindi

Managing up

Determine costs of being late

Global collaboration - video

Tier 4: 0 votes

User contextual inquiries

Preview of materials

Groove

Going down a rat hole

Skype

Scrum meetings

Group Wisdom Without Groupthink works well with all kinds of groups, both technical and non, but clearly the project managers had a special affinity for the exercise, as participants rated it an average of 4.75 out of five, leaving comments like, "a very useful technique that I can implement right away."

Here is a similar workshop Chris ran on the topic of What Makes Agile Projects Succeed (or fail)? at Agile Open California 2008.

Intro to Extreme Programming

Photo courtesy of akindemir

This past Wednesday, I presented a 45-minute introduction to Extreme Programming (XP) to the Project Management and Program Management Special Interest Group, who meet every week Cupertino. The group was lively and full of questions. I especially enjoyed the chance to discuss XP, as that is where I got my start doing agile software development, back around the turn of the century.

Contrary to popular belief, Extreme Programming (XP) is not writing code while kiteboarding. Extreme Programming is an agile software development methodology created by Kent Beck in the mid nineties, while he was the leader of a large software project at Chrysler. The true genius of XP was selecting a set of 'best practices' that compliment each other and form the foundation for extreme productivity, extreme adaptability, extreme quality, and extreme satisfaction for every stakeholder in the software project.

Here are the slides, and here are some links:
A Gentle Introduction to Extreme Programming
Wikipedia on XP
The original home of XP on the Portland Pattern Repository
A set of XP links, including tools

XP for Project and Program Management SIG

Greetings,

Tomorrow morning I'll be giving an 'Intro to Extreme Programming' talk for the Project Management and Program Management Special Interest Group in Cupertino. The event is open to the public, and group asks for a $2 donation from each participant. We will be giving away a copy of "Planning Extreme Programming" by Kent Beck and Martin Fowler.

When:
July 9
7:30 AM - 8:00 AM Informal Networking
8:00 AM - 9:00 AM Presentation

Where:
UCSC Extension
10420 Bub Road
Cupertino, CA 95014
(408) 861-3700

Cheers,

Chris