I finally got around to looking at FacesTrace, a JSF debugger. Looks like it might be helpful especially with the nasty conversion errors and other joys of JSFs six phase lifecycle.

After googling around tonight I’m beginning to think our experiments trying to do Agile with mainframe development are extremely rare. That’s right we actually have at least one pure Agile mainframe project. Apparently it’s fallen into more on an iterative waterfall approach, but we are almost off the bleeding edge on this one.

I’d love to hear about anyone else’s experiments around this, but I fear we may be almost alone on it.

At the end of a recent Sprint planning meeting, I realized we had the services of four separate PMs. Considering that’s over 50% of our available PMs I’m not sure why one project needed that level of help. I do know this particular project seems to be gathering up new documentation that needs to be done every Sprint. Time to start asking the “Does this add any value?” question.

Popped over to our local Java Users Group (JUG) meeting to hear a talk on Dependency Structure Matrix also known as Design Structure Matrix by a company called Lattix. Never heard of it, well neither have I.

The basic idea is it statically analyzes your project and maps dependencies between layers, or more accurately between packages. You can go in and define those layers and work with its simple model to sort of refactor the coupling out of your application. You can also add rules on what coupling is allowed and then run a quick report to see the exceptions. On top of that you can add rules around dependencies on external packages such that the only the DAO layer can use Hibernate packages for example.

Nice to see these sorts of developments as this can be added to your build process as another check, and it makes visible the dangers of coupling unrelated layers. Better to catch coupling early rather than later. The cost is $500 $495 for 500 classes or less, $1000 $695 for 1000 classes, and $3000 for the typical unlimited Enterprise license. I may add it to my todo list for looking into tools at some point. The only other tool that seems to do something like this that I was aware of before was Mike Clark’s JDepend, but I never had time to look into it much.

Kane Mar wrote recently about the difficulty teams have adjusting to finishing within an iteration:

Typically what this means is that the software will be code complete at the end of an iteration, but will not have been fully tested.

A comment that was frequently heard during the early retrospectives was that code was delivered late to the testers; usually just a day or two before the end of the iteration.

Over a year into our official Agile (PM/Excecutive sponsored) rollout this has continued to be our biggest common struggle. Keeping our QA staff busy on Agile projects often involves writing a few test cases up front and then slamming in the testing in the last 3-4 days of a 30 day Sprint.

The current mitigating ideas are:

• Actually use an acceptance test tool like Fitnesse to give testers work to do defining and writing acceptance tests.
• Break up functional deliveries to smaller pieces of functionality.
• Just do the testing for the last Sprint in the current Sprint.
• Writing GUI based regression tests on the past Sprint’s functionality.

We’re just rolling out Fitnesse on one project now so that strategy remains to be tested.

On the idea of delivering smaller pieces of functionality, we keep running into two roadblocks. One, is that on many projects we’re splitting development between web based OO software and legacy mainframe development. On the mainframe side they have been pretty consistent in sticking to a delivery in line with the end of the Sprint. So far no progress in getting that habit to change. Second, developers see a nice time box of 30 days and they want to fill it up with coding, not figure out how to deliver small bits of functionality that can be tested individually. We’re getting better at this, but often the argument is well I want to finish all of some module before I turn it over to QA and on the QA side they don’t want to ‘retest’. This has been getting better with practice though.

Kicking testing over to the next Sprint is pretty much an admission of defeat, but on one particular Agile project which involves a lot of parallel mainframe development the argument just comes up each Sprint that we should just throw in the towel and test the last Sprint’s code in the current Sprint. The dangers of this are numerous and we haven’t done it yet, but it’s a common refrain in retrospectives.

Finally, we have the idea of keeping QA utilized during the Sprint better by having them write automated regression tests. This is probably one of the better ideas, but we haven’t been able to implement it all that widely. The other issue is if the GUI is going to change significantly with new functionality the QA group often argues that they don’t want to write a lot of tests they’ll have to scrap and rewrite.

No clear best solution yet, but it is an area we’ve really struggled with.