But “focus” is the willful rejection of this theory. By saying no to alternatives you increase risk disproportionally to the reward. If you have the means to maintain a portfolio it certainly seems imprudent not to do so.

So why would someone want to focus?

The answer is that too much diversification is dangerous. It’s dilutive to everything the company uses to create value: its resources, its processes and its priorities. It dulls the mind and tarnishes the brand.

“The problem is that the more big-bang you are, the less likely you will get everything you want. That’s because there’s a ton of work in progress, and that it’s hard to be omniscient about how your architecture will work in practice.”

I think this point gets over-looked far to much. The more stuff you keep up in the air (in progress), the less certain completion will be what you were expecting. Make your iterations shorter and you’ll get to guide your project more to your liking.

“The design process that supports delivering a great design document is not the same process that supports delivering a great product.”

“If the BA above was a piece of software, her users would be filing bug reports, working around her, and using her competitors instead.”

In Who are your Users? she contemplates the general state of command and control, and how the system is not really set up to offer feedback on various forms of communication (like design documents or requirements documents), and as such it is hard for them to get better.

Presenter: How tall am I?
Crowd:5′8″! 5′9″! 2 metres!
Presenter: Go on, you can manage more than that. How tall am I?
Crowd: 6′2″?
Presenter: Come on! You can do better than that! HOW TALL AM I?
Crowd: (Giggles nervously.)
Presenter: Just because a project manager tells you you can do more, it doesn’t make it true.

If you’ve ever felt burned by an estimate, you’ll enjoy the levity.

“There is no end-state with Agile or Lean. You’ll be improving, and continue to improve, trying new things out and discarding the ones which don’t work.”

This is what appeals to me about agile. It isn’t a destination, it is a mindset of improving continuously. I look at corporate waterfall processes, and the thing that hurts the process far more than anything else is that it is considered to be a complete and well-rounded, immutable process.

The problem is that it doesn’t work well in every situation. Facts confront the reality (yet another project delivered late and over budget!), but process isn’t blamed … the people are. “You were not following the process as closely as you should.” is the common explanation you hear. “We need better documentation!” is another. But these strike me as a rather inhumane approach. Do you really want to blame your own people (of whom you would like to remain productive, and have been added to the staff at considerable cost) when the evidence suggests that it is the process that is broken?

“A small engineering firm axed the company lunch room and eliminated over $200,000 per year in costs. That gave an immediate boost to the bottom line. [... however,] A more insidious side-effect was invisible (at least on the balance sheet) for several months.”

Read her full post to see what havoc this cost saving effort did to the company.

But how would the corollary go? If you want someone else to do it right, do you: a) exhaustively document how to do it -or- b) have an open, honest, and regular conversation with them?

My next question: if your practices do not line up with your answer, why not?

Of course, everyone says quality is the #1 priority, but given the triad of time, scope, and quality – how do people act?

