Agila Sverige 2009

Two days of lightning talks and open space. A great concept inspired by the “Smidig” conference in Norway. On Monday the 8th and Tuesday the 9th, the second annual Agila Sverige conference was held in Stockholm, and I was of course there.

The format

The conference is held during two days, and each day starts with three blocks of 10 minutes long lightning talks. Each block contains several lightning talks and is run in two separate tracks, leaving you with about 30 different talks to choose from per day. Since each talk usually is packed with information, you are quite worn out after half a day. During the afternoon there are no lightning talks, but instead the participants are invited to create there own content for a big open space. Open space is run in three blocks on Monday and two blocks on Tuesday, leaving the last block on Tuesday for a big conference retrospective.

What did i learn?

There where of course a lot of stuff during the conference that I found great, but a lot of the talks did not put anything new on the table. Mattias Persson of Telia Sonera held a talk where he reminded us all that the user is often forgotten in agile methods, something that has been a subject for numerous workshops and tutorials at conferences in the past. However, he ended his talk with a picture of a super hero character called the “Agile User” and stated that it is in fact the user that needs to be agile, and unfortunately the user will in time be enough agile to switch to another product that will give him or her a better user experience. I think Mattias is right. Great way of putting it!

I have heard at several occasions at different clients that “the problem is never the people, but the process”. I am however not so sure that’s the case. I believe that hiring highly competent people for the job is the key. On two different occasions at the conference, once during an open space with Marcus Ahnve of Thoughtworks and once during a talk held by our very own Joakim Ohlrogge of Agical, I heard stated that if you want to make sure that you get to hire competent programmers, don’t use Java or C#, but some obscure language like Erlang or Prolog. Why? Well first of all there are so many really lousy programmers out there, and since half of them know C# and half of them know Java, you are bound to get a few of these applying for a job at your project. There are however not that many Erlang programmers, and the ones that have spent time learning Erlang are usually quite good and/or motivated. Most of them probably know Java and C# as well. This is a very interesting hypothesis. Wonder if it works. I believe you will get your hands on some great programmers this way, but I wonder if these people are the best agile developers?

Erik Lundh held an interesting talk called “Why going Scrum is not (good) enough”, and I attended an open space on the same theme. It was called “F”k Scrum” and was organized by Christian B Hauknes one of the few Norweigans on the conference. He stated that in his experience Scrum has done more harm than good to the agile community. This is because it is so easy to implement, that companies have implemented scrum without actually implementing the real agile values behind it, and since they already have implemented scrum, the managers are not interested in going even more agile. They don’t need to, since they can already tell their customers they are using scrum! This is an interesting point, but as the open space found, it is hard to find the real problem behind this. Is it scrum, or the scrum master certificates, or something else? Would these companies be more open to agile adoption if scrum would not exist? The discussion got very interesting when Henrik Kniberg, author of Scrum and XP from the Trenches showed up. Having certified over 1000 scrum masters himself, Henrik aggread that the title Scrum Master is a problem since it sends a signal that you are done when you are certified. He suggested the title Scrum Beginner instead. But noone would pay the same amount for the title of Scrum Beginner right? That would be bad for business!

Next year

Anyway, I am already looking forward to next years conference. This year the conference had 170 participants (last year about 140). Maybe next year it will be even bigger and hopefully some more PM’s and PO’s will be attending…

“Yes, that is mission- type tactics”

It’s funny how you can learn something new in the place where you least suspect to. This weekend I was at our annual gathering with the family on my fathers side, and I found myself trying to explain what I do for a living. That I am a consultant and specialized in agile methods. I still find it hard to explain agile methods in a nutshell to people not into software at all. The people I was talking to at the moment where my fathers cousins husband who is the head of purchasing at one of Sweden’s biggest grocery corporations, and my fathers aunts husband who is a politician, cantor and major in the Swedish armed forces reserve. How do you explain agile methods to these people? Well I often end up trying to explain how Toyota works, since cars are something everyone can relate to and there’s recently been some radio commercials here in Sweden, explaining some of the processes used by Toyota. I thought I’d lost them somewhere between trying to explain slack and self-organizing teams when one of them, the reservist major, suddenly says: “Yes, yes, that is mission-type tactics. You know when an officer only gives his subordinates a goal to achieve and the resources needed to achieve it”. This I needed to learn more about, so upon arriving at home, of course I looked it up.

