Androits

Agile is evil, at least according to one of my best friends. He’s not able to explain why he feels that way. All he knows is that all of the projects that he has seen and heard of that mentioned the term “agile” failed terribly.
I’ve talked about this with some colleagues and a couple of them had the same feeling. They’ve seen teams trying to go “agile” but completely missing the point. And because of that, the project went seriously wrong.
I believe it’s just a bit too easy to blame the concept for the incorrect implementation. In my point of view things like Scrum, Kanban, XP can’t be wrong. It’s the way you use these frameworks and methodologies that can be wrong. I compare it to the Force (yes I am a geek and proud of it). The Force itself is not good or evil. It’s the actions you do while using the Force that determine the alignment. If you use the Force to stop someone from falling down a building, the Force is good. If you use it to push someone of a balcony, it’s evil.
It sounds easy to start the voyage towards becoming more “agile”, but I think everyone who is walking that path can agree that it’s not easy at all. It demands some serious change in mindset from all different roles involved in the software project. It’s not just something the development team has to do, or something the management can decide on. It’s a path of change that everyone needs to be comfortable walking on. If you’re not open to continuous improvement, you don’t want to embrace change and really collaborate with the customer towards finding the best possible solution, then don’t “try to go agile”. It feels to me as if a lot of companies are trying to become more “agile” because of the hype and not the real mindset.
“Agile” to me is all about collaboration, trying to find a way for all the different roles in a project to contribute and really work together. It’s also embracing change, working together with the customer to be able to present the best possible solution for his problem. I experienced firsthand the difficulty of trying to convince a team to change their mindset. It’s not easy to try and help people make this transition, but I’m still convinced “agile” is the way to go.
Collaboration, as mentioned in the virtual revolution documentary, is the basis of the social media and web community as it exists today. Can it form the basis of software development or even the entire industry?

I didn’t know what to expect of this convention, but I am getting more interested in testing in general. I’ve been doing some work around test automation on a technical level but never on acceptance testing, more like the unit and component testing.

When I arrived at the scene, first thing that I noticed was the rather small number of people there. I’m used to the Microsoft techdays and in comparison to that this was a very small crowd. I liked the fact that we were only about 70 there, that way you can have better interaction between all the attendants.

I’m not going to go through all the sessions. I just want to pick out a couple of subjects that are still lingering in my mind. We saw a lot of different tools, frameworks, to enable people to work in a Behavior Driven Development process. I must admit this was completely new to me. I know what Test Driven Development is, but I never heard of BDD. I don’t think my mind has ever been so open for anything. So I just let Gojko, Aslak, Alex and all the other presenters make their case. I sat back and tried to take in as much as I could. I think it was somewhere during the first day that I was convinced I wanted to try this methodology. I’m certainly not at the point where I want to integrate this into a large project; I don’t have the experience for this. But I am going to try it in my next in-house project.
We saw a couple of nifty tools like Cucumber (love that name), GivWenZen (love that name even more), GuiDancer (why are all these tools getting to have cool names?), JNarrate, ETA and Fitnesse. Ok, by now I know that this Fitnesse thing is nothing new; it’s been out there for some time. But I just never heard of it, I think mostly because of my biggest realization of this convention which I will elaborate on next. All these tools have a lot of merit and have a serious potential.

BDD is still a Java community thing. There was not a single piece of .Net code to be seen anywhere these two days. Looks like the .Net community is not fully in sync with this way of working yet. Do I see some opportunities here? I also found it quite easy to read Java code, although it has been at least five years since I wrote my last line of Java.
I’ve been looking for a new project to develop in-house and I think this convention gave me the correct amount of information and energy to think a bit about an open source tool for integrating this BDD into visual studio. I’m going to do some serious surfing and testing to find some open source projects out there that are already trying to do this. Maybe I can even find one which I can use as a base for my integration tool. I’ll keep you in the loop when I actually start development.

Apart from the BDD oriented talks, there were also a couple of people that shared their personal experience in working agile on all kinds of different projects: in-house, outsourced, with distributed teams, for the government (which is not easy, trust me I know. I’ve been trying to do that the last two years. But that’s a completely different story).
I liked the fact that other people were having difficulties too, I’m not the only one who has trouble trying to convince other people this agile way of working is a really good idea. I found it very interesting to hear other people asking the same questions I’ve been asking myself the last couple of months. The answer is actually rather simple to write down, a bit harder to implement. The key to an agile way of working is communication and there is no one best practice for every situation. There are a lot of different factors that you need to account for when you try to implement your own agile methodology. There is no all solving answer (except for 42 off course). There is no black dragon (thanks Gojko for this analogy) that can solve your team’s problems. You have to try things, experiment and always keep an (agile) open mind. And never forget that only by making errors you can grow and improve your way of working.

To quickly summarize: this was definitely something completely different from what I’m used to and I liked it a lot. Thanks to all the speakers for their insight, thanks to Maarten for organizing all of this and thanks to the attendees for being a part of this because after all if it weren’t for us attendees, there wouldn’t have been a convention