Posts Tagged: agile


14
Oct 10

Doubt

@rands had an interesting tweet:

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


20
Sep 10

Turn your workers into machines

Seth Godin in Linchpin about the de-humanization of work:

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


16
Sep 10

Do something right?

When you want something done right -the saying goes- do it yourself.

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?


12
Sep 10

What is fixed? Quality or Time?

Ken Schwaber was contemplating team dynamics: they were taking on too much work in hopes of meeting a time frame. The deadline (time) was fixed and the features (scope) were fixed, and the outcome was that regression testing, performance testing and unit tests, were skipped (quality).

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.


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.