What is mission-type tactics?

So apparently mission-type tactics (Uppdragstaktik in Swedish, Auftragstaktik in German) is something that the German Wehrmacht has been using successfully for over 100 years, and that is the basic leadership method used in the Swedish armed forces and in most of the special forces units around the world.

Little tin soldiers using mission-type tactics. Or are they?

When I was a conscript in the Swedish coastal artillery I was taught that a Swedish soldier is worth more than any non Swedish soldier, since he or she is taught to think for himself and not rely completely on the orders from his superiors. If the soldier does not work on his own, whole units can be disabled simply by “taking out” the officers, breaking the chain of command. This will not work in the case of the Swedish armed forces and the reason for this being, at least in part, mission-type tactics.

“In mission-type tactics the manager states the task and action rules and divides resources but leaves as much of the implementation as possible to their subordinates. Coordination is ensured by the manager’s desire and the mission’s purpose and meaning being clearly expressed. Mission-type tactics requires a management philosophy that is characterized by initiative, decision-making autonomy, individual responsibility and mutual trust between managers and staff. Mission tactics further requires high level of training and discipline… Military units are forced to act in complex dynamic situations, often under great uncertainty and time pressure. The ability to act in chaotic conditions increases the chances of achieving leadership initiative. In such situations awaiting orders can lead to the initiative being lost. Decentralized management is therefor best in these situations.”

– Befäl, issue 6 of 2002 (Swedish magazine for officers in the Swedish armed forces).

Several sources state that it is vitally important for the person or team given the task to understand the true intent of the customer (oh, sorry, superior officer), since that would allow him/them to adapt when something changes and still work towards the given goal. The team or person might even choose to disobey orders from other officers if that will take them closer to achieving the goal.

Surprisingly agile

I find it interesting that the military, an organization that is the definition of hierarchical and that is often thought of as being quite strict and slow in making decisions, in fact can be surprisingly agile and apparently has over a decade of experience in being so. We can probably learn a great deal from their experience, and who knows what other disciplines we can learn from. I’m definitely gonna keep my eyes and ears open.

Iterationless agile

So what is this all about? No iterations, microreleases, what ever! I have to say I was extremely sceptical at first, but during the last few weeks I have started to change my mind. I’m now at a point where I would very much like to try it. There’s still a few issues I have to think some more about though.

What about the oh so important story discussions?

One of the most important pros with the iteration planning meeting is that the entire team get to start discussing the prioritized stories with the product owner, since this is an important part of making correct estimations. The team gets to start solving the problem and get a common view of upcoming issues and future work. How do you handle this without this meeting? I guess a step in the right direction is to switch pairs extremely often. Many times a day. But will that be enough?

What about retrospectives?

I guess this is a minor issue. Even with no iterations, the retrospectives could be run periodically. Maybe once a month, or once every two weeks. I heard a neat solution the other day: The team had a flip chart page posted on a wall, and when someone had an issue he or she felt needed to be discussed, a note was written and posted on the page. When the page was full, a retrospective was run. Me like.

What about selling the idea?

I can see my current project running iterationless, since they have been running iterations for so long and have a very good pace and a good heart beat for releasing. But I still have trouble seeing a completely new team start running with no iterations from the start. The reason for this is that I feel it would be harder to sell the idea of agile to the team. The idea of short iterations is a very nice and easy to understand selling point for people who are used to the non iterative way of working.

I have tried the idea on my team and the product owner, and they where surprisingly positive. We might try it in the coming months. If so, I will post the result here.

Development stages in learning TDD

When having a newborn baby you read a lot of books. Books on being a parent, books on being a father, books on child behavior; books on everything you think that you need to know.

Currently I am reading ‘Why They Cry: Understanding Child Development in the First Year’ by Hetty Van De Rijt and Frank Plooij. According to the authors, all children go through a number of stages during there first year and each stage ends with a big step in the child’s physical and mental development. All children are climbing a set of stairs so to say. At the end of each stage, the child will suddenly see the world in a whole new perspective and everything that was familiar before is suddenly completely new to them. This results in the child being confused for a while and during this period, that may vary in time, he or she will be very clingy and will often be inconsolable. The authors call these periods cling-periods (translated from swedish). What’s more is that it is this new perspective on life that is needed for the child to get new insights and reach the next stage. A stage can never be skipped. The book also emphasizes that all children are climbing each step in pretty much the same time and pace. The first cling-period is reached at about five weeks of age.

