Measurement tools. What's the point?

The saying goes - "Give a manager a chart and he will be happy for a day. Teach that manager to count story points and you will wish you'd shoved that fish down his throat."

That may have got lost in translation...

If you ever hear the phrase "ideal man days" walk away from that project. Using project estimation techniques derived from traditional manufacturing and engineering methodologies no longer hold true.

What on earth is a man day/hour anymore?

So how else can you measure/estimate a project? How do you know when you'll be done? 

Story points CAN be your savior. Used correctly they can abstract the complexity of the work from the seconds/minutes involved to complete the tasks. 

Or they can bite you in the ass.

It's a great way to get management to focus on prioritizing features based on size. It allows them to prioritize without requiring in depth work breakdowns. It's also a horrible way to track daily progress.

If you start hearing phrases like:

"I need 21 points accepted today to keep on track"

"That was at least 1/2 a days work - you need to up the points"

"So 1 pont = 1 hour right?"

You're missing the point.

The dark side

A year ago I took on my first consulting gig.

Before this I'd always worked in Product Development. Making the switch from Product Development to Consulting was challenging. 

It seems obvious in hindsight - but make sure you do your homework before taking on a consulting role. Does the company you're joining already have a client site in mind? If so - start digging on the projects history.

Some project sites may not welcome you with open arms. There may not be any fanfare upon introduction (That was very disappointing - I quite like trumpets).

The client may have been disappointed by contractors before who are "all care and no responsibility". They may have been burnt. They may have baggage.

In hindsight - I probably should have suspected something when I saw this on the wall in the office...

Enterprise Agility. An oxymoron?

"If we figure out how to make this work - we could write a book on it" A colleague once told me.

We'd recently started on a very large Public Sector COTS implementation project that was significantly behind schedule and over budget. "Agile" had been sold as the solution to their problems.

In summary - We were in trouble.  

I have a short attention span - textbooks are not my thing. So instead - here's a blog. 

Can you run projects of this size, complexity and historically bureaucratically hindered, using agile techniques?

Apparently So. Go figure.

Methodology or Mindset?

Or both....

A lot of agile proponents are a little too "evangelical" for my liking. (Can you be a fundamentalist agilist?)

You may have worked with some people like this - they're not much fun at parties. 

I once worked on a project with another scrum-master that was very stringent on the agile process he wanted the team to adhere to. Unfortunately, they just felt like they were getting lectured at - They just wanted to ship; Being agile was just a way to get there.

Randy Paush in his "last lecture" discusses how sometimes it's what you learn when you don't realize it that is important.

The head fake is a great tool. Deliver first. Coach as you go.

Why Sashimi?

"Sashimi" is sometimes used in agile projects to describe something that was "done". It's usually a thin slice of functionality. I feel that it's a nice way of representing what agile techniques try to deliver.

Besides, I hate the use of the word SCRUM which is a commonly used Agile framework. Apparently it was so named because it represents "A Rugby team working together and progressing the ball down the field".

The founders mustn't have played much Rugby when they coined the term. In real rugby games - Scrums collapse. A lot. 

And they're boring. 

At least Sashimi is tasty.