How we arranged a Hackathon

Hackathon was something that we had discussed for a long time and thought that it would be a nice event to arrange. I noticed that hackathon as an idea has been implemented in many forms but the one we used was borrowed from Atlassian. The idea was to give people 24 hours, no guidelines or boundaries besides the rule that one should present the results to the audience.

As this was the first time ever, we wanted to first check that is there even any interest for this kind of thing. We created an idea bank where people could 'deposit' their ideas on what they thought would be cool to try. When we had around ten ideas it was clear that we would do this thing.

Behind the scenes we set up a Hackathon Confluence space. It hosted an environment for people to register their team. Also it was a great way to arrange the electronic voting. Our technology unit head was already very much involved, but we wanted to get also our CEO as a sponsor and guardian for the event. After all, that's also a good way to guarantee that people are confident on spending their time for this kind of event and no-one will book meetings or customer visits for that day. When everything was clear, we announced the date and sent out invitation to everyone.

There were some necessary purchases to do before the grand day. For timing the demos (we had decided that each team would get a five minute slot to show what they had made) I wanted to get a Time timer. I saw one of those in a training and understood how simple yet brilliant the idea is. It's very easy to visualize how much time you have left with this little buddy.

Then we of course needed something to keep the people awake if they wanted to pull an all-nighter. Our company is not so big and I wasn't really sure how many participants we would get, so I got as ~50 Battery energy drinks.

And because everyone (should) know the Ballmer peak and we wanted to get awesome hacking results, we needed some alcoholic beverages.

Finally we wanted people to be constantly aware of the coming event, so we replaced our normal wall mounted status display with a countdown. It was very hard NOT to know when the Hackathon would start!

On the Hackathon morning we had a very short briefing about the rules. As stated already, there were no restrictions regarding the topics. Only rule was that you should be able to demonstrate the results the next morning, in a maximum of five minute demo. Presenting failure would be also very much acceptable, since when you ride a rocket, predicting the precise landing spot can be tricky. ;)

When the 24 hour time started rolling our idea bank had grown tremendously. We had almost 30 different ideas! And the number of teams was also astonishing. If I remember correctly we had 15 teams, some consisting of only a single person, but teams anyway. 

During the day the ideas got developed. We ordered some pizza for the hungry people just tried to root for everyone. It's worth mentioning that also people who were not themselves participating were very supportive for all the hackers.

As this was the first time, I didn't really expect people to stay up all night, but some teams did some late night coding. There were some hilarious pictures taken in the office during some very non-standard office hours. :)

When the next morning came, we had set up our demo environment. When the countdown reached zero, we started right away with the first demonstration.

The demonstrations were really high quality. It was really eye opening for people to see how much can be achieved in 24 hours when skilled and motivated people give their best. It is a huge potential that doesn't always get fully blooming. This is something to really pay attention to more.

As the master of ceremony I was really strict with this five minute rule. When the Time timer beeped, I started applauding. With some people the running out of time took them by a surprise, but almost everyone managed to present their ideas and results in time. It was clear that people had understood the idea that 'only the demo counts'.

Even though there were plenty of people physically present in our headquarters, we wanted to have electronic voting. We are a global company with multiple offices so it did felt like the right thing to do. We had ten minutes for the voting and then we announced the winners. They received the challenge cup, some personal rewards and of course awesome bragging rights for winning our first ever Hackathon. By the way, here's a picture of the cup:

All in all the event was a big success. Many of the ideas could be taken straight into production and unleashing people's potential was an awesome boost for the whole company. Definitely this is something to do again and I can really recommend arranging this kind of event if you have the possibility.

Release Planning Day

Earlier this year I wrote about our Release Pre-Planning. This time I wanted to take things a bit further. We had previously been discussing about the Release Planning Event described in the Scaled Agile Framework. Going for a two day meeting with the whole company sounded like something that could be useful, but would maybe require move convincing than I could do in a short period of time. But if I started with just one day...