How we learn TDD

When I think back on the way I started learning TDD, I realize that it went by in a similar way. At first you have only a basic idea of what TDD is all about, and you start practicing. Suddenly you learn something new that greatly improves the quality of the tests you are writing and you leap forward to the next level. You continue practicing, and soon you are ready for the next stage. At least this is how I learned TDD. I have tried to list some of the stages that I’ve reached so far when it comes to learning TDD. I might have missed some small step in between, but these are the major stages as I remember them.

Stage 1 – First step

The first stage is where you write your first unit tests. This step is probably taken on some sort of course. For me it was a two day course on eXtreme Programming. What characterizes this and probably the next few steps is that what you are doing is writing tests, as opposed to the later steps when you are probably using TDD to design and document your code. A typical test during this step would be testGetName().

Stage 2 – Learning to walk

Once you start to get more of a hang on writing unit tests you now start to test in a larger scale. You might have tested some interaction between classes before, but now you start to test more advanced interaction. This stage might have been reached by the discovery of mocks. You are still not using the tests to design your code but merely for testing the code after designing it, perhaps not in written code, but at least in your head. A typical test during this step would be testSelectAllNamesFromDatabase().

Stage 3 – Coping with übermocks

One day when you are about to add some new functionality to a class you realize that the tests you wrote for that class a few days, weeks or months ago simply is too hard to modify or even understand. Typically it is a huge test class with a lot of mock-code, or it might be a class with a huge setup and only one assert. If you spot this or something similar, it is a sign that says it is time to move on to stage 3. Some people choose to focus on symptoms and not the root cause, just sighing and blaming the mock framework or something to that effect. Those people tend to get stuck at stage 2. During stage 3 you start to actually use TDD for what it’s good at; designing your code. You start to realize that a test is an excellent smell-detector. You realize that when writing unit tests starts to hurt, something is wrong. Stuff like huge set-ups and huge test classes in general, usually means that the class under test is doing too much. There might be a responsibility or two in there to extract? You start to use factories to extract object creation, and soon the huge mock-setups are a thing of the past. A typical test might be testCreateDatabaseConnection().

Stage 4 – Dependency injection

Using factories, and testing every line of code, usually means that you end up with ‘factory factories’ and ‘factory factory factories’. Sooner or later you need to add some kind of dependency injection, like Spring. Now you end up with questions like ‘do i test the spring-configuration?’. Well, this is the well known debate on ‘do I test configuration’. I don’t.

Stage 5 – Testing behaviour

Now you’ve reached the stage where you add another dimension to your tests; the dimension of documentation. You start to focus on the behaviour of the class. Doing this you probably adopt a new naming convention for your tests. You probably also write a greater number of tests for your classes. A good convention is that you want to know what your class under test is capable of only by reading the test-names. A typical test during this step would be testRetrievesNamesFromDatabase() or testUsesPhonenumberToFindAddress(). Now it is not so much about test-first anymore. Now you realize that the tests and the code are one entity, tangled together, living and coevolving. It’s just as much the code driving the tests as it is the other way around.

Stage 6 – The next step

…

I myself has not reached stage 6 yet. I don’t know what will take me there. Maybe a cool and easy way to testdrive GUI? I yet haven’t found one, even though I’ve looked. Maybe Acceptance Test Driven Development (ATDD)? Maybe User Guide Driven Development (UGDD)? Maybe the discovery of a way to use unit tests to record history within a team, so that when all the original developers have left, NOTHING is lost.

Everyone learns in the same way?

My theory is that everyone is learning in a similar way as mine. The stages might differ some, as with babies, but maybe you recognize some things in the stages above that you have experienced on your own when learning TDD.

J.B. Rainsberger once said that a person, if i remember correctly, must write something like 1500 unit tests before he fully understands TDD. That statement would also strengthen my theory. Like there is a path that each individual must take, and there are no shortcuts. You cant skip steps in the set of stairs. You have to climb each step to reach the next.

Maybe this is why some developers whine and complain a lot about TDD. I know many developers that are stuck at stage 3. Even some stuck at stage 2. If I would write a book about my own set of stairs, maybe that could help others to climb theirs?

By the way, my daughter is approaching her first cling-period. Me and my wife better brace ourselves.