30.4.09

Yesterday’s scrum

created at TagCrowd.com

23.4.09

Dinner @ the inn

Yesterday was St. George's day and in celebration of the patron saint of England, I went to the local Inn where they had layed out the very best in English cuisine. This ranged from the curiously named toad in the hole to the delicious Shepherds Pie.


19.4.09

When Paradigms Collide- Sorting Spatial Data using the List Metaphor

Given a spatial dataset that comprises physical locations that must be traversed efficiently, what’s the simplest solution that would accomplish this task?

Trouble booting from CDROM on Sunblade 100.

Possible causes:

  • Corrupted media
  • Faulty CDROM drive
  • Non-bootable media
  • SunOS 5.9 limitations booting Ubuntu/Solaris 10

A lean view of scrum

The sources of waste are:

  • Third-party delays in providing inputs required for the upcoming sprints
  • Stories with insufficient detail to ensure that the team proceeds without interruption
  • Scrum is yet to gain traction; the old way of doing things still haunts the project
  • Delayed feedback
  • Developer distractions – meetings; problems with machines; network connectivity; complex build process

NIH…

When a developer inherits a codebase, there is always a case of NIH(not invented here) syndrome. I am guilty of it, but with experience and professional maturity I have become more objective in my evaluation of third-party codebases. Recently, I had the chance to work on a codebase that ticked all the boxes of what a good software application should contain. The codebase exhibited the following characteristics:

  • Unit testing and Mock objects
  • Dependency Injection
  • IoC Containers
  • MVC
  • N-tier architecture(and a slight hint of domain driven design)
  • Fluent Interfaces
  • NANT builds
  • Code-generation
  • Template meta-programming(generics)

These are fairly advanced concepts in software engineering and represent the software engineering zeitgeist. Unfortunately these practices will be lost on the majority of enterprise developers(unless you are working in a dedicated software shop that’s at the bleeding edge). For the typical enterprise developer, this translates into is software that is harder to maintain, extend and for which the sprint velocity is going to be dismal. The inheritors of the codebase have the additional task of understanding the domain and the engineering approach.

The question then becomes: how do you balance the need to create supple software systems whilst staying true to the software engineering discipline. Can you sacrifice the need for rigour in favour of comprehension and program understanding or vice-versa?

From XP Developer to ScrumMaster

As luck(or misfortune) would have it, I have been tasked with ensuring that the team delivers the right software on time and to the product owners’ satisfaction. My previous forays in extreme programming(XP) mean that there is zero cost of adoption of this new way of working. It could be argued that scrum and XP are polymorphic. They both inherit from the same agile shrub.

It is tempting to approach the scrum master role from a developers’ perspective given that I am a developer to the core. But this misses the essence of being a scrum master. I need to balance the demands of the product owner with those of the development team whilst being aware of the latent political interests that subtly influence the project. Some of these interests have a less than positive impact on the project and are impediments that need to be reported if the project is not to grind to a halt.

Agile is new to the organisation and the idea of product owners, sprint velocity, burn-down, sprints, product backlogs, sprint backlogs is alien in certain quarters. It is not uncommon to be asked to provide an estimate on the spot without consulting the team. My advice is don’t do it and don’t over commit the team.