So I made a preliminary plan for a one day's Release Planning Event. Rough schedule with the important events and list of requirements from some of the key actors like the Product Managers and Business Owners. Then I communicated this to our technology head who received a nice buy-in from the whole management. Of course something like this could not take place without a proper management support. After this I invited everyone in the company to the event.

Fig 1. Schedule of the Release Planning Day

As a groundwork, the Product Managers were asked to put their Roadmaps in order and the Business Owners to prepare for a short presentation about the current state of our business. All the necessary meeting rooms were booked. The main meeting hall has high level audio-gear with microphones and loud speakers. We have development teams on multiple sites. (Actually I booked almost all of the meeting rooms in the office to make sure people would concentrate on this event. ;) )

At the start of the day I gave a really short overview on what would be coming. Then we quickly moved into the business context. Our two Business Owners told us briefly about the most recent trends in the markets and what could expected in the future.

Fig 2. Different levels of planning.

Next, our Product Managers presented their updated Roadmaps. Figure 2 is very close to the view I have on breakdown of different levels of planning. Outside the outermost circle I would still like to have company strategy, but I'm lazy with the pictures. As the Roadmaps are still rather new concept for us, they again raised a lot of discussion, but in a constructive spirit.

Surprisingly after first hour and a half, we were still on schedule! After going through the Roadmaps I explained the plan for the rest of the day. The purpose for the whole day was to craft Release Plans for our product teams. In addition to those, I wanted people to identify the possible dependencies and potential risks. Making those transparent would help us address them later.

Then we had the first Team Breakout. People moved into their team rooms together with the stakeholders. Target was to get some kind of draft plan that could be refined later. This time period included also the lunch (most people are more productive if they get a decent meal during the day.)

One o'clock in the afternoon we met again with the whole company and started to go through the draft plans. This was also a time to face the reality and notice that some Product Owners and one Product manager were not present hence making it impossible for some teams to craft their plans. This was remedied by agreeing that those plans would see the daylight next week. No panic there.

But going through the draft plans helped to identify a couple of topics: as quite often, some of the plans were really optimistic. And there were dependencies between the teams and some general confusion about what to do. We didn't settle these problems right there and then. They were just identified publicly and settled later by the teams themselves.

Originally I planned to have a physical board for writing down Risks and Dependencies and a webcam for having it visible in the remote offices. Then I realized that it would make more sense to have the board in digital format, so in the end the things were written to a Confluence page.

Second Team Breakout helped to build more realism into the plans. At the end of the day we met again at the common square. This time the plans looked a lot more realistic and people gave a (really symbolic) vote of confidence on the plans. Some of the plans could have been refined a little more, but the results were satisfactory. We had plans for eight teams working in three countries!

After the day it was quite clear that this will be a practice we will keep on doing. Personally I was really happy to see people take this seriously but with a small twinkle in their eyes. People participated, teams got their Release Plans and people from business and development worked together. In the end, I believe that's the essence of Agile Software Development.

Some things that were left for the next time: estimating the business value of the release objectives and things regarding the architecture vision. Also worth considering if this could be worth spending the full two or one and a half days on the topic. At least I think it's better to have it in one go than to plan for weeks.

Proper Technique

Again, I'd like to share some real life experiences and thoughts they have provoked. I learned how to swim at the age of seven. Since then I have been able to float on the water and transfer myself from one place to another. But I have never been very fast. And some of my friends have politely described my swimming style either as resembling a beater or that I'm "trying to crush the water".

This week I attended my first swimming technique course. We were swimming just freestyle and practicing the breathing technique. We were in the pool and the instructor told us what we could improve. I'm not sure the results were tremendous right away, but with every pool length something was improved. Towards the end of the session, I felt like I had learned to swim in a new way. (Interesting fact: only 10 % of the propulsion is produced by legs. And for amateurs not even that much.)

