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

I'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

HT:

Zombie PM website

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.

Goal

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

Waterfall Zombie vs. Agile Zombie

Back on October 12 (2010), I had the privilege of seeing Michele Sliger do a presentation titled "Hello Agile, Goodbye Scope Creep".  In it, she presented a compelling argument as to why a Waterfall process used to work so well for projects and why Agile is becoming more and more prevalent and successful.  You know me by now.  I can't help but draw a parallel between Waterfall versus Agile and old-school-dragging-their-legs zombies and new-school-all-out-sprinting zombies.

waterfall_zombie

agile_zombie

Waterfall Zombies

Back in the day of Night of the Living Dead, Day of the Dead, and even Dawn of the Dead, zombies were sooooo slooooow.  You usually had enough time to time to go to the gun shop and pick up a few cases of ammo, pluck them off one by one, all before they would change course and lumber after you.

Those were the days, when you could actually plan your attack on the zombie populous and carry it out.

Yes, when Waterfall was big, zombies were slow.  You actually had a fighting chance to outrun them.  That is, until you made some foolish mistake like not rolling up a car window or fumbling with your car keys.  Come on, people!

Agile Zombies

Now, zombies are fast, fast, damn they are so fast!  These aren't zombies like I remember them. These "28 days later" style zombies look you square in the eye and they are sprinting after you.  They are quick to react.

Now, I'm just looking for an excuse to put zombies in a post.  But, truthfully, something has changed.  Why is it, more and more projects are leveraging Agile methods and not using Waterfall?  Is it ADD?  It is just a bright shiny toy?  No, it's evolution.  Things change over time.  The one constant that seems to be happening is communications is a lot faster than they used to be.  The famous "Midnight Ride" of Paul Revere of 1775, where he road horseback across the countryside would now merely be a 21 character Twitter Tweet British coming! #fail

But, I would be doing you all a disservice if I didn't let you read what inspired me to write this post.

From Michele Sliger's original post title Hello Agile. Goodbye, Scope Creep!

Fifty years ago, planning out the scope of an entire project and locking it in worked because the pace of change was much slower. Teams had time to analyze, design, code, test, and deploy the product before their customer could change their mind. It was in the late 1980s that all of the inventions that speed thoughts of change started being used by the general marketplace: the personal computer (PC), Internet, email, and cell phones. The speed of communication increased, which increased the speed of knowledge, which drove the speed of change. Teams using the traditional plan-driven approach to product development could not keep pace with this new speed of change...

...A new approach to product delivery was required in order to take advantage of the technological advances and speed value to market. And it had to abolish the philosophy that change was bad, and instead embrace it. It had to give teams the flexibility they needed to react to change, and the framework and discipline to execute change.

Like the images?  Find them at Pictofigo

The Pepsi Challenge of Waterfall, Agile, or Kanban

I kind of enjoy it when people get all in a huff over which soda is the best.  It's bad enough they can't even decide what to call it. Is it soda, pop, or soda-pop?  I've even heard a few refer to any brown carbonated non-alcoholic beverages as a "Coke".  I don't get that at all.  I'm going to assume these people just don't care.  All they want is a brown carbonated non-alcoholic beverage that will satisfy their thirst.  As far as soda-pop, I am the complete extreme opposite.  I drink Coca-Cola.  I don't drink Coke; I don't drink Pepsi.  If I ask you for a Coca-Cola and you ask me if Pepsi is OK, I'm going to respond with a stern but polite "No".  But, at the end of the day, I am also just looking for something to satisfy my thirst.  But, I digress. Since the Pepsi Challenge in the mid-70's, there has been another battle raging.  Let's call it the Delivery Challenge.  Regardless of what facts may be reports, detailing which approach lowers risk the most, which approach delivers the most value up front, or which approach leaves the stakeholders feeling the most satisfied, we all have our favorite.  If delivery approaches were soda-pop (yes, soda-pop) in a blind taste test, chances are we'd stick with our favorite regardless of what we may have picked.

From my own perspective, I don't believe we should be so blind to these opportunities.  We should be open to the idea that formulas can be improved and we should be open to the idea that processes can as well.

When I'm dealing with the government client on a particular contract, I use Waterfall.  We're talking Waterfall the size of Niagara Falls.  It's not that I choose this approach (drink).  It's all that is currently offered. When I'm managing my own personal projects and deliverables, I use Agile and Kanban.  I'm not saying one is better than the other!  But, when the choice is mine, I know what I like from each.  I ala carte the way I do things, so (as the customer) I get the most value while not bastardizing the original processes.

I know there are those out there who are cursing me.  They are strict Coke, Pepsi, and Dr. Pepper zealots.  Think of me as that kid down at the local Kwik-E-Mart who takes his cup and adds a little of each soda-pop in his 64 ounce cup.  It may look nasty but it sure tastes good.

...and at the end of the day, isn't it important that I just satisfy my thirst?

Image source: USAGeorge

Agile is in the PMBOK so it must be true

Yesterday, I was having coffee with Jesse Fewell and we discussed, among other topics, how the PMP® or Certified ScrumMaster (CSM) credentials legitimize many in the eyes of stakeholders. This is a sore spot for many, particularly for me.  Experience and project leadership trumps a certification any day of the week.  But, for those of us who believe we know what we're talking about, a credential is sometimes a necessary evil.  As I advise a Federal PMO on a multi-year project, I have grown to accept that progress can be slow and expensive. Things can be so slow and expensive, we rarely get to see actual value delivered.  Rather, successes are measured with earned value. Sometimes, I think it's just the nature of the beast. But, it doesn't have to be that way.

You can only imagine my excitement when a vendor proposed using Agile to deliver the next (year) software increment. The PMO I advise has many PMPs but only one CSM...me.  I'm not going to go into the details of the project.  But, how could the opportunity be seized to leverage Agile?  Rather than answer that directly, I'll ask a question.  If you believe in the Agile Manifesto, how would you convince people with no experience with Agile or Scrum (but lots of experience with the PMBOK and Waterfall) that you know what you're talking about and that Agile is a viable option? I would propose that you make sure you can communicate with stakeholders in a language they understand. If you start using terms like Sprint, ScrumMaster, and Burndowns, when they understand contract periods of performance, project managers, and EVM reports, you may lose that essential stakeholder buy-in.

One of the first things I would recommend you say is "Agile is actually in the PMBOK". If your stakeholders are PMPs and they believe the dogma of the PMBOK, you'll have their attention. It's not called Agile but it is there. In Chapter 2 (Project Life Cycle and Organization) of the PMBOK, you'll read about Project Phases, specifically phase-to-phase relationships, and then even more specifically the iterative relationship.

...only one phase is planned at any given time and the planning for the next is carried out as work progresses on the current phase and deliverables.  This approach is useful in largely undefined, uncertain, or rapidly changing environments such as research , but it can reduce the ability to provide long term planning.  The scope is then managed by continuously delivering increments of the product and prioritizing requirements to minimize project risks and maximize product business value.  It also can entail having all of the project team members (e.g. designers, developers, etc.) available throughout the project or, at a minimum, for two consecutive phases.

For the Agile pundits out there, does that sound a little familiar?  For those who believe the gospel of the PMBOK, is it reasonable to believe Agile is an approach that can be considered?  Agile is not a bunch of voodoo for the wild and undisciplined.  It's an excellent opportunity to deliver value.