Minimum Viable Sprint – a One Week Hackathon

We, Marcos Pacheco and Marcus Tannerfalk, work as Agile Coaches in the Palma office for the hotel search company trivago. This is our experience in working with a development team in daily sprints with the goal of delivering a MVP (minimum viable product).

Introduction

One of the development teams that we work with wanted to create an MVP (minimum viable product) for a new feature that they are responsible for. We suggested to do this as a one-week hackathon with daily sprints, which we have never tested before. So how small is a Minimum Viable Sprint (MVS)? Can it be done in one day? This article describes our approach and what we learned from this experience.

The team

We always strive to have teams as empowered and autonomous as possible. This specific team had the following members: product owner, dev lead, front end dev, back end dev and two quality assurance engineers (QA). One of these QAs wanted to try to work as a developer, which we of course embraced.

Preparation

To be prepared is without saying, super important, due to the obvious reason of not losing any of the precious time that you want to spend on development. The following are the main points that we prepared before starting the hackathon:

• Co-location: the team is usually spread between two geographical locations (Palma and Düsseldorf). In order to enhance the communication, we decided to co-locate in Palma. We relocated them to a space in the office where they would not be disturbed by other teams.
• Office infrastructure: when moving dev teams, there are certain things that are important, from network connection to the right chairs.
• Scrum-boards: we created both a digital and a physical board. This gave us a little overhead, but we did not see this as blocker. The reasons for this were:
  • Easier to prepare digital tickets
  • Higher commitment when moving/pulling a physical ticket
  • A limitation in JIRA. The team usually use the ticket types feature, task and technical sub-tasks. We wanted to include only the subtasks to a daily sprint, but JIRA does not allow that. It needs the parent task as well, and then you also get the subtasks intended for the coming days.
• Groomed and prioritized backlog: we gave the team a challenge to break down all items to be done in tasks that did not exceed four hours, identifying all dependencies and risks. This resulted in a well groomed backlog which was then co-prioritized on a daily basis between the product owner and developers to define the daily sprint goals.

The kick-off

We really wanted everybody to be on the same page when starting a week like this, so we had a kick off for the hackathon week, talking about what was vital for this to be a success.

1 week hackathon success enablers

• Goal
  • Clear and commonly understood
  • User stories written and prioritized
• Focus
  • Clear our calendar
  • Full focus on the team, try to limit interaction to others
• Close interaction
  • Don’t dig deep into problem on your own, ask someone to help you instead
  • Pair/swarm programming
• Risks
  • Dependencies and bottlenecks are identified

We also had a strong emphasis on the plan for the week, since this was something new for us all.

1 week hackathon schedule

• Monday: Introduction
  • Envisioning (establishing the project vision and success criteria, establishing the product backlog, doing the basic architecture, and grooming the product backlog)
• Tue-Thu: Daily sprints
  • Reachable targets for every sprint
  • Definition of Done (DoD) has two levels
    • Presentable for feedback (Dev complete)
    • Releasable quality assured (QA complete)
• Friday:
  • Finalize and prepare for:
    • Demo
    • Retrospective
  • Celebration

Expectation management or futurespectives are always interesting. We therefore created a baseline to be able to measure the success rate in the end. With a simple exercise, described below, we gathered everybody’s expectations. The result can also be seen in the picture.

Expectation

Write on a post-it: What am I most looking forward to during this week?

The dailies

As some of you have already noticed, we do not have a dedicated Scrum Master for this team, and we did not have that during this week either. This specific team has reached a level of dynamic where they communicate and remove impediments by themselves without having someone to ask or help them to do that. Therefore, it is our role to be more of an observer, coach and facilitator, when needed. The daily stand-ups were done by the teams themselves, including deciding on the daily sprint goal, with us just observing from time to time.

The Retrospective

Although we had daily sprints, we did not have formal retrospectives for each of them, because that would have created way too much overhead. We just added a simple question to the daily stand-ups: “Is there a need for any changes?”. And based upon that an action was taken, or not.

The formal retrospective was planned on the Monday after the hackathon week was finalized.

We allocated 1.5 hours, and since parts of the team had travelled back, we had to do a remote retrospective, which always complicates the ceremony a little, but we did it with the following setup. One web camera pointing towards the flipcharts and one laptop showing the room, so the people in the remote office could see both the people and the flipcharts.

Step 1 - Expectations

Starting off with understanding how well the team’s expectations were fulfilled, we asked the members to rate them from one to four, where four was “perfect” and one was “not so much”.

As you can see, everybody rated the maximum score, which was super nice to see! Comments on the post-its:

• Great experience working together with developers, feeling part of them
• It was completely successful and it will go live soon!
• All developed and tested, good team effort!
• Great work together with little interactions, developed what was planned

Step 2 - What happened and why

