Boy Scout Rule in practice

I've started doing Scrum in late 2008 (thanks to Piotr Burdyło). And though I've immediately seen benefits of practices like daily standups, sprint planning, reviews and retrospectives, I had a big problem with finding out how to deal with refactoring within this method.

Before Scrum, whenever I found a place in code that I thought should be done better, I'd put a TODO comment. I would return to these comments whenever I saved some time on what I was doing, or when I decided that it has already been too ugly for my standards. And since my standards are pretty tight, I've been  (and making others) refactoring quite often and it worked well for me.

When doing code review, I'd write TODOs, discuss them with the authors of the code, and make them do clean up as the top priority.

But what were my options in Scrum?

1. Don't tell anybody, and just use your left over time to clean up the TODOs

This is against transparency, which Scrum is advocating, and against my moral backbone (no lying). And since you are evaluating tasks/features better and better, sooner or later you'll have no left over time for TODOs anyway. Ergo: this won't do.

2. Create additional tasks/features for refactoring

These are not visible from the product owner point of view, so some Scrum Masters are strongly pushing against them.

Ok, so I had to choose the second option, and make my Scrum Master live with it. But then, another problem emerged: unless you put a cleaning task for every class that has TODOs inside, sooner or later you'll end up with tasks like “Do all the TODOs in my Big-Ugly-Module”.

This will happen because doing TODOs may have very low priority, because people in a hurry don't bother doing them, and because some people don't write TODOs at all, rather thinking: “yeah, this is ugly, lets fix it, when we fix the rest of the module”.

So it seams that your code is predestined to go down the great spiral of (bio)degradation, until your team can't stand it anymore and somebody asks for a Scrum task to clean up the mess.

Is there a solution to this? Is there a third way?

Sure there is.

What if we can switch the direction the code quality goes in? What if our code can get better with time, instead of getting worse? That would be cool and it would solve our problem with TODOs in Scrum.



Boy Scout Rule

Leave every code you read in better shape than you found it.

Ha! That sounds like something everyone would sign under, and completely forget about a few minutes later, right? I mean, phrases like this sure look nice, but the real battlefield, the front-line, is a mean and messy place, right? You sit in your trench, trying to survive and keep the project alive, while bullets fly above your head. How can you try to make things better, when you couldn't keep them clean in the first place? No way to do it, man, there is too little time, right?

Wrong.

Let me show you how to use this rule in practice, without any significant time burden.


Real case scenario

You are in the middle of writing an application, you take a task from the Scrum white-board. It's a new feature. It says: “When importing orders, every shipping address should be verified. If it's not in our shippable zone, it should be canceled (status change + send an email to the frontend application)”.

Ok, so you want to write a new acceptance test, for this feature. But first you need to know what to test, which part of the application is responsible for importing orders. You search the project structure, and you spot the OrderService interface. You nose tells you, that it should be somewhere there. You take a look.

public interface OrderService {
    /**
     * Imports orders.
     */

    public void importOrders();
    /**
     * Export orders.
     */
    public void exportOrders(DateTime date);

    /**
     * Create raport of placed orders
     */
    public OrderRaport createRaport(DateTime date);
}

Yeah, it's there. The importOrders() method. You search for implementations, and as you expect, there is an OrderServiceImpl.

WTF is with this blur, you ask. It's intentional. It's how much you see during your first second of looking at the code. At the first second you, as a good writer, have already noticed two things:

1. The method has 30 lines. It's probably too long. Good method should be as short as possible. This, according to Robert C. Martin, means between 1 and 7 lines.


2. The are several different BLOCKS of code.

What does the second thing mean? It means, that the author has noticed the first thing as well, so he decomposed the method into different blocks, by putting an empty line between them.

This is so natural, so popular, nobody thinks about it anymore. We put empty lines between different blocks of code, to help us read the code. When we read the code, we can skip such blocks, because we already know, what those blocks do.

We put together similar stuff, so we can put a name into our mind-map, that given block does something. Next, we can fast read and skip it consequently.

There are two big problems with such method:

1. it requires you to read all the details (every line) of the code at least once, before you put names of those blocks in you mind


2. it is not the way Object Oriented Programming is supposed to separate stuff that make a single concept

So how about fixing it, while we read it? We have to read and understand it anyway. How about not keeping the names of blocks in our memory, but putting them into the code instead.


Comment every block of code

You are doing it anyway, but instead of saving the names/explanations in your head, save them in the code for a moment.

