Even if you are not a developer or technical resource, I highly recommend attending at least one hackathon, preferably one that lasts 48 hours. To help you see the immense value of these short sessions, I will review what a hackathon is and one of my experiences with short projects below.
There are so many lessons that can be learned from a hackathon that directly translate to everyday work and teams. The compressed timeframe clarifies the concepts of planning, distributing work, impediments, and most importantly, working as a team toward a common goal.
Definitions:
Hackathon: A coding hackathon is a short event, typically 24 – 48 hours, where programmers collaborate on software projects, aiming to create a working prototype like an app or website. Teams brainstorm, design, and code intensively, often focusing on specific themes, such as technology innovation or social issues. The environment is high-energy and collaborative, with mentors providing support. At the end of the hackathon, teams present their projects for evaluation based on creativity and utility, with the primary focus on learning, networking, and innovation. Hackathons are popular in tech and have expanded to other sectors.
Impediments: In the context of Agile project management, “impediments” refer to any obstacles or issues that hinder or slow a team’s progress toward the goals. These can be internal or external factors and vary widely depending on the project and the environment. Common examples of impediments in Agile include:
- Resource Constraints: Lack of necessary resources, such as personnel, tools, or materials, can impede progress.
- Technical Challenges: Difficulties in the technology being used, such as bugs or integration issues.
- External Dependencies: Reliance on external teams, stakeholders, or vendors that are not meeting their commitments or timelines.
- Lack of Knowledge or Skills: The team might lack the necessary expertise or training to handle certain aspects of the project.
- Organizational Barriers: Organizational policies or bureaucracy that slow decision-making or limit autonomy.
Going from Suck to Awesome
Suck – Never attempting to use Agile outside of a normal business Sprint cycle of 2 to 4 weeks.
Sucks a little less – Using some but not all of the Scrum ceremonies for a hackathon event.
Awesome – Using rapid-fire Sprints for individual projects, hackathons, and other short-duration work.
Hyper-Agile Hackathons
The Story
You know how over time, some stories just get grander and grander each time you repeat them? Full disclosure—this is one of those stories (just in case one of the architects who was with me reads this blog).
So, each year, the company I owned took architects on a mini-retreat. One of the perks of owning a company in Colorado is the great outdoors. This particular year was during especially harsh economic times. Hence, our budget was very limited, and we ended up in two cabins at a local National Park—low cost for sure! (The fact that more than a couple of people would think it’s cool to spend a weekend coding and talking tech in a rustic mountain cabin may be unique to the West.)
The weather turned very nasty, as it often does in winter, and we were snowed in with nowhere to go and almost no heat! Remember, these were budget cabins. The CPUs in our laptops were not very efficient back then, which thankfully helped heat the cabin.
The problem we were going to tackle as a group was that our time-tracking tool totally sucked and was too hard to use. We had to track time because our consulting business billed by how much we worked. We decided to keep the underlying database of an existing third-party tool and rewrite a UI that met our specific needs. It had to be quick and easy to input data and take the pain out of tracking our time.
We decided on Scrum for the two-day hackathon. Here is what it looked like:
Two-hour sprints, though we typically prefer two-week sprints.
We had stand-ups where each person took an item from the whiteboard (we brought whiteboards, of course; in retrospect, we should have brought a heater) and wrote their name next to the task. Each person stood up, announced when completing an item, and grabbed the next one.
We had the planning ceremony for 15 minutes to review the approach at the beginning of each Sprint.
We focused on MVP techniques, specifically on being able to use the product after each Sprint. Given how cold it was in the cabin, we were legitimately concerned whether we could continue the hackathon, so any Sprint could have been our last. We didn’t know if we would have to leave the cabins because it was so, so, so cold.
The non-coders in the group helped with QA and anything else needed.
We didn’t worry too much about what we were doing four Sprints from now; we just kept doing Sprints until we finally fell asleep.
We agreed upon leaving the last Sprint of the trip to clean up loose ends and not start any new features. Our goal was to build something that weekend that a 100-person organization would use and appreciate on Monday when we returned to work.
After just two days, we had a working system. We could barely feel our fingers, but we had a working system!
Lesson Learned – Defining and Scoping the Goal
In general, estimation is very difficult, so people are notoriously bad at it. Most teams are structured in a way that doesn’t allow members to get better at estimating. Under extreme time constraints, such as a hackathon or other system outages, it isn’t that estimation gets easier; rather, there is group acknowledgment that the time is fixed. The short timeline helps the team define and focus on the highest priorities.
Additionally, the time constraint helps the team prioritize items. We had great discussions on what was absolutely needed and what dependencies could get in the way of delivering those items.
Lesson Learned – Impediments
Once again, with limited time, impediments must be dealt with. Typically, teams use the following approaches to mitigate impediments:
Daily Stand-Up Meetings: Impediments are often raised and discussed in daily stand-up meetings. This ensures the entire team is aware of the issues and can contribute to finding solutions.
Role of the Scrum Master: In Scrum, the Scrum Master plays a crucial role in addressing impediments. They facilitate discussions, help remove obstacles, negotiate with stakeholders, and ensure the team can focus on their tasks without external distractions.
Collaborative Problem Solving: Teams often work together to brainstorm solutions to impediments. This collaborative approach leverages the diverse skills and perspectives within the team.
Prioritization and Backlog Refinement: Sometimes, impediments can be mitigated by reprioritizing the backlog or refining tasks to make them more manageable.
Engaging Stakeholders: For impediments that involve external parties or higher management, effective communication and engagement with these stakeholders is essential. This might involve clarifying requirements, negotiating resources, or adjusting timelines.
Continuous Learning and Adaptation: Agile teams learn from each impediment and adapt their processes accordingly. This constant improvement helps reduce similar obstacles in the future.
Regular Retrospectives: During retrospectives, teams reflect on what went well and what didn’t, including how impediments were handled. This reflection leads to action items for improving processes and dealing with similar issues more effectively in the future.
Seeking External Help: External expertise (like consultants or specialized trainers) is sometimes required to resolve specific technical or organizational impediments.
Given the nature of the hackathon, several of these approaches weren’t available, putting even more focus on the constraint. For example, given it was the weekend, reaching out to the stakeholders wasn’t possible.
Interestingly, with long-term options limited, teams get very creative with workarounds. There just isn’t any room to procrastinate and defer issues. Many times during our hackathon, we acknowledged the impediment, and instead of removing it, we worked around it. I equate this to when a city bends roads around 100-year-old trees instead of cutting them down.
In cases where impediments must be dealt with, the team quickly determines who should deal with the block. Sometimes multiple people are required because the Sprints are so brief. A plan is made with the help of the entire team. Then, once the plan is set, a subset of folks could then deal with the issue.
Lesson Learned – Follow-Up
To a layperson, hackathons can be misleading. Why shouldn’t it take only two days to code a complete system? Why does it normally take weeks or months to add features?
During compressed timelines, systems typically eliminate many critical sections. For example, just because a system works doesn’t mean it is secure. Often, error handling, DevOps, and testing are completely missing. Unfortunately, much of the work of developing a system isn’t just the main feature but also concerns other vital issues like billing, usability, integrations, documentation, etc.
Once we returned from our frozen cabin trip, we met in the office later that week and devised a plan to roll out the system. We confirmed the functionality with other stakeholders. We also cleaned up the code, tested it, and created minimum documentation.
The point is the systems that hackathons produce are very valuable because they confirm approaches and concepts. That said, they still require software development best practices.
In our case, we were addressing a real pain point, so there was pressure to finish the system we started. Not all projects will have that much pressure to finish, so they must be onboarded into the normal development processes. Hopefully, these processes are strong enough to carry the initial work to completion.
Lesson Learned – Other Secondary Benefits
Even if the software isn’t adopted, extreme timelines can bring individuals working on the same team closer together and help form a team that works better together after the hackathon.
A great team really excels under pressure because they have the tools to help them rise to the challenge. Occasionally, the team should engage in some high-intensity activities. These events help the team practice their skills.
Plus, the dynamic nature of a hackathon might not be all that different from dealing with a major outage or a major security breach. Remember, every great team—from professional sports to the military to your local volleyball group—practices as a team.
I haven’t mentioned it yet, but there is an Agile guiding principle that says work should be sustainable. This comes from common practices concerning software development of having to exert non-stop effort around the clock to get work done. I won’t go into details, but it just doesn’t work in the long term to solve issues by grinding out inhumane efforts week after week after week.
BUT, every once in a while, it is beneficial to turn up the heat, just as long as it doesn’t become a habit. As another example, it’s common practice to occasionally release a ton of water from dams because it benefits the environment. Yet too much, too often, can be unsustainable and damaging, if not catastrophic. It’s the same with work: too little can lead to team complacency, yet too much can lead to burnout. Every once in a while, though, these hyper-agile sessions can make the team even more cohesive.
Conclusion
In summary, the exploration of “Hyper Agile” in the context of hackathons underscores the flexibility and efficacy of Agile methodologies in extremely short timeframes. The insights gained from a 48-hour hackathon demonstrate Agile’s capability to excel under tight deadlines, highlighting important lessons in strategic planning, overcoming impediments, tightening teamwork, and project follow-up.
Emphasizing rapid-fire Sprints and collaborative problem-solving, the hackathon experience illustrates how Agile principles can be dynamically applied to brief, intense projects. This approach not only drives quick development and innovation but also enhances team dynamics and effective problem resolution.
The experience reinforces the adaptability of Agile, proving its value beyond regular business cycles and showing its potential in diverse project environments, from high-pressure hackathons to routine project management.
Komentáre