There are some important lessons to draw from this. Coaching, mentoring and teaching are efficient ways to share knowledge. If you don't know the techniques, you could seek guidance from a master. It's not embarrassing, it's wise. The second thing to note is that you will easily become blind to your own performance. An outside observer with a fresh pair of eyes can help you notice new things. And finally: only practice makes perfect. Now, after the teaching, I have a faint idea of what the proper technique is, but without practice I will just regress back to my old style. 

And the same applies also to Agile software development. Get your team a Scrum Master or an Agile Coach. Or if you are such person, consider seeking guidance from a more experienced practitioner. Mastery is an asymptote which you can never reach. But you can always get better. 

Perfect road is always ahead

Development Discussions

When I think about development discussions I have a bit mixed feelings. I strongly feel that people need to be nurtured and given chances to develop themselves. They should be encouraged to find their current limits and surpass them. Organization needs to support employees professional development by allowing (or even insisting) time to be allocated for practicing and learning new things. But then again, the initiative should come from the person him-/herself.

One of the saddest things I know is when people afterwards say that "no-one developed me". In this case afterwards means when people have been fired due to their low performance or because their skills have been outdated beyond repair. Fortunately these are extreme cases, but I also feel bad when people who still have jobs are not interested in learning new things.

I seriously doubt that it is possible to learn everything you need to know in school/university and then just apply that knowledge at work until you receive a gold watch and a nice retirement package. Maintaining your attainments is simply a must. And not just in a niche speciality area. Let's say you knew everything there is to know about VHS cassettes. After the introduction of CDs, Blu-Rays and set-top boxes rules of the game changed. The things you knew just weren't valid anymore. Or they were valid alright, but no-one cared because no-one used VHS anymore.

And this is why I believe everyone should craft their own development plans. Your knowledge/career is your product and you should be managing it. Think about where you want to be in five or ten years and what skills you still need to obtain. Then keep that in mind in your next development discussion. If you don't say it out loud, how can your company help you reach those goals?

Set your own goal, keep it in mind and pursuit mastery. External motivation is so 90s. :)

Mastering Motivation

Autonomy, purpose and mastery - three sources of intrinsic motivation. I have recently been reading Daniel Pink's Drive. I've been familiar with the concepts for a while, but now I finally obtained the book. Really interesting!

The truth about the drop in motivation due to monetary rewards is really surprising. I suggest reading the book, it is good. I won't pay you anything for doing that though. ;)

As a coach and supervisor, I'm really interested in motivation. I'm passionate about learning more about it and how to increase it. Agile methods have some of the sources of intrinsic motivation almost built-in. Self-organizing teams have autonomy to do what is necessary to reach their goals. Depending on where you work, your work may have a noble purpose (connecting people, increasing passenger safety at sea etc.) And as a software developer, if you truly take honor in your craft, you may strive for mastery. I'm actually very proud to use this video as an example of mastery. It was made by one of my talented team members.

As Pink states in his book, business doesn't always do what the science knows. It's not easy. Unlearning the old 'truths' about carrots and sticks takes time. And making peace with the fact that you are not in control. In software projects people have never been in total control. Better accept it sooner than later. Management can and should set goals and targets. If you have the right people and you support them and give them room, they will find a way to reach those goals.

As an example of 'walking the talk', I arranged a self-organizing workshop on renewing the Definition of Done. In my role I could just dictate the contents, but what good would that bring? So, instead I gathered a group of people and summoned them to a meeting room (or as this was a multisite setup, several meeting rooms connected via teleconferencing.) I explained the situation, showed them the current version and expressed the boundary conditions. I told them they were empowered to come up with a new version and I would accept it. Then I set the time-box and left the room.

I can assure you this approach has not been very common. But the results were great. When I came back after 45 minutes, I was handed a brand new Definition of Done. It was crafted by the people who will be using it in their daily work. As I had promised, I accepted the results. People were generally surprised how smoothly things went. I wasn't. Maybe I trust them more than they themselves. Most of them were my Scrum Masters.