So our code will look like this:

@Override
public void importOrders() {
//create date before importing from web service
    DateTime date = new DateTime();

//import data transfer objects from web service
    List<SalesOrderExportDetail> orders = salesOrderWS.getSalesOrdersFromWebService();

//create summary for importing orders
    SalesOrderImport salesImport = new SalesOrderImport();

//for each order try
    for(SalesOrderExportDetail salesOrder : orders) {
        try {

//convert it to domain object
            Order order = new Order();
            order.setValue(new BigDecimal(salesOrder.getValue(), new MathContext(2, RoundingMode.HALF_EVEN)));
            order.setAddress(convertToAddress(salesOrder.getShippingAddress()));
            order.setBuyerAddress(convertToAddress(salesOrder.getBuyerAddress()));

//calculate vat
            double vat = calculator.vatRate(order.getAddress());
            order.setVatRate(vat);
            BigDecimal value = calculator.value(vat);
            order.setVatValue(value);

//calculate value in PLN
            Currency curr = order.getCurrency();
            if(curr != Currencies.PLN) {
                order.setPln(converter.convert(curr, order.getValue()));
            }

//save in repository
            orderRepository.save(order);

//prepare information whether it was succesfull                
            salesImport.imported(order);
        } catch(Exception e) {
            salesImport.notImported(e);
        }
    }

//save the summary for importing orders
    salesImport.setDate(date);
    orderRepository.save(salesImport);
}

Put the comments without any indentation, so that you won't forget to get rid of them, and they won't mix with other comments in the code. Make those comments verbose, make them say everything that is important on this level of abstraction. You are a programmer, you probably write faster than you think, so there was no additional time spend on this action.
Now for the second step.


Eliminate blocks of code using explicit names

The goal is to compress all the information from inside the block and the comment into one-liner. That saves the time the reader needs to get the meaning of the code next time. It usually means, replacing the block with a method, with a name created from the comment. So for example this:

//calculate vat
    double vat = calculator.vatRate(order.getAddress());
    order.setVatRate(vat);
    BigDecimal value = calculator.value(vat);
    order.setVatValue(vat);

will be replaced by this:

order.calculateVat();

