It’s day 3 and this is a late night entry. At the risk of sounding like a broken record, I’ll say once again that was another good day. If you’ve been following along, you’ll probably notice that another good day has become the theme for me at this conference!

Testing As We Go: Perspectives On Testing As Part Of Done

This was an interesting session. It was my first look at the “No Bull Know How” stage where the organizers are trying a brand new format. The idea here is giving people 10 minutes or less to ask questions of an expert from the agile community in front of a room full of people. The expert sits up in an arm chair onstage and people queue up to sit on the couch opposite the expert to pick their brain.

Elisabeth Hendrickson of www.testobsessed.com, who is very well respected in agile test circles, was the expert in this session and the questions were geared toward quantifying the tester’s role as part of delivery.

Early on, Elisabeth reinforced the point that development and test are both part of a single team effort, not 2 separate efforts farmed out to individual development and test teams. There were interesting comments regarding what designers should do at the end of an iteration when there design responsibilities were done. First was the suggestion that instead of designers building up untested code by jumping ahead to the next iteration, they surf the web because doing nothing would be more productive in the long run that building up the technical debt associated with untested code. If surfing the web is no good, then maybe designers could be refactoring existing code as part of continuous clean-up effort, or improving automated tests or scripting, doing exploratory testing or finding other ways of being productive that don’t involve writing new code and getting too far ahead of the rest of the team.

There was also talk about convincing designers to test their own code – which I whole-heartedly endorse on the verification side as well. I think Elisabeth’s comment was something along the lines of “your professional pride should push you to see that your code does what you expect” (i.e. if you care at all about the quality of your code then you should be testing it).

She finished up with the comment that done means implemented, checked and explored. We tend to associate done with (design) implemented, which is completely misleading. We also associate done with checked (which would be verification). The part that we might be missing is the explored. I think it’s rare you have hardware teams including all of the above as part of regular DONE milestones which is an area of significant improvement in my opinion.

On the downside, in this session I discovered that not all software teams have an automated regression suite. Some actually have people manually applying scripted test procedures. That caught me a little off guard. I couldn’t imagine being the person in charge of manually plunking through test procedures for days on end as part of a regular release process. If manual regressions were part of hardware development, I think I’d have changed careers by now.

How To Play Basketball With A Soccer Team? Making IC Development More Agile

Here’s another hardware talk, the second of the conference, from Tobias Leisgang of TI in Germany. I thought this talk was outstanding. Tobias and his team are 1 of very few examples in the world where a hardware team is working together using an agile approach. I think it’s becoming increasingly common to see individuals working with agile techniques but less common are full teams which makes this talk special.

The soccer/basketball metaphor worked well. When teams move into agile, they are taking on different techniques, rules, pace, objectives and other tools and skills very similar to how a soccer team would need to pick up new skills if it left the pitch for the basketball court.

Tobias shared insight on his group’s use of cross-functional teams, iterative development, daily stand-ups and a few other practices. Interesting was how the team had transitioned from a 14 week to 8 week to 4 week iteration cycle. Also very interesting was how his team was offering early feature sets on FPGAs which customers were using for early software development. An FPGA was part of there deliverables at the end of each iteration without significant extra effort.

If you’re looking for a success scenario and some hard experience, I’d suggest downloading and flipping through a set of Tobias’s slides from the Agile2012 program site.

Great talk! Thanks to Tobias, we’ve doubled the hardware development content at the conference in only a year :).

Craftsmanship or ‘The only way to go fast is to go well’

Here’s another talk from the No Bull Know How stage this time with expert Bob Martin. Bob is the clean code guy and signatory to the agile manifesto. Judging by his performace in this session, he’s also part stand-up comedian! This was a fun session. The people in the room obviously have great respect for what Bob has done part of the agile movement and what he’s doing now to promote a finer level of craftsmanship in software development.

The Q&A was light for sure but the underlying message was actually quite serious. As agile has matured, the emphasis on craftsmanship has begun to wane. Software developers, Bob asserts, should be taking quality more personally and handling their work like professionals to the point where a person can take pride in their work. Software craftsmen should be working toward the point where nothing leaves QA without satisfying a number of criteria… it should be understandable, decoupled, tested (with tests that run quickly and often), etc. He also made the comparison, several times, that software developers should be mentoring new software developers in the same way doctors train new doctors. That’s a good point. Doctors aren’t performing heart surgery on their first day, they build up to it over years. The same type of mentoring should be happening in software development.

Looking Ahead…

Unfortunately, the only thing I’m looking forward to now is sleep. Lights out. We’ll talk again tomorrow!

-neil

PS: If you’re interested in the rest of the week, there’s more on my Agile2012 page!