getting agile via meetings

There was an 1-hour agile presentation I attended some time ago. I asked one of the other attendees for comments. She said: ‘the whole presentation was saying “communication is good“. Do we really need a hour to elaborate it?’. I don’t know answer but I like her punchline: ‘agile is about communication’.

So what do we do to facilitate ‘communication’? Well… we set up meetings. Meetings. Some more meetings. And more. Now we feel more agile.

Adding meetings to the process does not make the team agile. Remember the manifesto? Individuals & interactions over processes & tools.

Meetings don’t add value. Meetings are useful, sometimes extremaly necessary. Nevertheless they don’t add value. They are your coordination cost. What adds value, then? Coding a feature adds value… so long you code the right thing. Information discovery (aka testing) adds value. Meetings not.

The book is out!

Toni, Felix and the gang invited me to contribute to the brand new book. The Practices of the Proper Christian Programmer will be available on Amazon shortly!

Sweetest

In a constant battle for sweet tests (readable & maintainable) I developed another weapon. Have a look at this tool for acceptance testing: Sweetest. What do you think?

Hudson is a cunning beast

Build failed today:

ERROR: Failed to update http://svn.dev.sabre.com/svn/apd_centiva2/trunk
org.tmatesoft.svn.core.SVNException: svn: blah blah blah

‘Bummer, I need to log in to the ci box and figure out what’s wrong with svn.’ – I thought. Being in the middle of something I didn’t get to it immediately. Then I got another notification from Hudson:


Updated failed due to local files. Getting a fresh workspace
...
Finished: SUCCESS

Apparently, hudson figured out that there’s been an issue with svn update so during the next build he simply did a full checkout. It worked just fine. I do like Hudson.

Guerrilla Developers

Not sure I like the punchline but the story is real.

Once upon a time there was a project, pretty bad one actually. The were big performance and stability issues. The were no docs about functionality whatsoever. The code base quality was disastrous. There was even a local framework implemented that dealt with mapping java classes and fields into database tables via annotations (hmmm… this kind of framework does sound familiar…)

Several smart developers where thrown into this project. Officially, they didn’t have time for technology upgrades because new clients were waiting for this software. Developers couldn’t deal with the crap they ended up with. They started guerrilla development. All the efforts occurred under the radar: refactoring, automated testing, improving migration scripts, performance & debugging capabilities. They were stealing work hours, cheating on estimates, doing 2AM check-ins, staying late at work, etc.

After ~1 year of guerrilla development developers finally sorted out the project. Cost of introducing new features was reduced substantially, migrating new clients was blind fast, there were very little bugs, fixing & patching the production system was quick & easy.

Higher management was very happy with the quality of the product. The project was doing well and apparently it didn’t need so many developers to maintain it. So they rewarded developers… by transferring them into even worse project. The project was bigger, uglier and had large number of existing team members that stopped caring long time ago. Half year passed and there is no sign of improvement. Guerrilla developers are pretty much disillusioned because there is no groove in the team for sneaky improvements plus they still remember the reward after fixing similar project last time…

//given //when //then forever

@Test
public void shouldDoSomethingCool() throws Exception {
    //given
	 
    //when
 
    //then

}

I like to call it the Ultimate Test Template. I’m so fond of those 3 little comments but surprisingly, I didn’t buy it at first. Micheal (it’s you, tapestry-maven-iPhone fan boy =), friend from ThoughtWorks showed me it a couple of years ago. Actually, he didn’t show it to me – I just overheard him coaching a young dev about it. That day I thought I didn’t need any hip comments because my tests were great anyway. It was foolish.

Don’t be a fool like me and start writing //given //when //then today. Life is too short for messing around – you want to get level 85 in software craftsmanship soon, right? Here’s the deal: use the template for 1 iteration and if you don’t like the results then I will give you your money back. Seriously, no matter what you think about it – buy it! BTW. If you need to document some ‘exceptional’ behavior in your test somewhere there is the template for tests with exceptions.

Lately, I’ve been selling //given //when //then quite relentlessly. I even try to sell it via Mockito api. (The link also shows how to install the template in Eclipse so don’t miss it!)

