Monday, March 30, 2009

Saturday, March 28, 2009

Sunday, March 22, 2009

Is business value model overrated?

I often get asked how do we calculate business value for our backlog items. We have a (relative based) way to do it, but more importantly I have been wondering how much estimation is actually needed.

James blogged about "Maximizing Value with Agile.." and came out the following:
  1. Work on One Project at a Time
  2. Release Early and Often
  3. Adapt Your Plans
  4. Keep Your Options Open
  5. Plan at the Last Responsible Moment
If your company has clear vision where it wants to go ("we want to have more users for our website"), then your prioritization should be pretty easy.

Is your company just missing the focus and hiding it with a complex business value model?

Tuesday, March 17, 2009

Exposing Huitale Way - take 2

Again we are getting visitors from companies to see how we do agile. This time the guests are from Accenture and Leonidas.

Wednesday, March 11, 2009

Exposing Huitale Way

Today we're having a group of visitors from Houston Inc. to see how we do agile.

So cool to share some findings with other agilists :)

Monday, March 9, 2009

Manifesto for Software Craftsmanship

I just signed the Manifesto for Software Craftsmanship. Take a look at it at

Of course the manifesto does not matter if we do not act like we have signed it.

Sunday, March 8, 2009

Interact with your customer - this is how Mousehunt does it

"I think the main reason MouseHunt has become such a deeply engaging game is because we've included our users in the development of the game. We've done everything possible, used every method to get them to interact directly with us. The users have access to the development team (and each other) through the forums, videos, and a built-in chat system. We've decided to share a large slice of our office lives with them."

How could you do the same with your product?

See more at

Thanks for the link Rob.

Friday, March 6, 2009

Broken Build?

There is no way to be too serious about broken build..

Thanks to Ari for the link :)

Tuesday, March 3, 2009

Testing (teasing) your Product Owner

It so much fun (ok, it is about being a bit of nasty..) :)

Anyway, here's a story about what I did just recently when I was invited to join a "scrum" team that had some difficulties to deliver.

I was told that the team has been developing fancy system for 2+ years. The development was not too much guided (= missing leadership) so the team just did what was "wished" by "stakeholders" and now they were on their way to "put it out".

I tried to understand the system with help of some of the developers that had been part of the team. We went trough some of the functionalities together and after a while I got the impression that the system was way too complicated for any "non-techie" to use (yes, it was meant to be used by non-techies). I wondered who had requested such a features and yet approved the features in the demos.

I took few screenshots and went to the Product Owner (PO) to have a chat. I asked him to describe what the screens are about and in few seconds he admitted that he had no idea. Encouraged by that I requested if any of the stakeholders would know if I would visit them with the screenshots. Not surprising the answer was "I don't think so". I wondered what would be the cost of building such complex features.

When a "scrum" team delivers something that nobody has requested nor approved the demos must suck. I went off back to the team and asked how have they conducted their demos.

The team told that their demos were "practiced" beforehand (good? maybe..) so that the tester who will go trough the implemented stories knows all the "traps" that should not be touched. In another words demos were about looking good (~lying that it is done) and not letting the customer to trial. No wonder that they were not ready to put it out when the time had come.

Unit testing is overrated

When I present our case (400 acceptance tests, 30 unit tests) I often get asked
"How you can refactor without unit tests?". Well, it's easy, if the refactoring did not break my acceptance tests then I am safe. It seems that there is common misbelief that you need unit tests in order to refactor.

Lets look at the some view points:

1) Unit testing supports design (building the knowledge)
True, though you could as well use any other "tool" like CRC cards and you would not increase the mass of your "manufacturing equipment" than can be seen as waste. Acceptance testing also supports design by giving the focus and telling you when you have "done" with the story from functionality perspective.

2) Unit testing does not ensure that the totality works
... so you need the acceptance testing anyway.

3) Acceptance testing is slow, so therefore it is better to do unit testing
If something is slow you should not do it? That's just weak. You should look into tools like Selenium Grid.

4) Fixing acceptance tests takes so much time, refactoring unit tests is faster
So maybe your acceptance tests are not very good? Changes in implementation (not behavior) should not break your acceptance tests.

5) Unit testing is not really that much about testing
... but it may be a good tool for learning. Still unit test coverage does not mean anything really (neither does acceptance test coverage).

Of course you may have as much unit tests as you ever like - just give it a thought before jumping into it. :)

Update: Some people have taken this post as "Unit testing is something that should not be done at all". That is NOT my message - I think we need delicate balance and I would pursue that by "outside in"-approach where you take the user's view and start approaching the system from there, working from Acceptance test towards Unit tests. If you approach automation by implementing "inside out" unit tests you may get lost with the unit testing adventure.