We wanted to get the team’s opinion on which factors exactly contributed to the project’s success, and to what degree. To guide the team a little, we predefined factors that might have had an impact on this hackathon, such as:

• Teamwork (internal focus, how individuals worked together)
• Collaboration (external focus with other teams such as Operations)
• Learnings (takeaways to make things better in the future)
• Organization (way of working, prioritization, team alignment, planability)
• Communication (individual’s communication, answering fast, taking time, clarity…)

Everyone rated the outcome and gave constructive feedback. For example:

• Teamwork: The first couple of days were really good, all people were located at the same place, so developers rated (10/10) for the period when all were together. But during the last two days, half of the team were back in Germany, so everyone suffered somewhat from not being together. However, the team rating was still pretty high (8/10).
• Collaboration: The team itself was aligned, but the teams they were depending on, like operations, were not aware about this experiment, and therefore not aligned. The team said that it would be good for the next time to include the third parties somehow in the hackathon.
• Learnings: The entire team was really satisfied with this, all of them learned something, and as mentioned earlier, one of the QAs participated as a developer.
• Organization (Planability): It was not clear who should create tickets, and how to prioritize.
• Communication: There is no teamwork without good communication. The team highlighted the emphasis on communication and collaboration, which are both vital. For example, when asking if someone could perform a code review, the team was responding fast and the communication was really flowing well.

Organization (plannability) received the lowest score, and was then decided to be discussed further.

Step 3 - Discussion

The purpose of the following exercise was to sustain positive behaviours and actions, and to emphasize which behaviours and actions could be improved.

These were the comments on the post-its:

In favor (continue doing)

• Time to prepare in advance
• Analysis and preparation
• Communication
• Organize taking into account type of job (responsibility)
• Required tasks broken down before starting
• Thinking in the future (prevision)
• Planning tickets (realistic outcomes)
• Align in what is achievable

Could be both

• Split tasks in little pieces

Against (stop or improve)

• Blockers
• Starting with something else before finishing
• Organizing without asking others
• Improve Collaboration with other teams
• ”The unexpected”
• Not splitting work in advance

Further discussions concluded in a consensus; that it really helps to target MVPs and being together.

One of the team members also said something really interesting about the mindset of how to plan better, in terms of being realistic and what could be achieved:

Plan with pride, think realistically and achieve a dream!

It was also mentioned that the team had to take some shortcuts during the week, because of the planning difficulties. Shortcuts that probably would have not worked in bigger teams or projects.

Recommendations to avoid these shortcuts:

• Each person should split their tasks in advance, not only the dev lead, as that might lead to a bottleneck.
• Make it more clear what needs to be QA’ed and what not; as the QA struggled and became confused with some tasks, that were split into subtasks.

Conclusions and insights

So answering the initial question: How small is a Minimum Viable Sprint (MVS)? Can it be done in one day? Yes absolutely, it can be done in one day, but there are some things to keep in mind.

Team dynamic

This was overall a great experience, with collaboration and communication excelling. We did have a great baseline in the team, with them already having a well working team dynamic and being motivated and open to participate in this experiment.

Learning

Hackathons are generally about learning and inspiration, so combining this with value creation of building an MVP was a great experience for the team. Testing new roles during an event like this is feasible. But you might add a risk in lack of knowledge then. On the positive side, you will gain drive. And in our world, the drive of learning new things always trumps knowledge.

Way of working

Generally, having specialist roles like QAs could possibly create unnecessary bottlenecks. It is much more preferable to have a more test driven development process. The workload can then be more evenly distributed.

The daily planning could have been even better, by preparing the following day’s objectives at the end of each day. And on the following morning, go more in detail and make sure that all is clear, and all requirements are there.

The team suffered by not being aligned with the external teams, such as operations, trying to be really fast and then having to wait unexpectedly, because an external team that is not participating in the hackathon needs to take action, can be really frustrating.

Also having a more defined Definition of Done, not only for the developers, but also for the product owners, who creates tasks and the business specifications, would have been preferable.

Retrospective

The whole team rating their expectations being met in full is great, but might be a false positive. We have to consider that it is highly unlikely, but of course plausible, that everybody had such an awesome experience. It is easy to be influenced by others when presenting publicly, so we will think of opportunities to reduce the bias.

The definitions of what we called “the factors” were not clear. We realised this when executing the exercise, and the obvious example is what was called Organization, which were more related to the ability to plan i.e. planability.

Another improvement area is that there was not enough time to discuss all factors in depth, which might have left out important information or comments.

And finally, preparing in advance is always beneficial, and especially when you are having people from different offices joining.

Conclusion

The One Week Hackathon is the perfect extension to the popular Google Ventures Design Sprint concept by creating a MVP out of a realistic prototype.

We would highly like to recommend others to try the same type of concept!