I tried to lobby for the Church of given-when-then in Krakow, Warsaw & Kiev. I heard rumors that Wroclaw develops a growing number of brothers and sisters in faith =)

I think I forgot to thank Dan North for given-when-then and Liz Keogh for the idea of BDD aliases in Mockito. There you go!

TDD unlimited

So I read a short rant that questions TDD (or unit testing – it’s hard to figure). Here’s my message:

If you want to learn your trade don’t get too excited about gurus that outsmarted the Universe and found cracks in TDD. There are way more IT celebrities that successfully practice TDD. They blog about, they teach and you know what? Their code kicks ass big time. So… Write loads of tests, try TDD, taste BDD. Learn it yourself and at some point you won’t be needing blogs to decide what side to take (Alliance or the Horde? =).

Now, if you already know your trade please try to influence others to write more tests and learn TDD. How much inspirational is this or that! Anyway, it’s just my humble request to the world. Of course, you can write whatever you want, dear influential blogger!

hgsubversion on windows

Who likes mercurial? I do. Lately, I even started using mercurial as a client for subversion repositories. Let me describe the hgsubversion installation steps that worked for me; on my laptop that is boldly supplied with The Only Right operation system…

I heavily borrow from excellent entry by Ben Collins-Sussman and from outrageously diligent post by Dave Cameron. I want to focus on the smallest possible installation routine on windows. Also, I want to emphasize that you don’t have to build anything on windows. All the prepackaged installables or binaries are ready, waiting for you to grab them.

Oh right, here are the steps that worked for me:

1. Install mercurial (TortoiseHg)
2. Clone hgsubversion
3. Configure hgsubversion extension
4. Start cloning svn repos!
5. Understand the gotchas
6. Stay happy

1. Install mercurial (TortoiseHg). I installed TortoiseHg (mercurial + tortoise). Your cmd should nicely take: hg version.

In theory you can install different Mercurial client. However, there is a huge advantage of installing TortoiseHg: you don’t have to install python, svn python bindings & make your Mercurial use it. All because TortoiseHg comes with python+svn bindings (thanks Afriza for a hint!).

2. Clone hgsubversion:

hg clone http://bitbucket.org/durin42/hgsubversion SomeFantasticFolder

In my case SomeFantasticFolder is c:\projects\open-source\hgsubversion. At the moment I cloned hgsubversion the tip was the changeset 500.

3. Configure hgsubversion extension. Add extensions to your USER_HOME/.hgrc, which on windows is Documents and Settings\SomeFabulousName. In my case SomeFabulousName is sg0897xxx (after years in IT industry I’m still just a number…). Note that hgsubversion is duplicated at the end – that’s fine. Your .hgrc should contain something like:

[extensions]
rebase=
#do not quote the path if it has spaces!
svn=c:\projects\open-source\hgsubversion\hgsubversion

Your cmd should print enabled extensions at the bottom of the screen when you do: hg help extensions

4. Start cloning svn repos!

Instead of cloning repos with “hg clone” I suggest to “hg pull” instead. Pull is better because it can continue in case something breaks (cloning very large repo can takes hours).

hg init example
cd example
hg pull http://example-for-hgsubversion.googlecode.com/svn example-for-hgsubversion

5. Understand the gotchas.

• gotcha 1. If svn requires authentication, you may be asked to enter user/password… 3 times. Don’t worry, just enter correct credentials patiently. Three shall be the number thou shalt count, and the number of the counting shall be three. (update) Augie Fackler, the mastermind of hgsubversion points out svn+http or svn+https can be used to work around this gotcha
• gotcha 2: After updating changes from svn (hg pull, hg update) never use ‘hg merge’, instead use ‘hg rebase’. Merges are not yet supported by hgsubversion I heard. If you accidentally do hg merge you probably have to rollback the merge in order to push.
• gotcha 3: (new) From my experience it is better to clone entire repo, not only trunk. Cloning trunk worked for me but I noticed exceptions thrown during unsuccessful rebase. Working with full repo clone was smooth for me so far.
• gotcha 4: (new) Commands you should know:

  hg help svn
  hg rebase --svn
  hg svn info
  hg svn rebuildmeta
  

