I’ve already complained enough about us not being agile enough. I also realized that complaining and crying will not help us solve the situation we got into. There were a few problems arisen, ranging from tiny to not-so-tiny. Of course most of them will not go away overnight. It’s useless to tell “we’re doing completely wrong” and not to do anything about it. As one of my former colleagues would always say, “the s**t has to go away”. However, it only goes away if we found out which the s**ty parts were.
As I’ve already mentioned, we somehow got far far away from different good habits and best practices. This had been a process, and I guess we’ll need time to get back on track.
So, here are some newly/re- introduced things I believe can help us perform better.
We believe in agile practices (or at least I hope most of us do). When it comes to development frameworks we use Kanban. However, with time we just forgot to do proper task aging. That is not that good at all, because this way we cannot measure our velocity (or lead time, if you like).
This is not that surprising, I guess. Nobody likes writing dates on small pieces of papers. Denting tasks is even worse; who wouldn’t get demotivated seeing their task full of dents. No proper aging – inaccurate measurements (as Andre Dhondt has pointed out in one of his workshops: what you measure is what you get). And that was the point, when we introduced, the date stamper:
This little thing has the cool property that you can have the current date stamped on your task with just a simple move. It’s easy to keep it up to date and it’s relatively cheap (and by relatively I mean very cheap).
So, how does this help? As I pointed out, aging tasks manually is booooring. However, stamping the current date on your task is fun. Since its introduction there has never been a single task without a very accurate timestamp.
Timestamps are used whenever a task is moved from one column to another. Such a way each column can have its relative lead time. It’s simple, time saving and once again; it’s fun! I recently overheard one of my colleagues saying “this stamping actually rules!”.
I won’t pretend the idea is mine. I’ve borrowed it from my fellow soccer player András Czigány. Great idea :-), problem solved, everyone’s happy.
The code improvements banner
We have a lot of legacy code to face with. Basically a good part of that code is older than some of nowadays’ pop idols. I don’t want to lie, that code isn’t of good quality. We’ve got long functions and classes, several code smells etc. Maintenance guys are having hard times fighting it, also minimalist bug-fixing solutions don’t really help us make the situation any better.
That’s what the improvements banner is used for. It is made of a simple (but large) piece of paper on our wall (beneath our Kanban board). I drew three columns on that paper: Bug number, improvement(s) and name. Bug number is pretty straight forward, let’s not talk about that. Improvement categories might be (but are not limited to): extracted classes, extracted methods, renamed classes and methods, extracted interfaces, extracted constants, added new test methods, added new test classes etc (renaming of variables don’t count. That’s too easy). Every time you fix a bug, you should track the code improvement(s) you’ve made. As these things are not so hard to do, you should pick and do at least one them at every bugfix.
So far we’ve got fixes like: “decoupled class X from class Y in order to follow the principle of single responsibility”, “totally refactored class Z”, “extracted constant C”, “Added test class and test cases to cover class Clazz”.
I’m really looking forward to seeing a huge number of improvements there. Slowly we can get rid of some ugly old code we’re currently afraid of. Baby steps, great achievements.
The weekly TDD “meetup”
Some time ago I got very sad about the status of TDD in our organization (here). Then I thought it would be a good idea to organize a weekly meeting where we could create a friendly place to practice agile development methods. Anyone could join, they just had to reply to my mail with a simple “yeah, I’m in” message. I though I’d be great if there were no speakers or instructors, but anyone could propose exercises they felt weak at.
There were no proposals for the first meeting, so I prepared a simple kata (given a Hungarian VAT number and an amount of money in Hungarian Forints. validate the VAT number and return the VAT-increased money, or an error message in case of invalid VAT number). Seven people (besides me) have attended the first session. We didn’t solve the exercise in rounds, but had some catch-ups at every twenty minutes; everybody told what ideas they went with, what tests they wrote, what their progress status were. It was good to see that they preferred pairing up over working alone.
After the session, one of my colleagues told me this was one of the best TDD sessions he ever attended. This -of course – made me very glad, however, I think we still got a problem here. The people who attended the session are not the ones who really need practicing. We’ve still got some “rebels”, who think “pair programming is a waste of time”, “refactorings are meant to harden integration” and “tests are for losers”.
Anyway, what I hope is that after a number of sessions we get some self-confident people, who can be “used” to pair up with those colleagues and spread the best practices. Anyway, I’ve already got some ideas for the upcoming events. I think we’ll definitely do a randori-based refactoring session, for example. But first, we have to finish off the kata described above; it has a nice second part and an even cooler learning outcome (I’ll post it later). I hope I will not be the only one to propose exercises.
So that’s it for now, I’ll be back with updates soon.