Who said that the new method has to be in the same class? In this situation, it makes much more sense to put the use of the calculator into the order, after all it has all the data (we are using aspectj load time weaving to get the calculator into the order, but there are plenty of other methods if you don't want to use aspectj).

And this:

order.calculateVat();
//convert it to domain object
    Order order = new Order();
    order.setValue(new BigDecimal(salesOrder.getValue(), new MathContext(2, RoundingMode.HALF_EVEN)));
    order.setAddress(convertToAddress(salesOrder.getShippingAddress()));
    order.setBuyerAddress(convertToAddress(salesOrder.getBuyerAddress())); 

Will be replaced by this:

Order order = orderConverter.toOrder(salesOrderDto);

Here we have decided to put the body inside a new class: OrderConverter, because the convertion is a serious responsibility and the OrderService look like it's got other things to do already (Single Responsibility Principle).

Even one-liner can be a bit fixed, for example in this part:

//create date before importing from web service
    DateTime date = new DateTime();

The comment is put, because the name of the variable does not communicate it's intention. We can get rid of the comment if we give the necessary information to the reader in other way. For example like this:

DateTime dateImportStartedAt = new DateTime();

We should eliminate every block and split every part of the code that serves a different need. Even for-each loops and try-catch expressions. For-each responsibility is to iterate over a collection, and call someone else to do the job on an element. Try-catch is responsible for handling an error, so somebody else should do the unsafe job for it.

This is the Single Responsibility Principle on a method level. Make every method have only one reason to change, and your life (and the readability of your code) will be better.

Since these are very basic and easy refactoring steps, that your IDE does automatically with little effort from you, the time burden is insignificant. You had to understand the class anyway, and on the way, you've made it better, easier to understand. Now the part of your class responsible for imports looks like this:

@Override
public void importOrders() {
    DateTime dateImportStartedAt = new DateTime();
    List<SalesOrderDto> salesOrderDtos = salesOrderWebServiceClient.getSinceLastVisitOrderedByNumber();
    ImportSummary importSummary = tryToImportEach(salesOrderDtos, dateImportStartedAt);
    orderRepository.save(importSummary);
}

private ImportSummary tryToImportEach(List<SalesOrderDto> salesOrderDtos, DateTime dateImportStartedAt) {
    ImportSummary importSummary = new ImportSummary(dateImportStartedAt);
    for(SalesOrderDto salesOrderDto : salesOrderDtos) {
        importSummary.add(tryToImport(salesOrderDto));
    }
    return importSummary;
}

private OrderImportOutcome tryToImport(SalesOrderDto salesOrderDto) {
    OrderImportOutcome orderImportOutcome = null;
    try {
        orderImportOutcome = importOne(salesOrderDto);
    } catch(Exception e) {
        orderImportOutcome = new OrderImportFailure(e);
    }
    return orderImportOutcome;
}

private OrderImportSuccess importOne(SalesOrderDto salesOrderDto) {
    Order order = orderConverter.toOrder(salesOrderDto);
    order.calculateVat();
    order.updatePlnValueIfNeeded();
    orderRepository.save(order);
    return new OrderImportSuccess(order);
}

Every method has a meaningful name. No more than 7 lines of code per method. You don't need to divide code into blocks, methods are an object oriented solution to divide the code. By the way, you've delegated some responsibilities to other classes. You've refined the code, made it more precise, more clear, more readable.

But somewhere in your head there is a voice saying: “Hey, I had just one, 30-lines method, now I have four, taking the same space. If I do it to other methods, I'm gonna have like 15 methods per class. I'll get lost, it's no way easier for me”.

But that is, because you have one more big mistake to fix.


The name is the responsibility

Have a look at the name of the interface: OrderService. Can you tell me what this class is responsible for? Every class should have just one responsibility, what is it for OrderService?

Everything about orders?

What kind of responsibility is “everything”? There is no such thing as “everything”? Thinking this way you can create single class named God-Emperor and end your OOP right there. You'll never need other classes anymore.

No, my friend. The name SomethingService is a great mistake, just like a SomethingController or SomethingManager. I know quite a few SomethingManagers in real life, that you wouldn't be able to find any responsibilities for. They are called that way, because this is what they do: NOTHING. They just are.

But we do not speak corporation-bullshit (even though some of us work at corporations), we are Agile developers, we are writers, we name things as they are.

So our OrderService interface should be split into, let's say: OrdersImporter, OrdersExporter and OrdersReportFactory. That would make responsibilities and our intentions clear. If you do that, you end up with a WebServiceOrdersImporter implementation class, that has only 30 lines, 4 methods, only one of them public.

Now that's simple, isn't it?


Conclusion

It doesn't have to be expansive or difficult to make code better while you are reading it.

You shouldn't wait for the code to get really ugly. You shouldn't write TODOs only for obvious problems. Every time you have to read and understand some code, ask yourself a question: Can I make it easier? Can I make it more readable? Can I make it better?

Take at least a small step, every time you answer is yes. Good is better than good-enough. This helps turn the tide, change the (bio)degradation into positive evolution. In the end, your code gets better with time.

No one writes good code right from the start. Good code evolves from normal code, by using the Boy Scout Rule.

And if you cannot find any way to make the code better, at least eliminate blocks of code with methods. Stick to "7 lines per method", and "Single Responsibility of a method" rules.

Writer versus Constructor

What's the favorite toy from your childhood? For me, both my sisters and pretty much everyone I know that would be Lego. If you could only afford it (and in the times when I was a kid, that wasn't so easy in the post-soviet Poland), there was no greater fun, than the joy of unlimited freedom to create whatever you can only imagine. And the fact, that you had limited resources wasn't a real obstacle. It was a challenge.

Nearly all the programmers I know, fell in love with programming because of the same reason. To be able to put pure ideas to life, to create something meaningful out of nothing. Truth is, no other matter is so flexible, as the stuff we work with.

We are developers because we love to construct things that work. To give soul to the machine. To make it act on our behalf. It's like magic.

That's why it is so difficult for us to understand, that a real software craftsman is a writer, not a constructor.

Uncle Bob is talking about it at the beginning of “Clean Code”. When you are writing code, you are actually reading a lot more. How is that possible? Let's have a look at an example: you have a project going, and you take a new feature from the Scrum/Kanban wall of features. And you:

1. read the code to find a place where putting some more code will give you the result you seek
2. read the code to better understand the surroundings, to eliminate potential side effects of your changes
3. write the test and the code that does what the feature is expected to do

You can start with an acceptance test first, but that only changes the order, not the fact, that the proportions of reading to writing, are always in favor of reading. Big time.

