How much documentation do you need?

I'm not talking about User documentation or Help - I'm talking about all the supporting artifacts that get created during a project lifecycle.

This is a seemingly innocuous question but is usually a good gauge at how productive your project really is.

How much of the supporting documentation for your project is actually consumed? 

How much of it is produced to satisfy your development process?

How much of it is to keep external stakeholders happy?

How much is created for reporting or metrics?

Who is actually consuming it? 

It's easy to get caught up doing "Busy Work".

My guidelines are:

1. Do enough so that you have control over the project

2. Do enough so that your boss trusts that you have control over the project. 

That's it.

If you don't need it to actually keep on top of things - don't waste time producing it. Because then you have to maintain it, and next thing you know you're spending all your time editing docs instead of producing value.

If you don't keep your boss happy and up to date, they're going to come and poke around and probably distract the teams doing the work. So work out what they need and how often they need to see it. From experience, It's rare that a weekly report and an invitation to product demo's won't cover their needs.

TLA's

If you read the Project plan post, got very angry and yelled at the screen "That's why you should have a Change Request Process dumbass!"  - Thanks, that sets up this next post. By the way, You have some repressed anger management issues - you should probably talk to someone about that.

Let's listen in on a conversation I have with myself regarding Change Request Processes.

For this example, My personality has been split in two: Three Letter Acronym (TLA Me) and Agile (Ninja Me).

Ninja Me: Why do you have need a Change Request Process?

TLA Me: So I can document when we have deviated from our original plan

Ninja Me: Couldn't you just have a quick chat with the Product Owner and Team and if they agree it makes sense, just re-prioritize the order you're doing things?

TLA Me: But it needs to be traceable

Ninja Me: So make sure you log it. Or use a system that has it for free.

TLA Me: But all the stakeholders need to be aware, and then we have to re-plan, and re-estimate.

Ninja Me: Hasn't everyone already agreed it needs to happen? If you have a definitive finish date, then whatever was at the bottom of the list just became less likely.

TLA Me: Ah-Hah! That's exactly why. We just changed scope and impacted dates!

Ninja Me: You're also delivering what the customers and stakeholders actually want- not what they asked for months ago. 

TLA Me: But won't I get in trouble?

Ninja me: So this is about CYA?

TLA: Hey, TLA's are my job

Ninja Me: Sorry. My bad. How much time do you spend chasing down Change requests, re-estimating it and re-drawing the project plan?

TLA Me: Most of my day

Ninja Me: And you get Developers and testers to help you with the documentation, task breakdowns and estimates?

TLA Me: Of course - otherwise it wouldn't be accurate

Ninja Me: So who's doing any work?

TLA Me: Let me look at my project plan. I'll get back to you.

I need to drink less coffee...

Do you know your Purpose?

Most Projects have some goal or end state.

Some even have fancy mission statements.

Very few clearly define the "WHY" - What is the purpose or reason behind what they are trying to achieve. 

This can lead to several problems:

1. It's the Purpose that drives the actions. 

It's the real motivator. When you know why you are doing something and it's a powerful enough reason - you're much more likely to get the end result you're looking for.

2. Sometimes understanding the "WHY" leads you to a totally different end point or solution. 

Ever have that lightbulb moment when you realized what you built wasn't what the customer really wanted? If so, You probably didn't understand why they wanted it. 

     This is why user stories are structured as:

          As a <role>

          I want <goal>

          So that <why>

The last part of a user story that justifies why someone wants something is very important.

3. A lot of the arguments/ long discussions that occur during a delivery cycle are usually differences of opinion on "How" to do it. 

The design, tools used, Process etc... People can get pretty dogmatic defending their position. 

You can circumvent these a lot of the time by refocusing the discussion back on the purpose behind what you are doing. As long as you solve the "WHY" The How is less important. 

As they say - There's more than one way to skin a cat.

Mine is better though ;)

"No plan survives first contact with the enemy"

It's a famous quote from a German field marshall named Helmuth von Moltke (The Elder). 

I believe Helmut was reincarnated as Scott Adams, though I have nothing to back that up with.

I recall a project where the Program Manager was very quick to announce during status meetings that we were "executing to plan". Her measurement of success was how well we were marching against the detailed project plan that had been meticulously put together over several months. Unfortunately this was flawed for a few reasons:

1. The plan was terrible.

2. If she'd talked to Helmuth, she would have realized that it was essentially out-of-date the moment the first task was started.

What pattern do I normally see?

Very late in the project, the status flips from "Green" to "Red" because executing against a plan doesn't mean you're really "done" or meeting the customers expectations. You are no longer reacting to or basing your decisions on reality (both status and environment) and the repercussions of discovering that late in the cycle are usually costly.

Of course - Project Plans and Gantt charts can be very helpful when used correctly. I still use MS Project to map out release and integration milestones. It gives Executives and Stakeholders the ability to see at a high level what is happening/when in.

But a detailed MS project plan does not a successful project make.

The wand won't work

I just got back from a day at Universal Studios in Orlando. One of the highlights was visiting the Wizarding world of Harry Potter section. We toured Hogwarts, drank butter beer and browsed through Olivanders wand shop. I even bought a magic wand.

It just doesn’t work on my projects.

I'm sure you've heard about the triple constraints of project management. It basically holds that adjusting any of the 3 sides of the triangle has a direct effect on the other 2 sides. Unfortunately moving to an agile delivery method does not give you a free pass to avoid those constraints.

Sorry.

But what if you can make one of those sides flexible?

An all too common scenario I've seen is when Sales or Product Management have promised a fixed set of functionality to the delivered within a set time frame, and it's up to the Development team to deliver.

