Agile or Waterfall (Podcast)

Back in late 2010, I was features on the Talking Work podcast. Then in early 2011, I appeared at the WorkOut 2011 conference.  Because Ty Kiisel and Raechel Logan were such gracious hosts each time, I couldn't help but say yes when they recently asked me to make another appearance.  Hear what I have to say, when Ty asks me, "Which is better, Agile or Waterfall?" I love being asked a provocative question and then given full liberty to articulate what I really think.  All too often, people already have their own set of beliefs on a topic. They're polite, but only to a point.  They aren't listening. They're waiting to talk.  Thankfully, Ty and Raechel are good listeners.




The Forest Through the Trees

Zombie PM WebsiteI'm coming down to the wire on the first installment of my Zombie Project Management book.  I look at my Kanban and all of the activities are one-by-one making it into the Done column.  It's actually quite exciting! I think back to reading several of Seth Godin's books and him writing "Pick a budget. Pick a ship date. Honor both. Don't ignore either. No slippage, no overruns."

I know that is easier said than done.  But halfway through writing my book I saw the forest through the trees.  This idiom personified what I'm trying to communicate.  I became a "writing" zombie.  I thought of those who came before me, puting pen to paper.  They had ideas but how many were able to actually offer their works to the general public?  What roadblocks stopped them from making their dream a reality?  To just accept the status quo without question is your first step to becoming a zombie.

Something in the book publishing business didn't seem right to me.  I didn't know what was bothering me until recently.  See, I don't like to ask permission and I don't like inefficient processes.  If a process doesn't seem to make sense to me, I want to change it.

Lightbulb Moment

Doesn't the book publishing process sound a lot more Waterfall than Agile? As the Product Owner, I take issue with that.
  • Step one was to not ask for permission.  I decided to use Amazon Kindle Direct Publishing.
  • Step two was to pick a ship date and ship whatever I thought would have the greatest value first.
  • Step three is to ship more content, once a month, until I feel the body of work is comlete.
Why release the book in a series of sections or chapters rather than the entire book at once?  You all know I’m a strong proponent of Agile approaches.  When I looked at the publishing process, I compared it to tradition project management methods.  Traditionally, you plan it all out, you build, and then deliver the finalized product.  One thing I’ve learned is you can deliver value earlier, if you establish a series of deadlines and ship something at each deadline.  In that way, you lower your risk of not reaching your overall goal, by ensuring you deliver something regularly.  This will also allow you to produce something of value others can benefit from, at a lower cost.  One of my favorite books, Agile Project Management with Scrum by Ken Schwaber, has 9 chapters and 155 pages.  When I purchased the book at a Borders bookstore some 6 years ago, it cost me $39.99.  Though I recognize the value in reading a physical book cover to cover, I would now be willing to purchase an electronic version of the book, by the chapter.  Give me the chapters of greatest value first at a price relative its cost of production.  At $39.99, each chapter would have cost me just under $4.45.


So, with that in mind, I will "ship" a series of sections or chapters each month for $2.99.  I may even bundle a few chapters at a time and offer them as printed copies.


HT: Zombie drawings by Pictofigo

Yes, the link to the Scrum book by Ken Schwaber is an Amazon affiliate link.

Agile Traffic Analogy

The post today was brought to you by... my hellish commute and those in the Washington DC metropolitan area who help create it.  Thanks! Today, I'm going describe Agile concepts by using my commute as the analogy.


During any given day, spend as much time working or at home and as little time commuting as possible.

I'll write a User Story because I'm weird like that

As a project management advisor to a government PMO, I want to travel 55 miles in the shortest period of time so I can spend more of my life delivering value than wasting time sitting in traffic.

Predictive Approach

How long will it take to drive 55 miles to the office in the morning and 55 miles to my home in the evening?  We've all had to estimate our commute time.  Sucks, doesn't it!?  We're all terrible at estimating.  Why?  Things change...constantly!  You can spend as much time and energy as you want, trying to think of all of the possible scenarios.  You can break your commute into "chunks" and estimate those.  That could give you a better estimate, taking into account variances in each leg of the commute.  But, until you get on the road and actually start your commute, you just don't know.  We've got weather we need to deal with.  We've got that knucklehead in the far left lane, driving 10MPH under the posted speed limit (with his blinker on).  We have to deal with the occasional traffic accident.  Work on a project is no different.  You can try to estimate your time, up front, but when something happens (notice I wrote WHEN not IF) your original estimate is going to be wrong.  What are you going to do?  Are you going to try to make up the lost time later in your commute?  Is something else going to be sacrificed like hours of work or hours at home?

Do I personally think there is a more accurate way to estimate a commute, as the commute happens?  Yes.

Adaptive Approach

This was my Adaptive commute this morning.  My wife told me that the traffic report on the radio stated there was an accident 40 miles into my commute.   Good to know, I thought.  Information is good.  Communications is good.  So, did I change my estimate at that time.  Nope!  Why, you ask?  I was armed with my handy Droid X.  My Droid X has GPS and Google Maps with a traffic overlay.  Now, I still broke my commute down into chunks.  I still had the basis of estimate there.  But, the magic happened after the commute began.  I did see the traffic slow down (on the map) that my wife referred to.  But, the radio was still reporting that the lanes were blocked.  The map indicated that traffic was getting by slowly.  Good to know I thought.  Information is good.  Communications is good.  But now, I saw (on the map) that traffic was stopped much earlier and they were not saying anything on the radio traffic report.  By the way, the radio station only reports the traffic every 10 minutes.  By getting realtime feedback from the Droid, I was able to know when I was going to have take a different route, to bypass the delay. I took the next exit and my commute route and the map refreshed.  I could see, by the map, where I could get back onto my original route.  I actually arrived to the office, 20 minutes from my optimum commute time.  If I had not had the Droid and the constant feedback about the traffic conditions, it would have added a hour.