So, if reading takes so much time, how important is to make things readable?

People are working hard to learn how to write faster, how not to use mouse in their IDE, they memorize all the keyboard shortcuts, use templates and so on, but the speed up is not significant in real work. Why? Because we are only writing code 1/10 of our time. The rest is spent on reading and thinking.

A good craftsman is a good writer, because he makes the code readable, easy to grasp, easy to understand. There is a huge shift in mentality, between a constructor and a writer. Above all, the constructor's goal is to make things work. The writer's goal, on the other hand, is to make things easy to understand.

The question is, who are we writing code for? The computer? Hell no. If that was true, we would be still writing in an assembly language (or maybe even in a machine code). The whole point of procedural, functional, object oriented languages was to make it easier for us to understand the code. And that's because we don't write the code for the computer.

We write it for other programmers.

To make the shift in mentality easier, let mi show you the differences in mindsets, between the constructor and the writer.

The Constructor

The constructor is in love with technology for the sake of technology. He likes to “technologically masturbate” himself with new toys. He thinks that simplicity is for pussies, the real thing is always complex. He never removes anything, always adds more. He doesn't care that he cannot understand how his earlier solutions work, if they work why would he want to change them? He creates monsters like EJB1/2, that can do pretty much everything, but nobody is able to handle them. The he writes software to be able to use/confgure the software he has written before, because it's already too complex for anybody (maybe except for him) to understand how to use it directly.

A bigger framework is a solution to his every problem. And even if it's a new problem, he tries to modify his beloved one-to-rule-them-all tool, to be able to solve it. He is dreaming about the day, that he will have a single, big, multipurpose, futuristic wrench that works as if by magic, and does everything, from printing log files to saving the planet.

The constructor works best alone. He gets angry at people that cannot understand his programs in a second. When he works with other programmers, he is always afraid, he doesn't like others to play with his tools. When they try to do pretty much anything, they always blow something else up. Because of unforeseen side effects, a small change can devastate days of work. And it happens a lot. It gets messy, so he hates to work with others.

The Writer

The writer reads a lot, so he wants to make his code as readable, as simple as possible. He learns stuff like DSLs, patterns, eXtreme Programming, to make things easy. Easy is his keyword. He cares less about frameworks. He usually knows a few languages from different worlds, because he believes there is no single silver bullet, and different solutions are better for different problems. His code has few comments, because it doesn't need them. His code is self-documenting. His code is expressive. His code is simple, simplicity is his main value. Brilliant things are simple.

The writer always thinks about his reader. He walks hand to hand with his readers. He guides them, he cares for them. He never leaves them in the dark. His skills are in communication: he wants his intentions to be understood.

The writer works like a sniper. His changes (whether bug fixes or new features) are minimal, but the effects are exactly as expected. He never does Shotgun Surgery. He doesn't violate DRY. He is a precise man and he works with a scalpel. His code is side-effect free, simple and readable, so he knows where and how to hit. He knows what the effects will be. He keeps accidental complexity low.

The writer is agile. He doesn't set up traps, and he doesn't fall into traps. He works hard to master basic skills. He believes that without those basic skills, no framework can save him anyway.

The writer likes to work with other programmers. He is using pair programming and code reviews to make sure that his code is easy to understand by others. He wants to have another mind watching his back, and catching him when he falls. He is supportive, he is friendly. He understands that no man is an island, and that the quality of his work will be measured by the number of WTFs shouted by other developers.

A good craftsman is a good writer.

And you know what one of the most successful writers of recent times, Stephen King, says?
That he's only a craftsman.

PS: all the pictures are from Fallout games.
PS2: I've failed at giving appropriate credits to the author of the concept of programmer as a constructor. Let me fix that right away: the source of the idea that a programmer as a writer has opposition in programmer-constructor comes from a post by Andrzej Szczodrak that you can find in here

How fast is TDD exactly?

This is a true story, but for the sake of protecting some people, all the names and other details have been skipped or changed.

It starts on some Thursday with some new guy asking me “how much TDD is slowing down the programmer”? I don't have to think twice, my instant answer is: “programming with TDD is faster than programming without”. The guy doesn't believe me, some other SQL guy joins, doubting as well. I see no point in explaining it to people who don't touch OO code. They won't believe anyway, as it is counter-intuitive, if you have not experienced it yourself. But then, life has a funny way of giving you proofs right when you need them.

