Agile and American Football

This post is about Agile, not football. I like to use analogies so please, please don't crucify me!

The football analogy

In 1983, at Superbowl XVII, the Washington Redskins beat the Miami Dolphins. It was a game my wife, who was born in the Washington DC area, reminds me of every time the Washington Redskins play a game.  Mind you, I'm usually not watching the games. I'm off pondering what I would do if zombies tried to storm our home. Do I have enough plywood and nails? Do we have enough ammunition? But I digress.

So, what was unique about this particular team that made them so successful?  Was it their head coach, Joe Gibbs?  Was it the coaching staff, the team, or all of the above?  Was it a simple process or detailed approach? I guess if they knew what the magic formula was, they would have repeated the winning season over and over again.   Unfortunately, life doesn't work like that and neither do projects or football teams.  The Washington Redskins have won only 2 Super Bowls since.  Gibbs retired from the team.  Then, over a decade later, Joe Gibbs returned to the team, determined to take them back to the Super Bowl.  As part of his strategy, he hired Al Saunders as the offensive coordinator.  What I found interesting was Al Saunders' offensive playbook reportedly had approximately 700 pages of various plays.  Seriously!?  700 pages!  Why would you think detailing play scenarios ad nauseum in a 700 page playbook would give you better results than having the team follow a few basic rules and then empowering them to make decisions on the field?

PMI PMBOK

The PMI Project Management Body of Knowledge (PMBOK® Guide) Fourth Edition has 506 pages.  Some look at it like a cryptic instructional manual to all thing project management.  Some merely look at it as something to reference from time to time, when someone asks "well, what does the PMBOK say?" And some look at it as the obstacle between them and obtaining the PMP credential.

Now, I don't think for a minute, if you try to follow the PMBOK to the letter, you are guaranteeing project success.  That may be the reason you see "Expert Judgment" listed so many times in the inputs-outputs.

Agile Manifesto

4 things we come to value

1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan

12 principles we follow

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity--the art of maximizing the amount of work not done--is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Which playbook would you rather follow?

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

A Quote That Spoke To Me

Your time is limited, so don't waste it living someone else's life. Don't be trapped by dogma - which is living with the results of other people's thinking. Don't let the noise of other's opinions drown out your own inner voice. And most important, have the courage to follow your heart and intuition. They somehow already know what you truly want to become. Everything else is secondary.

- Steve Jobs

Image from Treehugger.com

Agile DC 2010

On a cool day in October, the Agile Tour came to DC to talk Agile essentials, Agile in enterprise, and Agile in government. In the days leading up to the event, the Twitter buzz showed the event was running out of tickets.  By the time the event started, it was at capacity for the venue.

This was the first Agile Tour DC.  This one day conference aimed to serve agile practitioners in the DC area through 3 tracks.

1. Agile Essentials – Get the skills you need to get started.
2. Enterprise and Government Agility – See how it works in the large and hear from a Panel of practitioners working in government.
3. Open Talks Track – Create the conference you want in this Open Space (like) track.  If you didn't see a talk on one of the other two tracks, you cold propose a topic or attend one of the 4 concurrent Open Talks.

Before we got started, Bob Payne, one of the organizers of the event, spoke a little about the event and where some of the money was going.  AgileDC is a not-for-profit conference organized by Agile Philanthropy.    See more below

Compared to the last conference I attended, the PMI Global Congress (<= $1,600), this event had a lot of bang for the buck.  Agile DC 2010 was less than $100!  Now, I'm not going to do a lot of comparing of the PMI Global Congress to this event.  OK, yes I am.   I think PMI missed an opportunity to do some real good in the world.  How is it PMI can charge up to $1,600 and not champion some cause(s) that could really benefit from a few dollars?  Here are some side-by-side comparisons.

	PMI Global Congress	Agile Tour DC
Venue	Gaylord Hotel and Resort	Fannie Mae Conference Center
Transportation	Non-Metro Accessible	Metro Accessible
Duration	3 days	1 day
Price	$1,125 - $1,600	$75 - $90
Food	Average	Above Average
Session Quality	Excellent	Excellent

• Overall, both the PMI Global Congress (Agile sessions) and the Agile Tour DC had excellent presenters.  After that, I think Agile Tour DC was the winner.
• The Agile event was Metro accessible.  In contrast, it took me 2.5 hours to drive to the PMI event.  I then had to pay $20 for parking, compared to $5 at a Metro garage.
• When it comes to the duration of the event, I'm looking for the Goldilocks and the three bears of conferences.  1 day is too short; 3 days is too long; 2 days would be just right.
• Cost.  Did I mention this event was less than $100!?
• The food was good.  Seriously, it was pretty darned good!  One little tidbit, the coffee at the PMI event was below-average to average.  The coffee at the Agile event was average to above-average.

