So, I went to the Brussels Agile Tour 2013. An annual conference about agile, at least if you count two years in a row annual. It’s a relatively small conference with around 150 attendees, 5 tracks with each 5 slots. I personally consider it a good conference, because in this two years I picked up some things to take home with me. No, not gadgets or stuff from sponsors but valuable ideas to bring in practice or read up about to get deeper into them. What did I pick up this year?
I followed a couple sessions, let’s do a quick write up, because going in to depth would make this post very lengthy.
I started off with Why Agile by tcgarcez to get warmed up. A nice presentation about why agile and in which also came out that agile isn’t just an IT thing. But we all know that already it started at Toyota. But now these days we IT people probably think we’re the greatest adopters of that ‘methodology’. Well that’s wrong it’s not a methodology. It’s a set of values and principles and they are doing it everywhere. From manufacturing, construction works, research to it. See the presentation ( slides ). This is also a bit where the title of the post comes from a lot of companies do agile because it’s hot without actually knowing how to transform. And most companies do it only when they get into trouble. That is the time when the start doing real agile things. But great companies do that all the time.
There was a nice session, actually it was a role play by @JurgenLACoach and @talboomerik about Christopher Avery’s Responsibility Process. They started with roleplaying a story between a employee and a manager to come to the conclusion that the way humans handle problems is deeply embedded in our nature. The process consists of a couple steps you go to when there is a problem.
1. Denial > 2. Blaming > 3. Justification > 4. Shame > 5. Obligation 6. > Taking responsibility
A human will go to these phases when being confronted with a problem. Some go faster from one phase to another, some just quit and run away after certain phases. To fully grasp the context you’d need to read some stuff from Mr. Avery or see the roleplay. ( The slides are not enough but here they are )
If you keep this steps in mind you can confront people or yourselfn when coming to you or going to them, for a problem with the step they are in. In the end, you’ll reach a solution much quicker.
I also attended EVERYTHING YOU WANTED TO KNOW ABOUT PAIRPROGRAMMING, BUT WERE AFRAID TO ASK…. by @YvesHanoulle. A presentation of pros and cons about paired programming and a couple of useful tips on how not to or to do it. The numbers he brought showed that pair programming really pays of. We at work mostly do it solo and call each other when we have something we find really difficult to do and usually also when we’re fixing bugs in code we didn’t write our self. It is however my opinion that it would be good to do it constantly, 2 pair of eyes and minds see an think more then 1.
What I really remembered: “We do so much things in life as a pair. Why not program in pairs?” ( check the slides )
And finally I went to listen to @pascalvc who presented a talk about Real Options, and decision making. He told it like a fairy tail (it where two actually) the slides are here. It’s hard to reproduce the fairy tails, but what I really remembered from it was that decisions can be postponed to the latests moment possible, and if you can do that, do it. And that some times you’d better not make a decision because you know that it will be changed afterwards in those cases, implement all options until the final moment the decision has to be taken and then go for the option that has been decided. (Ok it sounds a bit weird writing it like that). As always Pascal referenced some must read books that will clear the path to do it that way: The Principles of Product Development Flow and Creativity Today
I had a great time, the conference had great food and great people. That must be said. Thanks to The Belgian agile community!