Do Something Appropriate

On Christmas Eve 2008, I happened to catch this phenomenal broadcast on National Public Radio describing how the Apollo 8 moon mission still awes us 40 years later.  Besides moving references to the first pictures of the earth rising over the moon's horizon and Archibald MacLeish's essay in the New York Times, there was something that struck my attention -- the guidance given to NASA commander Frank Borman: "do something appropriate."

Despite the background context of the turbulent times of 1968, the race to space with the Soviet Union, and a change in mission direction decided only 4 months before, NASA deferred the decision on what to broadcast to the entire world on Christmas Eve -- to the person doing the work.  NASA management did not micromanage what was, at the time, the largest broadcast in human history.  The decision to broadcast the first 10 verses of the King James Bible was made completely by Borman.  According to Borman (about 01:27 of the broadcast), "the only instructions that we got from NASA was to do something appropriate."

Nowadays, in my pro bono work, I spend time supporting project managers who are looking at making the transition to Agile methods.  For many of these managers, giving up the action oriented skill of directing work top-down can be very, very difficult.  When tempted to control our teams more than necessary, perhaps we can all take inspiration from the incredible example of NASA, and instead simply advise them to, "do something appropriate."

Announcing the PMI Agile Group

A grass-roots movement of Agile enthusiasts among Project Management Institute (PMI) members is now being officially recognized by the PMI.  Known by different names (PMI Agile SIG, etc), the PMI Agile Community, as it is now named is shooting for a launch in 2009 Q2. Led by Jesse Fewell, this group is communicating mainly on our Yahoo! discussion forum.  

An initial version of a business plan has been completed, and the following steps are planned:

1. Finalize steering committee
   
2. Finalize Business plan
   
3. Get IT infrastructure up and running
   
4. Launch in Q2 2009 to membershi

To get involved, simply join the Yahoo! group and begin interacting with other group members. Hope to see many of you there!

A Kinder, Gentler Agile?

So, 2008 is fast drawing to a close, and in the U.S, our economy is in the worst straits since the great depression.  Without intending to be polyanna-ish about the economy, I do feel pleased with the immense progress Agile methods have made in the past few years.  Nowadays, it's very rare for me to come across anyone in the software development arena who has not at least heard about Agile methods. There's a very definite shift towards Agile that's quite evident.  Agile adoptions abound at companies worldwide, and the Agile conferences and summits are thriving.  Yet, even as Agile methods are changing the industry, I'm seeing some evolution in the methods themselves. 

Here are some interesting developments from the land of Agile methods.  

1. Rise of the Scrum/XP hybrid. I have long maintained that integrating XP practices is a great way for Scrum teams to develop strong technical discipline. VersionOne's 2008 State of Agile Development survey indicates that 49% of organizations surveyed are using Scrum, and 22% are using a Scrum/XP hybrid.  This is excellent news.

2.  Integration of User Experience design (UxD) into Agile methods.  Perhaps singlehandedly, Jeff Patton has carried the UxD flag for many years in the Agile community. Thankfully, there are now many signs that Agile and UxD can be discussed in the same conversation. Indeed, Alan Cooper was one of the the keynote speakers at Agile 2008 and presented interesting points in his keynote address.  At the tactical level, Jeff and others are working hard to pragmatically integrate UxD techniques with Agile. There's also movement the other way -- designers getting serious about Agile.  All in all, this represents more of a product focus, than a project or process focus.  There's been much hype in the industry about product design. Perhaps agile methods can now help deliver on some of it.

3. Murmurings in the Lean Portfolio Management space.  While there is no mass movement in this area, new developments include an upcoming special issue of the Cutter IT Journal dedicated to this topic (Full disclaimer - I'm the guest editor for the issue).  I'm hoping more companies will adopt the Lean techniques we're advocating to manage their project portfolios. Meanwhile, two new books in this space are Jochen Krebs' Agile Portfolio Management and Johanna Rothman's Manage Your Project Portfolio.

4.  Better recognition of the causes of failure.  With more data points to analyze, the understanding of what makes Agile succeed or fail is growing.   For instance, Version One's survey indicates that, at 23%, company philosophy or culture being at odds with Agile values is the leading cause of failed Agile projects.  I'm hopeful that this awareness and recognition will create more learning about how to make Agile adoptions successful.

5. Kanban for Agile is attracting followers.  Kanban (literally, visual card or board) is a technique from Lean manufacturing where historically cards were used to indicate the need for replishment of an item, and to trigger associated action.   Kanban techniques have the benefit of limiting work in progress and focus the team on delivering a continuous flow of value to the customer.  There's been some buzz lately around the Kanban System for Sustaining Engineering (KSEE) developed by Corey Ladas, David Anderson, Aaron Sanders and others.  KSEE is being used to apply Kanban to software development, and is pushing the Agile envelope, since there are some innovations therein (like no iterations and limits to user stories that a team can work on at a time).

While some are raising the question as to whether Agile has lost its soul, I think these developments represent a kinder, gentler version of Agile that is more sanguine about co-existing with other disciplines.  We seem to be developing the maturity to understand the types of adjustments needed in different circumstances, and in different types of organizations. Indeed, the second editions of Kent Beck's Extreme Programming Explained: Embrace Change and Alistair Cockburn's Agile Software Development: The Cooperative Game landmark books seem to reflect this evolution as well.

What do you think?