Monday, September 27, 2010

As A User I Want To...

User Stories, especially if used in a very formal way, are much criticized by my colleagues. One point is that the user (in any role) most probably does not want to use your system but just to get it over with. So, whenever someone says "As a (role) I want to" it has become somewhat of a meme to say:


As a user I want to drink piƱa colada in a swimming pool

I assumed that this was true but I wanted to be sure and made some empirical studies and it in fact is so.

Photo: Heikki Pora

Tuesday, September 14, 2010

Rituals of Hypocritical Scrum

The Certified Scrum Master training does not make anyone a great Scrum Master. News at 11. But one thing I think it makes is better agile team members. I like to suggest CSM training to each team member I work with. The two days of Scrum training usually do not give much new about the roles, artifacts or ceremonies of Scrum to the attendees. But it still makes a difference.

As it says in Scrum Alliance introduction to Scrum "The Scrum framework is deceptively simple." In fact it is quite possible to start up doing a sort of hypocritical Scrum with all the ceremonies in place: plannings, dailies, sprint reviews and perhaps even retrospects. And fail. With hypocritical I mean Scrum without touching the core of Scrum - its principles. The ceremonies of Scrum become mere empty rituals without some understanding of the principles below them.

The principles of Scrum are in Agile Manifesto and in Toyota Product Development System. On a higher level it is in embracing change and concentrating on producing value. On method level it is in using pull systems and JIT, removing waste and doing continuous improvement of the system. 

Someone just tweeted that when you write code you should know at least one level of abstraction below the level at which you operate. For instance when writing C it's good to understand about the call stack and dynamic and static linking to libraries and optimizations at compile time. The same goes with Scrum. It is not enough to know the secret handshake. You must understand the things that can make your process work. And the same goes with Kanban, XP or other agile process models.

The CSM training does not teach you all the principles of Scrum. But it does one thing that is very important. It demonstrates some of those principles at work with some very simple exercises and thus usually gives a some kind of incurable agile brain tumor to most of the participants.

I find myself often in the empty rituals mode. I envy my colleagues like Kaira who seems to be able to work on the principles level all the time in his daily work. I just have to train my nose to smell my own odors to keep up.

Thursday, September 2, 2010

Our Continuous Delivery Process

A colleague of mine asked if I and a teammate of mine from my previous project could organize a small openspaceish tech talk on continuous delivery after our company's monthly meeting. To advertise it I drew a process diagram of our continuous delivery process:


  1. Teamsters pick up a new feature to implement from the features on our sprint board.
  2. They create a local or remote branch for the feature.
  3. They edit the text files in the source repository. This is also known as "programming".
  4. When the feature is ready the branch is pushed to the master branch in our git master repository.
  5. Hudson builds and tests a new version on every commit to master including all integration tests and Webdriver based browser tests. If the build is successful, new version of our application is deployed to a repository.
  6. Hudson is also used to deploy the latest successfully built version to production very early in the morning.
In haste and looking at the process through tool-glasses (mainly git-glasses) I forgot our step #3.5 which contains all the human process parts of our Definition of Done occurring between stages three and four: GUI reviews, exploratory testing, mini-demo to customer and customer acceptance of the feature.

So, compared to the well described and indeed very good git flow branching model we have a much simpler model with just master plus feature and fix branches and no develop or release branches as they have no meaning to us. This mainly because we only have one installation and one release of the application at a time running and we try to keep the number of features under development in one or two at any given time.