Agile @ JAOO 2007 #2

I should actually call this post; SCRUM @ JAOO because that was what the track was called. But anyway it was not only information on scrum that I am left with after the second day of the conference.

Key elements
Rythm is important. - Let it be the heartbeat of the team.
Roadmap is still important even you are doing agile.
Do not overload the experts, especially on multiteam environments.
Architecture is allowed! Abstractions and interfaces are a very good way of doing this. (Coplien had some really nice slides on this)
TDD is both good and bad (according to Coplien its only bad, but there where alot of discussions on this).
Domain is important. -It creates the bridge between developers, customers and users.
Retrospectives - Important for learning and communication (Prime Directive)

Wish I had more time to go in to detail on all the issues, but I will have to do that at a later time.

Agile @ JAOO 2007 #1

Yes, I'm attending the JAOO Conference in Denmark at the moment. Today I have seen most of the presentations in the agile track and I'm quite satisfied with the amount of information that has found its way through my ears and eyes to my brain. This information is now in a process of being mixed with my own experiences and thoughts. Hopefully on wednesday I will be able to go home and create knowledge by acting upon the informaton I now have.

I'll cut the chase and tell you. Agile Retrospectives by Diana Larsen was the last presentation on the track and its the one that still sticks in memory (The rest is written down in notes). The presentation was a small summary of Diana's experience regarding the facilitation of constructive discussions and retrospectives. One of the things she mentioned was that there is no blame in such a retrospective. The meaning is to find out what went wrong and fix it or to find ways to improve and not to finde someone to put your finger at. It is a team responsibility so there is noone to blame. Diana claims this is one of the key elements of a good retrospective, a safe environment where one can share thoughts and perspectives without handing out or be blamed for what went wrong (or right for that matter).

A second thing she mentioned was the amount of actions you should focus on for the improvement in the next iteration. This should be one or at the max two actions. These should be followed up in several ways. In the daily standing meeting was one, another being in the planning of the new iteration (ie put it on the sprint queue).

Diana Larsen inspire to a deeper look into retrospectives and from the feel of it, I think that my autumn books might be on the subject.

Have a nice night and I'll be back tomorrow with another tiny bit of the JAOO Conference

Friction and slow delivery

I was just reading up on my favourite blogs when i came over a interesting post on the From where I sit -blog. Michael S. Hyatt describes what he sees as friction when visiting a bookstore. The idea is to get the purchase happen fast enough so the customer does not change his mind or as in Michael's case, leave the shop because it took too long to get the purchase done.

Could we not draw parallel from this to our development of software and project practice? The customers want a new feature in an already developed software. We receive the request and we specify it further with the customer. We estimate the time it will take to develop the new functionality. Customer gives us clearance to start working on it. We work on it. We finish the development on the new feature and we test it. We do not deliver it, because we have more things on our list to do in this release. The customer knows this so he is patiently waiting for us to finish this as well, because he also wants the other changes. We test the other changes, we might find a bug and work more on the issue. Then we hand the release over to the customer so he can test it, this is 6 weeks after the order was placed. They find a bug which get reported back to us and we start fixing it. We deliver a patch for the release and they test this. All is well and the testing is over, the release goes to production. The users finally see the new feature which they wished for, maybe 3 months ago.

What if the process where a bit different? What if we develop the new functionality and test it and deliver this to the customer. The customer tests the new functionality while we develop the other requests on the list. The customer find no bugs in the functionality and we release it to production. Or if the customer finds a bug, he reports it and get a new release from us with the fix and maybe more new functionality in it. Maybe some of the other things on the list was finished and tested in time to get it with the fix for the new functionality. Customer gets the new delivery and test it again, now with additional functionality. It goes through and we release it to production, maybe 3 weeks from when the users wanted the new feature.

To me this sounds better than the initial way of doing things. If the functionality that gives value to the customer is done, give it to them! If the users want changes, make the change and deliver it to them as fast as you can. No need to wait.

There are of course issues around this. One of them being the ability of the customer to actually receive and test the new functionality as fast as you deliver it. Another might be that the initial software is used 24 hours a day and a production release will hinder them in their work and cost money. But I urge people to think on this and ask their customer if they really cannot receive and test small parts rather than big chunks of functionality. Do they really want to wait that long for something they ordered? Why should they order and add all these orders in to one delivery? Does 15 minute downtime on their production system really cost that much versus having users waiting for functionality for months? Do their lack of motivation towards the use of the system cost less?

In this post I have not even started talking about the cost of long feedback loops on the delivered functionality. I'll save that for another post sometime.