Next day I'm being asked to help put out some fire. There was a project running, two junior programmers were writing a small application, one of them doing the frontend, one doing the backend. No help from any senior or architect along the way. No code reviews, no pair programming, no nothing. Things, as expected, went terribly wrong, deadlines are weeks behind, the client is furious, and the software is not doing the stuff it's supposed to. Oh, and the backend programmer is already on the way to another continent. Some guys tried to debug the problem, but after six hours of getting nowhere, they gave up. A classic FUBAR example.

All right, I say. I know the frontend programmer, he's a good guy, I like doing pair programming with him. He doesn't know much about the other guy's code, but he knows the business domain. I'll help as much as I can. So we checks out the code, we setup the IDE and look inside the backend.

And the abbys looks back into us.

We stare into the Eye of Terror. A complete chaos, infested with chaos spawns. A terrible place to look at. Things can break your mind in here. It's twisted, it's evil and it's tragic. Pretty much every principle of OOP is violated. I could give it as an example of things that should not be, except I'd hurt the audience. There are no tests, there is a lot of faulty inheritance, with abstracts knowing about the children, there are hundreds of 'ifs', 'elses' and even some 'case-switches'. Hell, there are even misleading comments! There is a 'new' keyword in every constructor, no IoC, no interfaces, no nothing. No sane mind can leave this place intact.

We take a deep breath, and we try to find out where the problem might exactly be, but as we dig into this Big Ball of Mud, we realize that the problem we are facing is just a tip of an iceberg. The software does not guarantee anything, and as far as we can tell, there is a shitload of bugs all around the place. The main algorithm is so twisted that it takes us hours to understand it, while the purpose of the whole thing is dead simple.

Ok, so we've nailed down the possible problem. I'm suggesting writing a test to repeat the bug client had reported, and then fixing it, but the problem is, that the code, the way it is now, can only be tested end-to-end, so we have a lot of setup to do. My fellow programmer's mind is already burned out, he asks me to call it a day. He also says, that he'd rather rewrite the whole module instead of digging any further, because if he has to look again into this mess, he will never be normal again.

All right. I'm a bit more resistant, but I've not exhausted myself with debugging it before, and I've seen things, you people “wouldn't want to believe”.

So we set up an emergency pair programming session on Saturday. Now it's late Friday, and I'm heading for two parties I've planned to visit that night.

Saturday, 1pm. Sun is shining, weather is beautiful, girls are dancing in the middle of the town. I'm heading for the meeting. I'm expecting some heavy code crunching today, killing chaos monsters and stuff, but when I get there, the other guy says he couldn't sleep. Knowing the main purpose and the twisted algorithms, he has been working till 4am, writing everything from the scratch. Maybe not everything, but the main stuff anyway. He's been doing TDD, and though he has lost some benefits of discovering optimal interfaces/architecture, because he's been writing interface-first, then Red-Green-Refactor style, he got it quite well.

The code is doing about 80% of what it's supposed to do, test coverage is sky-high  (except for DTOs), there are some minor issues with ubiquitous language and so on, but for a single person junior programming this is a pretty sweet piece of code.

“Great job” I say, amazed by his late-night work. What should we do now?

So I help him write an acceptance test. We make it run all clean and green. We talk about the decisions he has made, I'm giving him advices and suggestions, but I can clearly see, that the guy has defeated an ugly dragon last night. He took his TDD spear, stormed the whole army of enemy warriors, killed them all and now he's on his way for the princess. Well done man, If I had a medal with me, I'd give it to you right now. You deserve a big thanks from all of the humanity for putting the beast down.

And he's saying, that if he ever had doubts about TDD, he doesn't have any now. He has really learned something that night, he gained a lot of experience points, and he has leveled up at least two times.

There is still some work to be done, but it's easy from now on. The client is safe and sound.

And now for the conclusion: it took him LESS time to rewrite the whole module, using TDD, that it took, to find one bug in the old application.

How's that for an answer?

PS: pictures are from www.studiocombo.pl

Mentoring in Software Craftsmanship

Maria Diaconu and  Alexandru Bolboaca are both strong supporters of Software Craftsmanship and Agile movements in Romania, with years of experience as developers, leaders, architects, managers and instructors. On their lecture at Agile Central Europe Conference they were talking about Software  Craftsmanship movement. While Sobótka at 4Developers was showing what Craftsmanship from the code point of view is, our guests from Romania gave us a brief introduction into the process of becoming a Craftsman.