The day was kicked off with a keynote by Sanjiv Augustine, an industry-leading agile and lean expert.  We then took a 15 minute break before splitting off to our separate tracks.  I have to say, you know it's a good conference when you're conflicted which session to attend.

I then sat to hear Agile & Government by Paul Boos.  Good stuff.

Next, I sat for Agile in the Enterprise and NFP (Not For Profit), presented by Tiffany Lentz and Jeff Wishnie of Thoughtworks.

I think the best part of my experience came next, from the panel discussion about Agile in Government.

Members of the panel included: Don Johnson - providing thought leadership in the acquisition of Information Technology across the Department of Defense. Josh Hendler - serves as the Director of Technology at the Democratic National Committee. Richard Cheng - managing consultant at Excella Consulting, providing consulting services to commercial and Federal clients in the Washington, DC area. Paul Boos - serves as the software maintenance lead for the Environmental Protection Agency’s Office of Pesticide Programs (OPP).

It was a very engaging panel discussion and they all brought some very unique perspectives to the conference.

I then saw Sanjiv Augustine present Agile Portfolio Management.  I think the best part of Sanjiv's presentation was that it offered something for everyone.  You didn't need to be a seasoned Agilist to enjoy it.  If you ever get a chance to see Sanjiv present, do it.

The last session I attended, Emerging IT Acquisition Processes Within DoD,  was by Don Johnson from the Department of Defense.  I would like to say Wow!  To see what is happening over at DoD is nothing short of remarkable.  The one question I get asked by people in the Federal Government is does Agile work in the Federal space.  Don proves that it can and that is does.

That's about it.  It was a great event.  I look forward to the next.

If you get a chance, clear your calendars for October 14, 2011.  That's the tentative date for the next Agile DC Conference.

---

AgileDC is a not-for-profit conference organized by Agile Philanthropy. Agile Philanthropy’s mission is to assist not-for-profits through fund raising and volunteerism. For more information visit AgilePhilanthropy.org or contact Bob Payne 202-903-6854.

Conference not-for-profit beneficiaries:

Mano a Mano International provides critical healthcare and infrastructure development in Bolivia.

Haiti Partners provides education and educational support in Haiti. Since the recent earthquake they have been serving their communities with earthquake relief and humanitarian services.

FreshFarm Markets helps create farmers markets in the DC area and provides matching funds allowing WIC and Food Stamp recipients to buy nutritious local food. Their work sustains local agriculture, schools and local families.

Scrum Alliance & Star Trek

Max Keeler tweeted that the new Scrum Alliance director is new to Scrum.  I went over to the Scrum Alliance website and I see they have selected Donna Farmer as the new Managing Director.

Beginning October 1, 2010, Farmer will lead the non-profit organization, working with the staff and Board of Directors to realize the organization’s vision and mission.

Lately, there seems to be some turbulence in the Scrum world, after Tobias Mayer resigned from his SA staff role as creative director and renounced his SA certifications of CSM, CSP, and CST.  He then wrote a scathing blog post on the whole thing.  I've also read an email response to his post by the Scrum Alliance, over at the Agile Scout website. The whole situation was really quite disheartening.

I empathize with Tobias and what he went through.  I empathize with the Scrum community, as it evolves and tries to navigate through constant change.

But, let's go back to what Max tweeted about.  Max sent me a link to the source (if it stops working let me know).  Farmer admits to being new to Scrum.  Even though she is, should it matter?

My analogy is the latest incarnation of Star Trek.  When I heard J.J. Abrams was going to be the Director of the movie, I was shocked.  How could the franchise do this to us!?  Abrams admitted he wasn't even a fan of Star Trek.  This was blasphemous to hear.  How could anyone but a fan direct a Star Trek movie?

Well, though Abrams wasn't a fan, he took the franchise in a new direction and made a pretty damn good movie.  I'm not saying Farmer is going to be a savior for the Scrum Alliance but I want to give her the benefit of the doubt.

I will continue to be optimistic about the future of the Scrum Alliance and the Agile Alliance until someone like Ken Schwaber or Alistair Cockburn publish something that counters the very principles they stand for.