Finally, I'd like to promote a very interesting article (unfortunately only in Finnish). It's about the culture at Futurice. It is a Finnish IT company that has been awarded as the best workplace in Europe twice. So if you know Finnish (or want to use Google Translate), I could suggest reading it through. 

Changing is Hard

I have come to the conclusion that resistance to change must be somehow built into us. Or at least it seems to be very natural. That's probably why there are countless of good and bad management books written about the topic. One of the best I know is Who Moved My Cheese? by Spencer Johnson. The plot in short is rather simple: there are two mice and two little people in a maze. Every day they go to a specific place in the maze to eat cheese. Until one day the cheese runs out and they need to adapt to the changed circumstances. Now I found out that there are even multiple videos made of the book. Here's one that I found:

Another short book about change management is John Kotter's Our Iceberg is Melting. This book is a fable telling about a penguin society. The penguins encounter a crisis when one of them notices that their iceberg is probably soon going to shatter. The book describes the steps for one possible way to carry out a change initiative. Amusingly, the reader may be able to recognize certain stereotypical (penguin) characters also in his/her own work environment.

Of course here I could pull Systems Thinking from my sleeve and simply say that it's the system that resists the change. The organizational culture developed during the years and the practices that people have gotten used to. Yes, true. It is the system that resists the change. And just like entropy, getting order to the chaos takes a lot of energy. The opposite happens without any extra effort.

In Systems Thinking management is responsible for the system, since they are the only ones who can modify it and change the rules. But sometimes it is hard to change the system even from the management direction. People are very reluctant to adopt to new ways and need constant reminding, gentle pushing and coaching. Repetition of the message seems to be really important. Otherwise people inevitably will revert to the old habits.

Books aside how do you carry out this in practice? I don't know. What I do is simply experimenting. Trying new ways of doing things and seeing how people react. Feedback is the key and sometimes a little provocation is required to wake people up a bit. And it is good to have a pragmatic colleague who pulls you out of your daily routines and reminds you to think about things that really matter: the big picture. (But it's so soothing to be busy and work on all those tiny details...)

Finally I'd like to share a video that tells about an interesting Agile organization. For me it could serve as a vision of where I'd like to steer my own organization. I think we are going to right direction, but Spotify has just taken a couple of more steps. Thank you Henrik Kniberg, you are an amazing fellow! (Also, just earlier today bought his latest book: Lean from the Trenches.)

Importance of Trust

It's fascinating how important trust is in Agile software development. It appears in many studies as a characteristic of effective teams. And trust can also be found as a decisive factor in whether distributed team succeeds or fails.

It's easier to trust someone you know. Even meeting a person once can make a big difference. After that one contact it is much easier to continue the conversation via some other tools like VoIP. That's the reason why even teams that are destined to work remotely should have at least some time under one roof in the beginning. This investment will pay off in the long run. (Face-to-face conversation is the best form of communication (co-location). )

Another place where trust is needed is the interface between business and development. (Close, daily cooperation between business people and developers.) The lack of trust from business can be perceived as too much attention into implementation details. Management should only decide what is being built and why and the teams should decide how it is built. It's also not uncommon to hear that developers are slacking off.

But I think the deal needs to go both ways. If the developers don't want business people to meddle with their work, they should provide them with visibility and concentrate on working on the issues that make most sense from the business point of view. Not necessarily on the things that are coolest, can be built with latest tools or offer the biggest mental challenges. Hopefully in many cases these can be combined and making the things the users need can be fun. But in reality this is not always the case.

To me, one essential thing in Agile software development is the acceptance of uncertainty. The only certain thing is the fact that things change. If you want to stay successful, you need to be able to adapt to different circumstances. And you need to have people around you who you can trust. Show them the direction and trust that they will find the way. (Projects are built around motivated individuals, who should be trusted.)

(The sentences in parenthesis are quotes of principles behind the agile manifesto.)

Finally, I want to share a wisdom my father used to say: "Trust is extremely easy to lose and very difficult to win back." Works both in business and in personal life.