Published at: 10:08 am - Saturday August 28 2010
At LINEAS we currently run our first three Scrum projects. I am one of the three Scrum Masters. Unfortunatly we don’t have much experience with Scrum. Actually we only knew it from books, and this weird thing called internet, before we started. So there are lots of questions we have and only few who we can ask. Thats why we invented the
Biweekly Scrummy Scrum
Its inspired by the daily Scrum of a normal Scrum project but happens as you might have guessed every other week. The purpose of this short meeting is to exchange problems and ideas for their resolution and so far it works really well. Although it is really not much time we invest we learn a lot.
It is open to everybody interested in Scrum and it is limited in it time frame. It starts right before the lunch break, so there is a strong incentive for not letting it run to long. So far we don’t use a fixed structure. It is more like an open discussion group. Maybe in the future when we all have somewhat settled for a basic implementation of Scrum we’ll use a more strict structure, where everybody reports about her problems, possible fixes are discussed and a plan is formed about what to do about the problem until the next meeting.
You might think it is a Scrum of Scrums as described in many book, but I don’t think so since the teams involved are completely independent and don’t work on the same or related projects. Also it isn’t only for scrum masters, but for everybody interested. If comparable at all it is more like an Improvement Community as described in Succeeding with Agile, which is a group interested in a certain kind of change, working together in order to support that change. But so far we don’t have an improvement backlog, but maybe that would be a great idea.
What do you to improve you agile/scrum/kanban or projectmanagement skills inside your company?
Published at: 10:08 am - Sunday August 22 2010
How many databases run in your teams development environment? One for the complete team? I have seen many places like that, but please tell me: Why? You aren’t working on a shared files system aren’t you? How is a developer supposed to change the structure of that database without interrupting the work of the other developers? And just in case you haven’t noticed: Pretty much every RDBMS vendor offers free versions of their database which can run on a developer machine.
So when you answered the second question above with ‘yes’ you have a task for tomorrow: Make sure every developer has her own database instance (or schema or whatever you need to work independently from the rest of the team). In addition to that: you need an instance for the automatic tests of your Continuous Integration system, one large one for performance and scalability tests, one for manual tests/integration and of course one for production.
And just in case you are now thinking: “Hell how am I supposed to keep all these databases in sync?” You are having a gapping hole in your software development process. I’ll cover that in a different post.
Published at: 10:08 am - Sunday August 15 2010
Sometime ago I blogged about JUnit @Rule Annotation. In the meantime I got the chance to use rules in a real project. I must say: Rules rock! Let me tell you about my use cases.
- I am working on a Swing project (It’s OK, it’s not as bad as it sounds). We have many tests that create components and check certain properties. Although they never get shown in the traditional sense, Swing documentation requires all manipulation of Swing Components to happen in the Event Dispatch Thread. We have an EDTRule, which runs every test using SwingUtilities.invokeAndWait(). It works like a charm. We actually had a dozen tests that would fail under real weird conditions, which behave nicely since they where adorned with an EDTRule. While the Rule takes care on the threading requirements, test stay nicely clean and don’t get poluted by SwingUtilities and Runnable implementations.
- Another class of tests runs scripts against a database. In order to reproduce what the database admins will do, we use SQL/Plus for this (If you don’t know SQL/Plus consider yourself lucky). One problem with these test is, that a small bug in a script might cause SQL/Plus to await user input. In order to prevent the test to hang forever we implemented a TimeoutRule. Each script that gets started puts its Process instance into the rule instance, and the rule instance will destroy the Process after some specified time. Note: JUnit comes with a similar Timeout rule, which will let the test fail after a timeout.
- We have an ApplicationRegistry, which is basically a singleton map containing Implementations for Interfaces. Each test should setup the ApplicationRegistry with whatever is needed, and clean it up afterwards. Often developers forget the last part (When I say developers I am talking about myself). For this we have an ApplicationRegistryRule. It cleans the ApplicationRegistry before the test and after the test. Since it is only one Rule instead of a Before and an After method, it is easier not to forget one half of it. But the Rule does more: Before cleaning it, it checks if the ApplicationRegistry is empty. If it isn’t this means, some other test left it dirty. In this case the Rule calls Assertion.fail(). This way we found (probably) every test which left the ApplicationRegistry dirty. Very cool. A similar approach should work for other central resources like Spring Contexts and the like.