Posts Tagged: agile

Main — No Comments
27
Aug 10

Great Design

Fred Brooks in an interview with Wired:

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

Main — No Comments
23
Aug 10

Nash Equilibriums

Kallokain smartly applies some game theory to agile adoption:

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

Main — Comments Off
12
Jul 10

Beliefs

Beliefs: The framework of things you hold to be true, and of which form the basis for all of your decisions.

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?

Main — 1 Comment
4
Jul 10

Least qualified for

I love this question: “what would happen if everyone on the team did the job they were least qualified for & spent half their time helping others?” @KentBeck

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.

Main — Comments Off
2
Jun 10

Global Navigation

Esther Derby has some advice about site (or application) navigation:

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

← Older Entries