The fact, that university education for programmers doesn't give us skills suitable for professional environment is old news (at least in Poland and Romania). While steps are being taken in the right direction, it's going to take a while to get there, and that's where  Software Craftsmanship movement comes in handy.

The core concept of the presentation, was that if you want to go pro, you should understand the way you need to follow. In other crafts, there are practices recognized as the core of a profession. Programming is so vast, that you may get lost on the way, and certifications like SCP do not help much, as they are too technology oriented, looking more like a “technological masturbation” (technology for itself) rather than a way to really learn something useful. Software craftsmanship has a concept of mentoring, which is based on one of Agile  principles: “individuals and interactions over processes and tools”.

How does it work in practice? To become a craftsman you start as an apprentice at some master of your choice. If you're lucky, you'll find someone to work for and learn from. If not (you have to work in a bad environment to get by, or everyone around doesn't have more experience than you do), you can choose a well known writer, such as Martin Fowler or Robert C. Marting (Clean Code is a great start) and learn from him (all of them, even better). But that's not enough. Next step would be to participate in the community (local language user groups, etc.) and finally, to get your ass to other places and learn from people out there. That means conferences, but also a week-out pair programming in another company, far, far away, an idea more and more popular in US, as you can see at software_craftsmanship google group. After all a journeyman has a “journey” part in it, doesn't it?

So easy so far, right? Nothing new and mind-shaking?

The thing is to understand, that while official certifications are a great magnet for potential employers, skills of a good programmer don't come from certification books. Skills come from work experience with other good programmers. That's why Pair Programming is so important. That's why you should start going for local language/craftsmanship group meetings even if you do not understand everything they are talking about. That's why it's more important to work WITH a great programmer than to work FOR a well known company.

I've seen so many people understating the technology to the ground, yet failing to create a good software solution,  because they've never ever seen, how a good solution is build. I've heard opinions that “no software is maintainable” from people with 10+ years of experience in Java.

All you really need is a mentor. A master, that can show you, what a great software is written like.

Sławomir Sobótka, answering the question “How to start with Java” on Jacek Laskowski's blog, wrote lately: “I'd leave SCJP and similar sadomasochisms for later, maybe in a few years time, or even better, I'd boycott it all together”. He is damn right.

Robert C. Martin has a very interesting entry on his blog “Developer Certification WTF?”, where he is explaining why  official certification programs are so much bullshit these days. Beware of big companies as well, remember that “big and successful company” doesn't mean “a good place to get better”. On the contrary, it sometimes means: “a place where an apprentice is treated like shit and a code monkey”. Check the company for people and methods that you're going to be involved with on daily basis, before you send your CV. Ask a lot of questions, talk to the guys working there, if you can, ask to spend some time with the team, do some pair programming, and see what they are up to.

While chances are, in most companies your CV is going to be processed forward basing on buzzwords and certificates, the most important thing is to check whether the people you are going to work with can inspire you, bring you to the next level. And vice-versa. This is exactly what Thoughtworks is doing. Don't be afraid to risk you stability and position to get more knowledge and experience. If you've been playing Heroes of Might and Magic, you probably know damn well, that to choose experience is better than to choose money in the long run. Always.

If you want more tips what to look for when searching for a good employer, have a look here.

Mentoring should not to be underestimated. When Piotr Jagielski began his speech about refactoring test code, at Agile Central Europe Conference, he started with saying that he was very lucky to get a great mentor at the very beginning of his work. I'm sharing similar experience: while I've started my carrier as an analyst in a long waterfallish kind of a project, when I've moved into programming I was extremely lucky to work with Piotr Szarwas, the guy who in one year taught me more than 5 years of university and two years of former software experience all together.

And if you already are a good programmer, remember that learning never stops. When you are a master, you are a student as well.

“Even today, I dare not say that I have reached a state of achievement. I'm still learning, for learning is boundless.“ [Bruce Lee, Tao of Jeet Kune Do]

ACE Conference: Reachel Davies – Retrospectives

Reachel Davies, author of “Agile Coaching”, with ten years of experience in XP, Scrum and Agile (seven on the board of directors of the Agile Alliance), and 19 overall in IT, is a serious girl in this industry. Funny, I'd think she has some psychology background, but no, she's an engineer to the core. I'd think that because her presentation made so many points on the psychological part of our line of work, that my sister (who is a psychologist as well as a jazz singer) may be interested.

Her talk was about the underestimated art of retrospectives in our agile methods. Teams tend to forget about it or do it a wrong way, while it's the main thing that can help them get better.

She suggested another technique for retrospectives, to create a constant time-line where the team would put their sticky notes, writing:

• what happened
• what was frustrating / stressful
• what was useful / fun

That can give you a very interesting insight in what was happening during the project. She also pointed out that people's moods take a big part in the efficiency of the team, and to have a valid historical view, you should include them as well (like biorhythms). To get that, anything would be good, from putting your spirit level on a scale, up to drawing a picture. Back to kindergarten anyone?.

That may seem silly, but the team is the most important part of the project, and as such, we need to pay attention to everything that happens within. For example, while voting on things to change during a retrospective can help, we should beware of serious disagreements. There are things, like personal values, that you cannot change with a simple statement, and there are things (personal values again for example) for which people would rather be fired than give up on.

That was pretty familiar to me, as I cannot agree to include chaos and lose quality for the sake of other things. And don't talk to me about quality versus work performance dilemma. It's a myth. You'll never be faster by writing uglier. In the long run, bugs and accidental complexity will bring you down big time.

It's quite an interesting twist to think about retrospectives in a more general sense. You can (should?) use them outside of IT as well. About three years ago, I've been to a sailing camp at Mazury where my trainer, who was a youngster, after every not-so-perfect maneuver, would ask: “What went wrong?”.  As simple as it is, the question generated a lot of afterthoughts that helper us pass the exam in the end.

Now, think for a while, what else could also benefit from a well performed, regular retrospective?

A marriage, perhaps?

ACE Conference general impressions

Getting up at 4am is never easy for me, and so it wasn't this time, especially after getting to bed only three hours earlier. Nonetheless, on the 8th of April, thanks to TouK, I was getting myself on a train to Cracow for 2 days long Agile Central Europe Conference, when out of a sudden I saw a man walking out his dog. That made me think: if this guy has so much love for his pet to walk it out in the middle of the night, then I definitely have enough passion for knowledge to stop complaining and be extremely happy that I have a chance to learn something.

And boy, how happy I am that I've been there.

While both 4Developers and Winter Agile Tunning, that I've attended last month, were really great (I can recommend both and I'd like to be there next year), ACE conference was simply fantastic. It seems that it's not only my opinion. Kuba Kurlenda, to whom I gave my free conference pass, that I got (won?) on Winter Agile Tunning for asking Szczepan Feber a hell lot of questions, was also delighted.

