Categories
Development

Learning Scrum

Geoff Watts was in Oslo a while back giving a talk on how British Telecom introduced Scrum to the organisation. Important elements in his talk was how to motivate, and how to let experience gained in some teams propagate to other teams. To summarize in short it was by stating the goal instead of how to do it (deliver something every 90 days), and have experienced coaches come in and lecture but also participate in the new teams that are just started and trying to find their way.

Similar and more specific ideas can be found in the slides Jeff Sutherland did at Google. I would love to hear the talk, but the slides gives a lot of interesting information on how they introduce new teams to Scrum at MySpace. Some of it seems a bit harsh, but I do actually believe some teams needs a painful bootstrap to get into it.

Categories
Development

Agility in operations

It seems like Facebok is pretty agile in how it handles new features and roll outs. According to an article on the High Scalability site they actually do major releases every week. One of the things that struck me was this:

Be Innovative, Not Safe. Fear of failure often shuts down the organizational brain and makes it hide behind excessive rules and regulations. A technology company should have a bias towards action and innovation. Release software. Don’t stifle genius. Rely on your tools and processes to recover from problems.

This isn’t a solution to problems, but it is a pretty accurate description of what I want to achieve myself. Making a release shouldn’t be difficult or scary. This means that we need tools and methods that:

  • Enables us to be relatively certain that we don’t introduce any errors
  • Enables us to recover from a failure, because we will eventually fail

Tools like JUnit, Fitnesse, Selenium are all tools that allow us to verify the behaviour of our application. They help us verify that what we have done doesn’t introduce any errors. This should enable us to roll out quite easily, but I think in many projects one doesn’t trust the quality of the tests and you fear rolling out because you don’t have a good recovery plan.

I think we have a lot of tools available to us when it comes to writing tests, we just have to get better at using them, and eventually improving the tools. Where we seem to be missing is the part where we do good rollbacks. Maybe we don’t even need tools for that? I’d like to hear how you do it, and what tools you use or are missing.

Categories
Development

Database as a service

I’m still out on if the database as a service is a good or bad idea. I am leaning towards the latter though.

One of the scary things most developers do today is refactoring the database. I actually think a lot of good refactorings just isn’t done because it becomes a large and daunting task when it comes to databases. Exposing your schema directly to other consumers just makes this worse. An abstraction would help some, at the cost of maintaining the abstraction. I do feel that this abstraction could be functions and/or views, but for most Java developers this is much harder to maintain than a Java abstracion.

Check out this blog for some arguments against database as a service.