Eating the Elephant

I love Man vs Food. 

It's indulgent, over the top, and somehow the host manages to accomplish ridiculous eating feats that you don't think are possible. 

And he does it one bite at a time.

Iterative development forces you to deliver some working piece of functionality every iteration. So realistically you can't go too far down the wrong path and lose too much time, because you'll be reviewing and readjusting your course every few weeks. 

How do you break down a piece of functionality into small enough pieces that they still deliver value?

Let's start with how you don't do it - When you're building tiered technology, you do not break it along those layers. For example - I would not have separate stories for the DB portion, The business logic and the UI. Each piece by themselves do not deliver any real business value. 

Remember - we're looking for fast feedback from the business - and demonstrating some DB tables, indexes and views isn't going to get you that feedback. 

As a general rule, people are pretty bad at defining what they want in any sort of detail. Those same people are usually much better at telling you what they do/don't like after seeing something. So build a small piece of it, show it to them, get their feedback, and then adjust. 

They may decide they don't really feel like Elephant for lunch; and that they're in the mood for sashimi.

Forget the handshake. Embrace the group hug.

In a work appropriate manner of course. I wouldn't want to see any of you get fired.

A lot of traditional project management revolves around hand-offs or handshakes; Sign-off's and documentation.

The entire cycle from Requirements Gathering -> Analysis -> Design -> Functional Specification -> Sign-off can usually be shortcut by throwing the right people in a room with a few whiteboards and telling them to have a conversation. 

In a past life, the company I worked for moved our Program Management Group under a VP who was tasked with improving product quality. His first initiative was to establish a "Product Creation Lifecycle" that involved passing 20+ gates before anything could be released. Each gate had upwards of 10 deliverables - The majority of which were never consumed. In theory it worked - We didn't release any more buggy code.

We didn't release anything at all.

Good Project management is about how you can speed up all the feedback loops in your process and get business value to the customer.

So rather than thinking about "How do I stop getting bad quality software into a customers hands" - Focus on how fast you can get good quality features to them.

Less documentation and reviews. More conversations.

Less process. More good people.

Less handshakes. More group hugs.

Whiteboards are your friend

I love whiteboards.

One of the first things I do on any project is get lots of whiteboards installed for impromptu design and troubleshooting sessions.

But they're damn expensive. 

On the last project though - a colleague introduced me to shower boards and i'll never go back. The coating on them makes them usable as a dry-erase board and you can pick one up for $15 instead of $500. Check out this happy guy.

3M have also started selling a sticky note version of a whiteboard that can be a less permanent fixture.

Glass walls and Windows are also great.

What makes a great team?

This is important in any environment, but even more so in the agile landscape.

One of the core principles of the agile manifesto is the firm belief in people over process.

There are less gates, silo's and places to hide. The work environment is usually open plan. Your team-mates can usually see everything you are doing. You spend a lot of time in face-to-face discussions and impromptu design sessions.

I've found that great teams are friends as well as colleagues. They actually like each other.They hang out at the pub or catch up on the weekends outside of work. This builds incredible camaraderie and loyalty. No-one likes to let down their friends.

Ask yourself - If you were going to start up and fund your own company - who would you hire? Which of your current team members would make the cut?

Why?

And most importantly - What are you gong to do about it?

Momentum is your ally

It's always harder to restart an engine than to just keep it rolling along.

So don't stop. 

With iterative development, you're always delivering frequently and the feedback loop is short. So what do you lose if you keep going? 

From experience, when you stop a bus, people hop off, go wandering and it's like herding cats to get everyone back on board.

By all means, take a breather, re-adjust your course based on what you've learn't, but don't. ever. stop.

Most of the time the person that recommends you to stop, form a steering committee, and re-establish the project plan is probably the person that that needs to be kicked off the bus.

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.