• last gotcha: I’m not a mercurial expert so feel free to comment & give feedback. Also, newer (different) versions of before mentioned installables should work as well. If links to binaries are dead then get creative and google for it – I don’t guarantee all links will work forever.

6. Stay happy. Are you kidding me? You know what to do =)

remote retrospectives

Ideally, I don’t like doing retrospectives remotely but many times I just have to. I live in the era of distributed teams. If this is not enough, there are usually more prosaic reasons: people working from home, lack of decent conference room, etc.

Many times I have to help with remote retros where people dial in from their desks, homes and remote offices. They don’t see each other, they only listen to each other. And there’s a gotcha.

The quality of the retrospective depends a lot on communication. We know that large percentage of communication is contributed by… non verbal stuff (was it 70%? or 80%? Look it up yourself =). You can add problems with quality of phone lines, latency, etc. This practically means remote retros are pretty much a challenge. Let me share a couple hints on dealing with remote retrospectives. I’m going to focus mostly on tools and I would really appreciate if you point me to some even better tooling.

1. MS Office communicator and its shared white board. By the Big ‘M’ company that rules the world (Hopefully, I didn’t offend the Big ‘G’). The communicator is an example of non web-based tool for shared meetings. We started using it instead of twiddla (see #2). The communicator has fairly nice shared white board. The only downsides I encountered so far are:

• occasionally someone cannot take part in a shared session.

Successful retrospective with MS IM might look like:

End of remote retro with MS communicator

I’m sure there are other peer-to-peer shared white board tools. Let me know if find something interesting.

2. Twiddla is an example of web-based, multi-user, shared white board. We actually tried it for several retrospectives with various success rate. The problems we encountered:

• too many features, some of them deadly enough to remove everything from the screen
• voting on items to discuss was somehow difficult
• we had some minor usability problems and once we couldn’t set up a meeting for unknown reason

We had successful retrospectives with twiddla, for example:

End of remote retro with twiddla

You might want to try out twiddla or look for similar tools out there. There are bunch of web-based tools to facilitate shared meetings, shared sticky notes, shared white board etc.

There is one great benefit of using tools like #1 or #2 for shared meetings. It really does not matter if you use a web-based tool like twiddla or just an instant messenger with shared white board like MS communicator. Doing shared meeting with any of those tools allows unsure team members to speak up: they can participate almost anonymously by sticking items on the shared white board. Certain level of anonymousness increases the chance unsure/diffident team members actually participate.

3. Emails. That’s basically my plan B for remote retros. (Although my favorite plan B is forcing plan A). There are number of ways of doing the remote retro with emails. For example, I can ask everyone to spend the next 5 minutes on thinking of three :)’s and three :(‘s and send me via email. Then I say what are the items most people wrote about and we discuss it. I don’t waste time on sharing the contents of the emails. This gives me a unique chance of steering the retro a little bit. If I feel that there’s an item only few people wrote about but I think it is really important… I can lie just a little bit =)

One other thing I find useful is that sometimes it’s better not to discuss most voted items. Let’s say 70% of retro’s participants are developers based in the same location. There’s a big chance they have similar problems and those problems are technical. In that case, most votes might go to technical problems related to the very same group of the team. I don’t like it… Many times I even skip technical problems during the retro so that we don’t waste customer’s time talking about issues with build. (or am I just too tired of talking about maven?).

***

Finally, I wish your team develop a habit of continuous improvement so that you don’t need a lot of ceremonial retrospectives to get better. Improve daily but if you don’t know how then by all means do retrospectives regularly.

Mockito in Zurich

I will have a pleasure presenting Mockito at Jazoon in Zurich. My session is on Thursday – make sure you don’t miss it. During the session I’m going to show few slides and do live TDD with Mockito & other mocking frameworks. I’m going to use Infinitest. Guys, it’s huge. Brett Schuchert wrote about it, Bartek told me to try it several times. Finally I did and I must say I’m impressed. Infinitest is like transcending to a real TDD.