There are two organizers mentioned on the site, but as far as I know, it was put together by one man, Paul Klipp, who is a president and Scrum Coach at Lunar Logic Polska, and founder of half a dozen different groups and other undertakings.

So what was so special about this event? Apart from great speakers, that is. First of all, there were only two tracks, but you wouldn't be bored, because as a “bonus third track”, there was an Open Space, where everyone had a chance to put his favorite subject and get some people to talk about it. Breaks between presentations were half an hour long, which was also motivating to get to know each other and start talking. That was what I missed the most on Winter Agile Tunning, a chance to talk with everybody. Finally, Paul was aware that people are getting tired at the end of a day, so instead of putting not-so-hot topics on late hours, he got us the most funny/innovative to wake us up, and after that, we had Lighting Talks, lasting for 5 minutes each, which is precisely as long as you can keep your focus on the subject when you're exhausted.

Big kudos to Paul for all of this. The only two things I'd change were, that we didn't get any pens/notebooks together with conference materials, which is something of a surprise (I wasn't prepared for that and had nothing to note with, except my phone), and that it could've started at noon, so people from other parts of the country would have a bit more time to get there (and to sleep at night).

I had a chance to talk with Paul about it, so chances are, he'll use those ideas next time, as I'm sure there'll be more ACE Conferences in years to come.

So much for the general impressions. I'll have to make one post for presentation, for the sake of readability. Stay tuned.

Tomek's tray notes on Scrum

As Nigel Baker was giving his speach titled "10 tips that ScrumMasters should know, (but probably don't!)" at Winter Agile Tuning, Tomasz Przybysz was taking notes on a paper tray. I've heard the talk was pretty good and a few people were trying to copy his tray. Since the original presentation is not yet available, I thought I'll help with putting my own photo (phone quality) on-line.

Maybe Tomek will take a while to put some insight into his notes? What say you, Tomasz?

Click on the image to get the full (readable) size version.