Notes from Agile 2006 and Comments on Testing

Notes from Agile 2006 and Comments on Testing

Agile 2006 the conference has come and gone. It was a good and eye-opening experience for me. I had lots of great conversations in the Net Objectives booth and over coffee. I got to help lead a session or two. And I had fun with customers and colleagues. All for something I really believe in, this connection between lean product development, agile software development, and technical skills, supported by lean management systems and tools.

In this podcast, I thought I’d share two or three observations of my own observations from the show and then ask Rob Myers to talk about a conversation he had in our booth with a skeptic. We are going to be turning to issues around testing and QA and this makes a good start.

I used this graphic to describe what we mean. I got to calling this the “three legs of the stool” for effective software development

VersionOne is cool

VersionOne gave away the coolest stuff: mini-rugby balls and rugby shirts (for Scrum). And their large screen TV had the "sizzle" factor, showing off the VersionOne tool quite well. And their tool is very nice. I am using it now and find that it works like I would expect and does not get in the way. Just what you’d hope for in an agile project support tool.

We partnered with VersionOne to offer a cruise as an expression of thanks to our customers and associates. And to give them and us a chance to talk and connect. It was a lot of fun, a great way to unwind at the conference. Both of us hope to make this an annual event at the Agile conferences.

Here’s a picture of the sternwheeler we went on. With thunderclouds in the distance, it was a gorgeous evening.

Mature Questions

The next thing I’d note is that people are serious about this stuff. There are people looking for what to do and many looking for what to do next, now that they have been using Agile for a while. There were a lot of great, insightful questions. Lots of good, practical insights being shared, together with some academic lessons.

It is clear the field is still growing. There seemed to be a good balance in topics, covering the “iron triangle” of people, process, and technology. When people issues are being talked about at a software conference, that is a good sign.

Hybrid Methods

It also seemed to me that almost no one is using a “pure” methodology, as defined in a book. Most companies I talked to are using a hybrid solution, choosing from among several approaches and adapting them to fit their own context.

And that is as it should be, in my opinion. Just because someone made something work in one context in one company doesn’t mean I should be able to bring those same practices and techniques over to my context and my company and expect them to work as is! I’ve had too many vendors come talk to me with their packaged methodology and, by the way, a tool ($$$) to support it. They are just trying to sell something and it has never worked out for me.

What works better is to understand the principles and strategies underlying a methodology. Then read about how the methodology is practiced at other companies to give me guidance and ideas about how I might use it at my own company.

That takes some thoughtful work. A friend of mine last night said, “but Jim, a lot of people simply want to be led, to be told what to do.” And that is where I would say, OK, there are lots of people who will take your money and tell you what to do, but it won’t be effective for you. This is knowledge work and learning and feedback and evolution are where it is at. So, it is better to have an experienced coach who can come alongside you and help you think about what will work for your situation and how to evolve an approach that fits your needs, that you can own.

Anyway, that is what I believe. And it seems that that is what many people are looking for. And it is the approach that people who are successful are using.

I want to use tools that fit me, not the other way around

Along that line, I also heard people say that tools were important. They are progressing beyond simply using stickies on a wall. They want to give visibility to governance structures about what is going on and to help them assess progress across the development and maintenance efforts. So that work can be prioritized and future iterations can get funded. Reporting is important.

But people want tools that can adapt to their hybrid methods, rather than forcing them to adapt to the tool’s methodology. I heard many people say they were resorting to writing their own tools, and that was going OK. Vendor tools that were interesting had to be flexible and light weight enough to adapt.

It is a balancing act. Whatever tool set you use, you want it to report enough and report accurately and yet you don’t want to impede the development team. It seems that is often yet another thing that falls on the ScrumMaster. And it is important.

Working a Booth is Fun and Work

One of the great things about working a booth at a show. Of course, there is a lot of mechanics to the booth itself – we tried to make ours a comfortable place for conversation (as much as a booth can be). I suppose as a training and coaching company, that is only appropriate. What we offer is who we are and the principles and practices we teach, and that usually involves talking… and trainers are always up for talking! Beyond the mechanics, you learn so much about how to communicate your message in a short time and get to listen to many reactions to that message. And you get to see what other vendors are up to and their approaches. It is an intense and educational experience. If you ever get a chance to work a booth for something you really believe in, take it. You will learn so much!

Conversations with a Testing Skeptic

The podcast contains a brief, 6 minute conversation with Rob Myers, a Net Objectives expert in XP and Testing. He had a conversation with a skeptic about testing. She had seen too many times where testing did not work – the code passed the test but the code was still wrong. Rob discussed the difference between UAT and Unit Testing. They require different strategies and timings and rationale in an agile context.

Testing should support your work on future releases. And it should help you know that your code is “Four Done”

Done: The system runs on the developer’s computer as expected.
Done: The system is verified by running unit tests, code review, etc
Done: The system is validated as being of deliverable quality with functional tests.
Done: The system is ready for production.

I want to spend several shows on this important area in the near future.

Recommendations - Training by Net Objectives