So, before we pass judgment on Donna Farmer, let's all get a extra-large popcorn and see how this plays out.

May the Scrum Alliance live long and prosper.

Graphic from ChipChick.com

Zombie Estimating Techniques

Since we all know zombies don't count, we're going to assume you are the poor sap trying to get away from said zombies.  But what are your chances of survival?  Do you have enough ammo? Let's assume your survival is the project.   Since a project is a temporary endeavor, we'll go with that.  Our goal is not necessarily to create a unique project, service, or result, unless you count killing zombies.

How big is that unthinking horde or zombies slowly making its way toward you?

Do you have enough ammunition to kill them all, before they get to you?

Now, I don't know about you, but my estimating skills suck.  We're in trouble unless the unit of measure are digits on my body or comparing something to the size of my coffee cup.  But that's ok. We have bigger things to worry about. I mean, we do have a horde of flesh eating zombies coming after us. So, let's talk about two simple estimating techniques, hours and story points.  In this post, I am not going to tackle what I would define as advanced estimating techniques. I'm just going to limit it to the two below.

Technique 1: Hours

OK, who here hasn't estimated in hours?  Though this doesn't necessarily translate to zombies, it does to software development and other project activities.  Break efforts down in the smallest group possible, like tasks or user stories.  This technique is good but I think you need to really have a grasp of what you're up against in order for it to be effective.  If you provide an estimate on an Epic or WBS Level 1 item, it loses its effectiveness.  Try to decompose (not like zombie decompose) work if it exceeds 8 hours.  The more time that elapses on a given task, the higher the probability something is going to change.  Get it completed and delivered so you can base your next estimation on something you've already done.

Please don't estimate for other people.  Only provide estimates on things you're going to do.

Technique 2: Story Points

Rather than estimating in hours, story points help people get past the uncomfortable feeling of saying they'll complete something in X hours.  Sure, a story point could equal 1 hour but it doesn't have to.  Think of estimating work at a relative amount compared to other work.

Imagine  two groups of the undead are lumbering toward you.  I'll say group one is worth 8 points in size and complexity.  It takes you 20 rounds of ammo to take them out.  Though you didn't get a head count, you'll say the second group is 13 points in size and complexity.  If you only have 20 rounds of ammo left, how does that make you feel right now?  Do you run like hell in the opposite direction or do you think you learned something in the last round?

Once again, please don't estimate for other people.  Only provide estimates on zombies you're going to shoot.

Are you starting to see the parallels?

Like the image?  Find it at Pictofigo

IT Blog Awards 2010: Project Management

The Critical Path has been nominated for the  Computer Weekly IT Blog Awards 2010 in the area of Project Management. I am honored to be considered, since I actually enjoy writing this blog.

My audience continues to grow and I had visitors from 112 countries/territories in the last month.  Who knows, maybe it's the recent posts about zombies?

If I've helped one project manager in the last 2 years, this blog was worth it.

If you think I should get the award, please vote for me!

Zombie Projects

Oh, you know that project.  That project that just won't die.  It is all that is unholy in the world of project management. Where did this project come from?  Who would sponsor such an abomination?  How the hell do we kill it?!

Do you ask yourself those question when that project rears its ugly head?

Now, we all know them when we see them. They don't seem to have a sponsor.  They don't seem to have a goal.  They certainly don't deliver value.  They just putter along (old-school slow zombie not new-school run fast zombie) eating up time, money, and the occasional brain.

What is sad is your project may turn into a zombie project at any time.  You must be strong and vigilant.  I know you were friends.  But, if one of your colleagues or your project become one of the undead, you need to cut your losses and run.  You need to do the right thing and kill it.  Yes, kill it!  It will be the best thing for everyone involved, especially all those people and projects that are not members of the undead.

I recently read an intriguing post by Dr. Samuel Prasad.  He wrote out an analytical approach to identifying if your project needs to be killed.  He lists KPIs frequently used by many companies and successful project managers to identify if a project is healthy or in the danger (zombie) zone.

Bill Jenson, author of Hacking Work, said it's good but his gut knows it way earlier.  Some out there don't need an analytical approach.  They just know it when a project needs to be killed.

So, do you know a zombie project that should be put out of its misery?  Before you get all judgmental on me and say every project has a right to exist, think about one thing.  That money and those people being dedicated to support that zombie project could be redirected to your project, hopefully increasing your chances for success.

Thank you to Brian Bozzuto of Big Visible for inspiring me to write this post.

Like the image?  Find it at Pictofigo