Hackaton – Agile vs "Freestyle"

My thoughts on the pros and the cons of using Agile methodology during hackatons as opposed to just improvising and pretending you are in control. All of this based on 24 hour long hackaton experience.

I had opportunity to attend my very first hackaton in which we had to come up with interesting idea for innovation, research the idea, design it and then develop it in Agile friendly way. The word of the day was Scrum as it was the Agile methodology we were supposed to use. We had couple of days to do the research and then we had 24 hours on the event itself to actually develop it.

Team is important part of Agile

The very first thing we noticed is that one of our developers did not turn up. So we were man short right from the start. This proved to be little problematic as the final product could not be such adventurous anymore. But we did not give up.

We had extensive discussions and brainstormings about how we could implement the ideas we had. It did not go well as some of us did not believe the basic idea was worth it and the rest did not believe the extended idea could be managed in such short time. Once again, we did not give up.

We decided to get backend developer into developing immediately as the rest of us (Product Owner, Business Analyst and Front-end Developer) started to sketch the interface and summarize the features of the tool.

After hour of designing we came to conclusion that nobody believes in any of the ideas we had. We got stuck and as a result our backend developer decided to spend his time on something that has potential to work - therefore leaving our team.

Down by two developers and with not actual backend developer the job just got extremely difficult. But we still did not give up. The fact we lost these resources meant that our product had, extremely easy and fast to develop for people with no proper experience in development of backend. That is quite a restriction.

That was the time I realized how important is to have diverse team in Agile. What I mean by that is not that each person needs to be focusing on something else, but that sometimes it is better to have some jacks of all trades. We had those and that saved us. Even though non of us was backend developer, we had some idea what to do and we actually succeeded in doing it.

Work management

Not having specialist for backend but having generalist who could do backend - slower than specialist would, but still - we were on right track. Time came to distributed to work around the table, make sure everyone has something to do and knows what others are doing.

This part of development process was not done properly in our team. We simply appointed people as specific role. One was backend designer, one was front-end designer and one was kind of merging everything together. After that, nobody knew what is happening and who is doing what. Each of us was stuck on our own jobs.

This meant when I was done with backend I started to work on generator of random data. Because I needed that to fill the backend with something. Others had no idea I am doing that. It could result on catastrophe as any of the other guys could decide to do the same. Luckily they didn't.

With roles so diverse as we had, and time so short, we truly only sticked to our thing. Eventually succeeding in connecting it all together without creating that much redundancy - there was some though.

In my opinion this is very dangerous approach to the problem but on the other hand, as we were short on time, we had very few people and very distinct jobs, it kind of worked and probably saved us a lot of time we would otherwise spend in front of whiteboard writing sticky notes and determining who is gonna do what, how long will it take and what sub tasks/stories we can break it into.

By simply sticking to our roles, doing stuff we knew was needed and not bothering with 'bureaucracy' we most likely saved some time for more development - something we needed gravely.

Cooperation

One thing praised in Agile is cooperation between people. I finished backend, I finished data generator. I was done. I could pack things and go home.

Front was barely started at this point. And that is when the cooperation started. We worked together to get the front-end done. This enabled us to work more efficiently as if there was just one person struggling to get it done and rest of us checking Facebook. Even if I had no idea how to help, I could google the issue and see if some of the results could help.

Later we got another developers to help us and once again the same role break down happened - backend devs, front-end devs and the guy in between. But this time it was little bit different, this time it was backend developers and the jacks of all trades cooperating to make front-end and connect it to backend + updating backend as needed.

We stopped being individual people, being individual roles and responsibilities and we started to be a team with one responsibility - get that tool done by the end of hackaton.

From that point on, it was a lot easier. And all of that happened because we did not give up, we did not back down and we did not leave even after our work was done.

Conclusion: My personal opinions

All of this are opinions I made after this hackaton and they can be horribly far from the actual truth about Agile.

• If your are small team and your roles are diverse, I found it way better to save time by splitting the general responsibility instead of spending it on bureaucracy and separating smallest of tasks.
• When people share similar responsibilities, do pay attention to what is being done by all individuals so you don't create redundant parts that were already done by someone else or stuff that is not needed at all.
• The moment you are done with your tasks, go and help others. At the end, this whole project is responsibility of all of you.
• Don't be afraid to be jack of all trades - gather a lot of knowledge, you might need it one day.
• Have fun! That at the end proved to be the most important thing. Without positive mood, you will most likely fail, or leave prematurely.

To summarize it, use common sense. All of these are pretty common things. They are not new, not revolutionary and not only Agile. But for some odd reason, people seem to forget them a lot. Don't be one of them.