“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.”

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?

“Things take the time they take, not the time you hope they will take. Pushing for half-time produces half-baked.”

I absolutely agree! When you push for a project to complete faster, something has to give. And more often than not, it is the quality that suffers because that’s the easiest cutback to hide in the short term.

Jerry is an author of more than 40 books, including “The Psychology of Computer Programming” and “Introduction to General Systems Thinking” and was the Manager of Operating Systems Development in the Project Mercury (1959–1963), which aimed to put a human in orbit around the Earth. (Thank you Wikipedia!)

“Doubt is the best QA.”

When you are doing quality-assurance testing, doubt is what will cause you to check (and recheck) all sorts of things. They may work just fine, but you aren’t sure, so you check. This is a great attribute for anyone who is testing the quality of a thing.

If you look at the corollary, it may become more clear:

“Confidence is the worst QA.”

Do you want your testers to come from a place of confidence (“Of course it works!”) or of doubt (“I’m not so sure it works.”)? I vote for the latter. They will be far more careful and complete in their investigation.

“competitive pressures (and greed) have encouraged most organizations to turn their workers into machines.

• If we can measure it, we can do it faster.
• If we can put it in a manual, we can outsource it.
• If we can outsource it, we can get it cheaper.

The end results are legions of frustrated workers, wasted geniuses each and every one of them, working the automations, racing against the clock to crank out another policy, get through another interaction, see another patient.”

I think there has been a long good run at “doing more with less”. It’s a good goal from the perspective of the employer, but needs to be tempered by the fact that you have people (not “resources”) working for you. People have their own needs and aspirations, and the best productivity will come from an arrangement that is good for both the employees AND the employers.

I’m optimistic that the next decade is going to bring more humanity and more rationality back into the work place.  I think this is in part from the adoption of agile, and in part, due to the new focus on social media. It looks a whole lot worse to be posing as a personable corporation instead of actually being personable, and people can tell the difference.

What do you think? Will there be more , less, or the same amount of humanity at work over the next decade? What do you think is influencing it?

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.

“Great design does not come from great processes; it comes from great designers.”

This seems so natural and correct when talking about design. Applied to other professions, you might see:

• Great software does not come from great processes; it comes from great developers.
• Great engineering does not come from great processes; it comes from great engineers.
• Great testing does not come from great processes; it comes from great testers.
• Great management does not come from great processes; it comes from great managers.

Yet time and time again, we lean back on the processes that in the best of situations are mediocre and brittle.

“Over the past two years I have seen a lot of debate about the success of Agile software development. Agile methodologies can produce great results. This is well documented. Yet, in many companies, they don’t. This has lead many people to question Agile. Some reject it altogether. However, the root cause of the problem isn’t in the Agile methodologies. The root cause that makes Agile fail is in the companies adopting Agile methodologies.”

Here are some of mine. Which do you disagree with? Why?

Workarounds are never a good thing. Short term workarounds are never short-term. They should be avoided. Do it right the first time, and if you can’t due to time or budget, delay the project. I hate technical debt.

Plan as you go is more appropriate to life and to projects, and returns better results, than planning everything up front (ie agile vs. waterfall). What we are talking about is predicting the future. Sure, you can be somewhat accurate, some of the time. But it’s just a guess. You’ll be more accurate if you don’t predict too far out. If you’re more accurate, you’ll be happier.

The problems of new are less than the problems of the old. On occasion you will run into a bug by upgrading software to the latest version. But I’ve found that on balance, I have far fewer compatibility & stability problems if I keep up to date. And as a bonus, new features!

Buy the well-built item once instead of the cheap thing multiple times. It’s eco-friendly, and you get to have the quality item to use every day. My wife and I had been wearing out a $10 garlic press once every 12 months or so with basic wear and tear — till we bought the Rösle Garlic Press for (at the time) $30. Five years later, it still looks good as new and works brilliantly.

Price is not correlated to the value. Just because it’s expensive doesn’t mean it’s worth a lot. Conversely, just because it’s cheap doesn’t mean it has no value. Open-Source Software, Wikipedia, a walk with your kids – these all have a lot of value, and they don’t cost you a dime.

Deals are rarely worth it. Everything is “on sale”. Everything is discounted. Of course, there are good deals to be had. It’s just that the effort to find and take advantage of the deal is more costly than any savings I might obtain. There is a reason why rebate forms are difficult to complete: it is in the company’s best interest that you never fill them out.

I believe in Scaling Software over Scaling People. See my blip on Techies and The Business, or the whole article here.

The most important attribute to any employee is their willingness and ability to learn. I’ve written about this one a lot. I think learning is the key to innovation, that through mistakes you get better, that Adapting is the Most Crucial Skill You’ll Ever Learn, and that progress (and who doesn’t want progress?) is an act of discovery.

So!  What are some of your beliefs?

Here’s what I think would happen:

• The completion of work would slow down for a couple weeks. Maybe a month.
• New talents would form.
• Inter-team communication, understanding, and empathy would get amazingly good.
• Cross training would actually happen, and single-points-of-failure would disappear.
• The business would see fewer things down because ___ was on vacation.
• Then the completion of work would start happening faster than it ever had before.
• And new ideas for old problems would start cropping up all over the place.
• And a whole bunch of “broken” things would get fixed (poor processes, kludgy systems, etc).
• And the team would re- self organize, and perform like never has before.

It would be brilliant.

“Design global navigation last.  Before designing global navigation, design screens with only local navigation–how people do the work of that screen.  Then, as parts of the system are ready to release, create an application map that shows hub and spoke relationships, selection screens, modal screens and links and build just enough global navigation for the current feature set.”

I like the idea. Seems like it would generate more a more natural organization in the tool instead of a lot of artificial constructs used to categorize and sort the functionality ahead of time.

“Checking is something that we do with the motivation of confirming existing beliefs. [...] Testing is something that we do with the motivation of finding new information.”

So when you “test” your software, are you really testing? Or are you just checking?

“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.

“I think of functional spec as one of the worst inflictions that has ever happened to the software development world. I think functional specs are a relic of a time when building features was a very, very hard and long process and you had to do all of this upfront planning because once you wrote anything in software, it was pretty much impossible to change it. I don’t think that functional specs is a technique that’s any longer relevant.”

Bob Marshall (@flowchainsensei):
“You really have no clue as to how much your business success depends on software, do you?” #neversaid

Ben Simo (@QualityFrog):
“Compliance with standards makes sense when & where interoperability is more important than innovation & improvement.”

Wil Harris (@wilharris)
“New Apple mouse proves not only does Steve think we are too dumb for two buttons, we can’t even handle one. A mouse with no buttons. Nice.”

Jared M. Spool (@jmspool):
“Remember, if you torture data long enough, you can get it to confess to anything you want.”

Jeff Patton (@jeffpatton)
“Requirements are the boundary between what I get to decide and what you get to decide. It’s a fuzzy discussion, or DMZ”

Esther Derby (@estherderby)
“ppl talk about commitment as if it is an act of will. commitment requires will AND time, resources, skill, authority”

Bob Marshall (@flowchainsensei):
“So you’re all far too busy politicking and CYA-ing to actually bother about delivering stuff to the paying customer?” #neversaid

37signals (@37signals)
“The best way to have a good idea is to have a lot of ideas.” -Linus Pauling

Naresh Jain (@nashjain)
“Consistency is over-rated. Consistency is a big innovation killer. Let diversity & positive deviance help us explore better ways”

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.”