I've seen Product Requirement Documents that have had hundreds of really large requirements all listed with a priority of "Must Have". The cavalry of reinforcements never arrives, leaving the team in a no-win situation: 

• If you're at a Public company, this leaves you with some revenue recognition issues if you booked sales based on features not supplied
• There's a hit to the company reputation for missing delivery dates
• That sort of pressure on a team does not make a pleasant work environment. You're going to see staff turnover if you set them up to fail like this.
• There's still no commission for the Sales guy.
• Someone decides to ship anyway - with incomplete features or buggy code because you ate into your QA time. That leads to a raft of other problems.

So how do you solve it?

The easiest side of the triangle to build in some flexibility with is the scope. The other two sides generally require acts of congress to move from my experience.

When you have so many things to deliver, and you are delivering them with waterfall techniques, it's quite easy to fall into the trap of spreading yourself too thin across multiple requirements concurrently - and successfully completing none. 

So take the wish list - and stack rank it.

If you could have just 1 feature. What would it be? 

What next?

If your business can't answer those questions - your problem isn't a Project Management or Delivery one.

Convincing the Biz.

There are a couple of things to take into account when trying to effect any change:

1. It's not how much you are doing that matters - it's knowing what you are being scored on.

2. Take Baby Steps.

3. Most New Years Resolutions Fail.

Let me be a little less cryptic:

1. Have you ever felt resentful because you feel like you do/contribute  a lot - but it isn't appreciated or recognized? 

Firstly, a personal example:

I worked from home for several years when I first moved to the US. It had it's pro's and con's, but having the time to do chores like washing and cooking during breaks in the day was particularly useful. Despite all the housework I did, my wife still seemed unhappy with me. So I did more. She still seemed unhappy. That just made me resentful. Then I worked out that what she needed from the relationship was for me to take a break from work when she came home was to drop everything, give her a hug, and spend some time paying attention to her. 

I was putting in a lot of effort - but not in the areas I was getting scored on - so they didn't count. Now we eat out a little more, we're a little chubbier, the house is a little less tidy, but we're both happier.

Until she notices that I used this example in a blog post.

Successful relationships are about meeting each others needs and that basic rule holds true in any relationship - including a work one.

So how well are you meeting the needs of your sales and marketing groups?
What about your boss?
Do you really know what their needs are?
Have you asked them - or are you assuming?
Are you putting a lot of effort into the wrong areas?

Maybe you are meeting them too well at the moment and they see no need to rock the boat and change the way things operate? (though you probably wouldn't be reading this if that was the case)...

Or do you need to do a better job of communicating how your proposed changes can help meet their needs?

Do they:

     Want predictable release dates?

     Want to reduce development costs?

     Want to deliver features that meet customer expectations?

     Want to reduce maintenance and customer support costs?

     Want to reduce time to market with a new product?

Work out what it is they want most - and then show them how you can help get them there. Usually - One of these can be enough of a reason to initiate changes. You just need to work out which one has the most leverage in your organization.

2. The phrase comes from a scene in "What about Bob" that has stuck with me for quite a long time. 

This seems really obvious, but - start small.  Find an exec or sponsor that is willing to support it. Identify a Business Rep that wants to change and partner them with a good team. Call it an experiment and promise to go back to old ways if it doesn't show results.

Time-box it.

Celebrate and publish the successes using metrics they understand. You can build from there. I've seen quite a few transformations fail that tried to change too much too soon and it was beyond the organizations comfort level. 

Ironically, they weren't iterative with their agile transformation :)

3. 72.8% of New Years resolutions fail. (Homer Simpson helped me with that statistic).

Good intentions only get you so far. Sometimes the best leverage and driver for positive change is when you get sick and tired of failure. It's the tipping point that forces you into action. If you look closely enough for them - You'll find areas in your business that are struggling and are willing to try something new. They are sometimes the best places to start - because the contrast when you succeed is so much greater.

P.S - I'm currently on a Caribbean Cruise so this post is not real-time. A friend pointed me at Hoot-Suite not too long ago and I've found it very useful for scheduling and tracking your social network posts.

The "Commitment" fallacy

"We're not using agile - that's just a way for you to not commit to deliver anything. How can I base a marketing roadmap off that?"

You've heard variations of that i'm sure.

A common misrepresentation is that you when you deliver using in an iterative fashion, you don't focus on the entire scope of the project and you don't commit to deliverables. This scares business people. It would scare me too. If only it were true.

It's generally accepted that even a traditional project plan built from the bottom up is likely orders of magnitude inaccurate. The cone of uncertainty depicts that quite well. 

If a team can't give you a good ball-park estimate on what you'll see at the end of the project, it's probably because they know your business requirements are going to change over that timeframe.

And that's allowed. 

Instead of thinking if it as a bad thing - think of it as a better way to react to the changing environment. How quickly you can react to fulfill a customer need is a success criteria every business should use.

Besides  - you won't have to fill out any more change requests.

Agile. Just like Fight Club.

The first rule of selling agile, is to not talk about Agile.

For "Old School" technologists - it's a buzz word that they are immediately cynical of. This is also true of a lot of other terminology. When I've snuck in agile practices in the past, I've used "Phases" instead of "Sprints". "Scenarios" instead of "User stories" etc.

Use terminology that the organization is comfortable with.

A friend (Let's hypothetically call him Scott) mentioned recently that convincing the business is often the hardest part of an agile transformation. That made me realize that for a lot of the implementations I've been part of - the transformation has been driven from the grass-roots level. It's rarely senior management driving the change - it's usually a lone dev team or sometimes just one manager who decides that there is a better way to build software - and does it. It's always easier to ask for forgiveness than for permission.

So how do you help the organization or business transform, when the Dev team is already champing at the bit?

Tune in next week - Same bat-time, same bat-channel.