My experience is that a deadline is set first (time is priority #1), then what can be done in that time is ascertained (scope is priority #2), and then the unit test, regression tests, etc slide (quality is priority #3) to ensure the time & scope are met.

I don’t think this is malicious — it is just that when you’re focused on the short term, a missed deadline is much more visible than a missed quality goal. Technical deficit issues with quality can hide for months or even years without ever being caught – so naturally they get a low priority.

My advice: If you want to think in the long term, set the quality standard first and set the deadline second. Missed scope can be addressed in the next iteration, but missed quality may never get fixed till your whole system crashes.

“Why is documentation so important to us? It’s because we’re used to using documents to carry our thoughts and ideas to other people, other places, other times. Documents are good at the “other places, other times” part. Documents can be good at transporting ideas to “other people,” but it’s really hard work.”

When you are on a team that is co-located, it’s a lot easier to have a simple face-to-face conversation. Time spent creating a document and time spend understanding a document are all to waste if it ultimately falls back on a conversation to clarify the original intent.

My suggestion: start with the conversation. Then, evaluate what is lost in translation. I’m guessing you will find that the conversation is far more accurate in transporting ideas than a document — and it takes a fraction of the time to complete.

“In my experience, most engineers with more than five years of experience are actually fairly good estimators, they just can’t estimate the amount of weekly bureaucracy they have to deal with.”

“Let’s face it. Our industry has had some challenges when it comes to setting expectations around estimates on software projects. It’s not that our estimates are necessarily wrong (though they almost always are). It’s more that too often people have looked to estimates for something they can never give—an accurate prediction of the future. [...] The simple fact is that accurate upfront estimates aren’t possible and we need to stop pretending that they are.“

[emphasis added]

“Don’t call your defects ‘bugs’. Call them ‘time bombs’ instead.”
- Watts S. Humphrey

From Wikipedia: “Watts S. Humphrey (born 1927) is an American software engineer, key thinker in the discipline of software engineering, and is often called the father of software quality.”

He has a recent book out that looks like it could be good, Reflections on Management: How to Manage Your Software Projects, Your Teams, Your Boss, and Yourself.  Has anyone read it?

[via @jurgenappelo]

“Status reports should report progress to plan. Tasks and the execution of tasks are not measures of progress. The production of deliverables are the measure of progress. [...] This is a common mistake of confusing effort with results. ‘We’re completing all these tasks, so we must be making progress.’ It’s results that measure progress, not the effort.“

“The World Has Changed – Why Haven’t Your PM Tools and Approaches?
In the last 10 years many changes have occurred in the world of managing IT projects, yet we still see the same tools and approaches being employed. Is this because they are classic and timeless? Are the traditional PM approaches so successful that they do not need to be dragged here and there following trends and immature technology fads? No, I fear it is more that people are creatures of habit, and the usually more mature project management community, are worse than most at evaluating and adopting new approaches.”

The first thing you must do is admit you have a problem with your project management process. It isn’t the business analysis, coders, or testers that is broken. It’s the process that is broken. Not the people. Once you can admit that, the world becomes much much less stressful.

“As one of the few people who has read the CMMI book from cover to cover, here’s what I think: In process-speak, the notion of maturity is backwards. [...] A mature person is one who is highly conscious of when it’s appropriate to follow rules and when to break them. A mature person is largely self-guided. Only in exceptional circumstances does a mature person need to refer to or appeal to a rulebook at all. In such cases, the issue is that someone believes that the rulebook isn’t working, and in such cases, consensus between mature individuals and organizations—not the rulebook itself—makes the determination as to what should happen next. Mature people know that rulebooks need to be interpreted.”

He sums it up by noting that:

“A mature process should encourage risk-taking and mistakes while taking steps to limit the severity and consequence of the mistakes, because without making mistakes, learning isn’t possible.”

There was a workshop specifically for Visual Management at Agile 2009 and a subsequent write-up on the presenter’s Visual Management Blog. But don’t be fooled – while this may be gaining traction in more technical areas, this will work for anyone’s project. There are lots of great pictures of examples and is worth your time to browse the pictures even if you don’t read the whole post. I’d suggest starting here.

I’m amazed at how well a non-technical solution can communicate to everyone on (or off) the team.

“Plans aren’t sacrosanct — they’re meant to be flexible guides, not straightjackets. Agile project leaders focus on adapting to inevitable changes rather than opposing them. In this way, value and quality are the end goals and the plan becomes a means to achieve them, not the goal itself.”

I found this to be a good reminder. I mean, the point of documentation is a simple one isn’t it? To convey ideas and intent clearly and without ambiguity. We write it down because we can’t remember long enough or clearly enough, or we don’t trust the people we are working with enough. (“I asked for X” “I thought you asked for Y” “well, let’s go look at the document!”)

If we worked in smaller iterations (with people we trust), our need for documentation would decrease exponentially. With contract thinking (ie, everything must be written down and signed) increases project cost by 30-50%. That’s a lot of waste for a problem that is pretty easy to solve.

I suppose there is a secondary purpose to documentation that focuses on tracking the history of an item. But let’s be honest – how many times do you go back and look at project documentation after it has been released into production? In my experience, the more detailed the document, the faster it becomes irrelevant and unhelpful.