Category Archives: project management

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.

Share it!

Relaxing After The Orlando Scrum Gathering

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.

Share it!

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.

Share it!

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

Information Radiator 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.

Share it!

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.

Share it!

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.

Share it!

Intro to Extreme Programming

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

Share it!

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

Share it!