Grails or Rails or JMatter or Naked Objects

Martin blogs about Groovy or JRuby.

Coincidentally I've recently needed to write a quick workgroup application (JMatter or Naked Objects but I also considered Grails or Rails. My first attempt with JMatter ended up being what I continued with though I did take a look at the other options.

JMatter was very quick. It provides an embedded database, H2, and an embedded servlet engine, Jetty. You write Java extending special classes and everything else (persistence via Hibernate, Swing UI with a lot of pre-built features) is generated. To clarify, my current application is generated from 3 classes. I think I'm starting to encounter the boundaries of all this black magic though now that I'm trying to implement some non-standard behaviour.

I actually thought the code and documentation for Naked Objects 3.0 was better than JMatter, at least at first glance. However, given the start-up time wasn't as quick, I didn't investigate further. I'm wondering if the uglier web site played a part in that as well.

Between Grails and Rails, I liked that Grails was designed to be seamless with the Java eco-system since I'm wary of leaving too much of an alien artifact. I also liked that you start with the domain model and generate the persistence and scaffolding UI. Like JMatter, Grails provides an embedded database (hsqldb) and an embedded servlet engine (Jetty). This made it faster to experiment with than Rails in my environment. I ran into a problem when I did my first experiment which ended up being trivial to fix but in the meantime, I had already progressed far enough with JMatter that I dropped Grails.

Given some potential JMatter limitations (i.e., users need a more current JRE to support the Swing UI), I may end up resurrecting Grails. JMatter seems to have some experimental web UI generation support which is another option.

All you need to fail is to not prioritise

If you want to guarantee that your project fails, all you need to do is put every feature into the Must Have category.

If you want to be more subtle about it, put a few items in the other categories. But make sure the far and away majority are in the Must Have pile.

Given the difficulty and creativity required to prioritise effectively, most people won't realise that you're deliberately sabotaging the project. Just blame the commitment of the team if anyone calls you on it.

Are you laying bricks?

Or are you building a cathedral?

But what if you're not really building a cathedral? What if you're building a brothel?

Then perhaps you'd rather just focus on laying bricks.

That's the importance of having a worthwhile purpose.

The price of overburdening

... is abandoning learning to "focus on delivering".

Fishbowl standup

With large teams, daily standups are more prone to the problems of low energy and lack of engagement. It's just too easy for the meeting to drag on and people to be apathetic in the large crowd.

Typically with a large "team", it's really a group of smaller teams that are working together.

One way to dealing with it is to split up into separate standups, perhaps with nominated representatives to convey information between groups.

I don't like this because you no longer have a shared ritual for the entire group and you have high risk of mistranslation and filtering.

Instead, inspired by the Fishbowl dialogue format, do a Fishbowl standup. In this format, you have representatives from each smaller team in a circle in the middle with the rest of the group observing around them.

The smaller number of participants actually talking means it is much quicker and because the representative is being watched by the rest of their team, it's less likely that you get mistranslation or filtering.

In practice, this form still doesn't prevent any particular team within the larger group to be disengaged from the process and share nothing. But I still find it more energetic and engaging than a massive standup.

I haven't done this enough to work out all the kinks. For example, I like Brian Marick's Actor Network Theory standup approach and I think it may help provide more focus for us.

In any case, I'd be curious if anyone else tries this and has a good (or bad) experience.

Ricardo Semler at MIT Sloan School of Management

Via Matt at Signals vs Noise,

A great talk by Ricardo Semler at the MIT Sloan School of Management.

Neat to associate a voice with the words from Maverick! and The Seven Day Weekend.

Limiting votes destroys information

You're in a retrospective. You have items in various categories.

In order to prioritise for further discussion or action, you decide to use a vote.

Now you might think that limiting votes (e.g., 3 votes per category) is a good system. After all, it forces people to decide what is important.

But actually it's a worse system because it destroys information. It destroys information because people are encouraged not to vote for what can't win and because we don't get any data on any items below the 3 vote threshold.

A better voting system is to not limit the number of items people can vote for but still only allow voting once against each item.

In practice, this is a lot quicker (you don't need to stop to think whether you're wasting your vote) and provides much better information (you can distinguish what received moderate or few votes vs zero votes).

Reflexively, people assume that you can just vote for everything and that will be a problem. But of course, voting for everything is equivalent to not voting at all so a quick reminder to the group is all that you need to deal with that.

The two main topics to learn in Agile/Lean

When going down the path of Agile/Lean, there are two main topics:

1. Learning to manage to capacity
2. Learning how to improve process capability

If you can't accept the first point, the second point won't make any difference.... in fact, because of overburdening, you'll make the second point harder.

The Warrior Within is like the Highlander 2 of Prince of Persia

I recently bought Prince of Persia: The Two Thrones Special Edition for the PC, which includes the previous two games in the series, and so played through Sands of Time for the first time. Great game and especially impressive given that it's 4 years old.

Now as for Warrior Within... it's like the Highlander 2 of Prince of Persia. Everything is worse. Story line, dialogue, the look, the music, the game play, the camera control, audio synchronisation(!)... everything is just poor. I'll probably force my way through in the interest of following the story line to The Two Thrones but it's shocking how poor this sequel is.

Update: Couldn't bring myself to keep playing Warrior Within. Who thought that soundtrack was a good idea? Moved on to Two Thrones which is quite a bit better but still missing some of the Sands of Time mojo though it adds its own with a few interesting new gameplay elements.

The reason why Guerilla SOA is not common sense

Jim Webber says that Michael Nygard's description of Guerrilla SOA as "common sense" is accurate.

I disagree.

The Guerilla SOA approach may be correct and reasonable, but it's not common.

Why?

Because many organisation have difficulties accepting the concept of decentralised control as being a superior model when their people management structure is based on centralised control.

Conway's Law strikes again.

Then again, maybe I just have consultant's bias. All I see is when things aren't working.

Social responsibility?

An excerpt I like from Small Giants:

I have never encountered angrier and more cynical employees than those I've met in socially responsible companies that have been so focused on saving the world they neglected to do what was necessary to save themselves.

I've expressed similar sentiments in a different way:

What is a couple days a week helping a charity if you spend the rest of the week at work contributing to psychopathology?

A tale of tea bags and reuse

Jason Gorman tells a sordid tale of tea bags and enterprise-scale reuse:

What Bill forgets, of course, is the $20 cab fair and the extra hour and a half it would take either lady to get across town in order for this reuse scenario to play out. But he tells them to do it anyway, and declares it a roaring success.

Reflection is not confirmation, nor celebrating success

Via Dan Markovitz,

Matthew May on what "hansei" means:

Hansei is not about confirmation. It's not about celebrating success. It's a sobering reality check, even when a project has been wildly successful. Were you to attend a hansei meeting following a resounding success at Toyota, you would be shocked at the tone of the meeting. It's stern and serious. Yes, the team greatly exceeded expectations, but exceeding expectations also means project members didn't fully understand the process, or else misjudged the impact of factors beyond their control. Their objectives should have been met. And even if they reached their exact target, the team must still examine their course of action and the interim measures, not just the final results.
...
The hansei being conducted now will result in new targets, for the fruit of all hansei is new policy and the road to new policy is lined with sharp questions.

So some questions... how many sharp questions are left unasked in your retrospectives? in your organisation?