What is Agile?

There’s a thread on the Extremeprogramming yahoogroup attempting to define Agile. John Roth started this thread with a trial balloon of ways to recognize an Agile project from easily observed practices. I have a bit of difficulty with this definition; I think that it’s too prescriptive and, while it could be a useful heuristic, would miss the mark in numerous cases. To my mind, it doesn’t zero in on the heart of Agile practice.

So what is the heart of Agile practice? In the ensuing discussion, Dale Emery posts a message the turns attention to feedback.

The whole team focuses intensely on producing accurate, relevant, timely feedback about product, project, and process.

I’ve written about the importance of feedback, before. Using feedback is not the defining aspect of Agile, of course. Using feedback is the basic mechanism for any control system. Read More

1 Comment

Categories: Customer Collaboration Responding to Change

Tags: ,

Making software visible

I was reading Jerry Weinberg’s book, Quality Software Management: Vol. 2, First-Order Measurement, and came across the following:

Software’s nature is to be invisible, unless we work to make it visible…. During a construction project, we can see the building rising; but during a software project, all we may be able to see is a programmer staring at a screen.

This got me to thinking, as Jerry’s writing generally does. Read More

1 Comment

Categories: Working Software

Tags: ,

Time flies like an arrow…

… and fruit flies like a banana. It’s amazing to me that it’s been three weeks since my last post. Sometimes real life has a way of consuming the time, leaving little left for philosophizing.

During this time, Brian Marick has been stirring things up at the Agile Alliance. I’ve joined in the discussion of his observations and proposals only a little. Brian’s turned over a lot of stones at once, and it takes me awhile to examine all the things that have been living under them. Being a Myers-Briggs introvert, I tend to discuss these things in my own head before displaying them to the world. Here, though, I’m just thinking out loud and I haven’t come to any conclusion. Read More

4 Comments

Categories: Uncategorized

Tags:

Making TDD and Java Swing behave

Recently, I wrote about using the JfcUnit and Abbot frameworks to test-drive the creation of a Java Swing GUI. Since then, a post by Liz Keogh on the ExtremeProgramming yahoogroup led me to another option. It a wrapper around Swing written in conjunction with JBehave, but as Liz points out, it’s not dependent on the framework and can happily be used with JUnit, also. I like the fact that it’s really lightweight and fast. Read More

2 Comments

Categories: Tools and Techniques Working Software

Tags: ,

TDD and Java Swing

It’s been awhile since I’ve written any Java Swing code, and doing so now is making me feel a little stupid. Test Driving the development of Swing hasn’t improved much since the last time I did this.

Back in 2003, Jeff Waltzer and I decided to experiment with TDDing a Swing application to see if GUIs could be test-driven. It wasn’t always easy, but we convinced ourselves that they could. We started out rolling our own Swing test framework, but soon found ourselves immersed in AWT threading issues and Swing peculiarities. So, since we seemed to be headed down the road of reimplementing JfcUnit, we decided to switch and use the real thing. Read More

3 Comments

Categories: Tools and Techniques Working Software

Tags: ,

Amplifying Your Effectiveness

Johanna Rothman’s recent post on the AYE Conference prompted this unsolicited testimonial.

If you’re a techie working with people, you can learn loads about being more effective by attending this conference.  This is no sit-in-a-room-and-listen sort of thing.  You’ll get involved and learn lessons you’ll never forget.

I’m an independent consultant and pay for my own training.  This conference is one I won’t skip.  It’s well worth the cost.

No Comments

Categories: Uncategorized

Tags:

TDD and Exploratory Testing

I’ve often found that Developers and Testers misunderstand each other, even when they have a congenial relationship. (And in some shops, the relationship is anything but congenial.) Developers often don’t see the value of the Testers, or get annoyed that the Testers find issues that weren’t mentioned in the requirements. Testers often think Developers only consider the nominal cases, and don’t give enough attention to the edge conditions. Often, neither understands the others point of view. Michael Bolton, on the agile-testing list, said, Read More

2 Comments

Categories: Working Software

Tags: ,