I learned a few days ago that a simple information radiator such as a task board can be extremely threatening. Our PM/Scrum Master on a project announced a recent unilateral decision to switch meeting rooms simply to escape the dangerous distractions of a task board. Apparently the team found the task board a more useful way to keeping tabs on progress, but the PM preferred a spreadsheet and didn’t want to allow for any other options on visualizing progress.

The bigger picture is that we’re still fighting a lot of problems with understanding that Scrum is built around the idea of self-organizing teams not command and control PMs. If the team decides on an approach that’s working for them it isn’t up to the Scrum Master to overrule them and then attempt to enforce it via dictating.

Who knew a yellow sticky note was dangerous.

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.