I still lost 20 minutes.  But that was unavoidable.  But I think I minimized my delays by getting real-time feedback.  I had opportunities to adjust my course based on information.  I was able to adjust my commute estimate every minute, not every 10 or 20 minutes.  If someone from the PMO had called me to ask when I was going to get to the office, at any time along my commute, I could have given them a pretty good estimate.  But that telephone call isn't necessary.  Here comes the kicker.  I share my location with Google Latitude.  They can see where I am at any time.

Here are some things to think about for your next commute

  • Know where you are and where you want to go
  • Break your commute into chucks
  • Get traffic conditions as often as possible
  • Be prepared to change direction
  • Be prepared to reestimate your time of arrival, the closer you get to your destination
  • Give people a way to know your location so they don't have to ask you every 5 minutes
  • Feedback is good
  • Information is good
  • Communications is good

Like the image? Find them at Pictofigo

Outdated Success Criteria

I know this is going to probably get me some "hate" comments.  It seems like if I write about anything but a zombie, that's what happens. But I do like to write about topics that make people stop and think. Think of this post a bridge between a historical project management and futuristic project management.  Let's think about success in both an objective and subjective way.

I'm seeing more and more topics about the measurement of success.  Geoff Mattie just wrote a post over at the PMI Voices site, titled Can Agile Conquer the Physics of the Triple Constraint?

Geoff refers to Triple Constraint and states

The "iron triangle" as some refer to it, defines three pillars: cost, scope and time. It asserts that you have to prioritize the three with an understanding that trying to have all of them at the same time compromises quality.

I applaud Geoff in his zealousness and hope this works for him and hit customers.  Being his blog post is on the PMI website, I want to point out the the iron triangle is not in the PMBOK.  Rather, on page 6, it states

Managing a project typically includes... balancing the competing project constraints including, but not limited to Scope, Quality, Schedule, Budget, Resources, and Risk.

I remember a few years back, when taking the PMP exam, I had a question about typical project constraints.  The answer was not limited to 3 or even 4 "pillars".  So, where am I going with this?

I'm curious why people continue to measure the success of a project, merely on the basis of an iron triangle.  I think this concept is outdated and perhaps created by a project manager to help an executive understand project management at a 100,000 foot view.  I am also curious why many continue to use the Chaos report, (which leverages triple constraint) as the de facto report of industry success or failure.  I am not debating that it has historical significance.  But, I am questioning if it should be the way of measuring project success.

Jeff Sutherland has a blog post about the happiness metric. In his post, he mentions Tony Hsieh of Zappos.  I recently read the book Delivering Happiness by the Zappos CEO.  Again, what's my point?  Perhaps the Chaos report should introduce happiness or customer satisfaction at part of its success criteria.

Too subjective you think?  I think not!

I recently saw a presentation by Sanjiv Augustine as part of the VersionOne AgileLive Webinar Series

One of the concepts presented in Sanjiv's presentation was a NPS (Net Promoter Score) metric.  Think of it as a customer satisfaction or "happiness" metric.

NPS is based on the fundamental perspective that every company's customers can be divided into three categories: Detractors, Passives, and Promoters. By asking one simple question — How likely are you to recommend [Company X] to a colleague or friend? — you can track these groups and get a clear measure of company performance through its customers' eyes.

So, what is the Zappos NPS?  In a YouTube video of Tony Hsieh at the NPS Conference  (1-26-09), Tony said Zappos offered random email surveys that resulted in an 83% NPS and phone surveys resulted in a 90% NPS.  Though they lose money on some of their customers, they are an overwhelming success.

Do you believe the Standish Group Chaos Report should include NPS to define success? Are the original classifications outdated?

AgileLIVE Webinar Series

Not seeing the productivity gains you expected?  Are you and your stakeholders losing confidence in your team's ability to deliver?  Are you sure you are measuring the right things? VersionOne and their Moving Agile into the Mainstream webinar series provides proven techniques to help you and your team with the tough issues facing agile managers, scrum masters and product owners.  Fifty-minute sessions feature case studies from teams that have succeeded in using agile methods to efficiently create better software.

Today, I saw "The Hybid PMO" by Sanjiv Augustine and Roland Cuellar of LitheSpeed

Even when agile methods succeed unequivocally at the team level, middle-management still faces two major, continuing challenges: managing a hybrid portfolio of agile and non-agile teams, and reporting progress upwards to the executive boardroom. How can PMOs bridge the gap between executive management weaned on plan-driven methods and predictability, and teams operating with agility in the face of uncertainty? How can they create a consistent reporting framework applicable to both agile and non-agile teams and communicate all-around progress effectively?

Sanjiv and Roland shared principles and techniques for the Hybrid PMO, and discussed some of the crucial management steps in establishing such a group, based upon their decade of experience in helping firms adopt agile at enterprise scale.

It doesn't matter if you want to learn from leading Agile pundits or just looking to get a few PMI PDUs.  This webinar was very enjoyable.  VersionOne will be uploading the webinar in a day or tow for those who were unable to join the live presentation.  All of this was FREE!

So, head on over to VersionOne and check out the other webinars from the series, from the likes of Dr. Alistair Cockburn, Bryan Stallings and Valerie Morris -  SolutionsIQ, and Michael Spayd - Collective Edge Consulting

The awesome Image and some of the content for this post courtesy of VersionOne