April 17, 2014
Trello? Is it me you’re looking for?
The ChallengePost tech team aims for continuous delivery. To achieve this, we keep our deliverables as small as possible, but big enough to provide value to our users. Typically, this means major features are rolled out piecemeal over a series of several development cycles. We strive to keep each step functioning smoothly, which means limiting the amount of in-progress work and addressing bottlenecks as soon as possible. For over a year, we’ve been using Trello to manage our workflow. Although it’s not perfect, we’ve adapted it to our needs and in general, have found it to be a great fit within our process.
We treat our development board as a left-to-right flow. Each card represents a deployable unit and the goal is to get it from the left side (Ready, or an idea) to the right (Complete, meaning deployed to the site and in use). Each card has a developer “shepherd.” The shepherd knows the most about the card’s implementation details and is responsible for shepherding it from Ready to Complete. Cards are typically linked to external resources with more information, like a Basecamp thread with assets. For bugs, this may be a link to an exception in HoneyBadger and/or corresponding GitHub issue.
A key governing principle for all our key Trello columns are “Work-in-Progress (WIP) limits.” Though Trello doesn’t enforce it, we have a prescribed limit for each column. The reasons for WIP limits are best understood with a car traffic analogy: one way to solve traffic is reducing the total number of cars on the road, the “car density.” I’ve found that we’re able to maintain forward progress when we don’t take on too many items at one time. By making sure existing work is finished before we start new work, we’re able to avoid bottlenecks — most of the time. We’ve determined our limits after much experimentation, though we’re open to reconsidering them at anytime.
For a card to be “Ready,” product and design work must be complete. Developers should have already worked with Product to determine a set of scenarios to build out. The order of cards in a column reflects their priority as determined by our product team — but in theory, all the Ready cards are important; developers are free to pick whichever they like.
Developers move cards to In Progress when they are ready to begin work and there is space under the limits for the column. We typically open a pull request on GitHub soon after starting work so others can follow along with the progress. User-facing scenarios are added as a Trello checklist. Surfacing the key requirements helps ensure product, development and QA are all in sync about the details of each story.
When all the scenarios are implemented, the branch reviewed, and the tests passed, our QA lead takes over and moves the card to Review. In order to review multiple features simultaneously, we typically deploy to our staging environment from a single staging branch. This does occasionally introduce conflicts that we’d have to resolve when merging back into master, but fortunately
git rererehelps us get around that. This git feature allows us to “reuse recorded resolutions” of merge conflicts and I can’t recommend it enough; just be sure you know what it does and its caveats.
A card moves to the Deploy column after it has been reviewed and accepted by QA. This effectively means that the implementation is approved for deployment to production. The feature branch is merged into master and the build is run against the new code. We have our CI server create a deploy tag when the build is green to mark a deployable commit. Finally, we move the card to Complete when it’s deployed to production.
How do we know how fast we’re going? Early on, there was nothing in our process to indicate how much time we’d spent on a particular card. Trello doesn’t have tools to measure how long a card spends in a column, though they did recently add some visual evidence of aging cards. What we needed was more qualitative insight into our development progress, so we started tracking it ourselves!
Every week, we recorded the time our deployed cards spent in each “bucket.” Once this got cumbersome, we wrote a script to extract data from our development board via the Trello API. We call it LionelRichie. You can fork it on GitHub and check it out on ChallengePost. Our script converts our Trello activity, among other things, into time spent on each card we’ve completed, which we can then export to CSV or Excel for more analysis. As an example, we recently started extracting cumulative flow diagrams from our Trello data via Google Drive, borrowing ideas from Aslak Hellesøy.
It’s a great way to visualize our workflow as we can easily spot issues in our progress and reflect on ways to tighten up our process. In this example, you may be able to see when we had “bug scrub” day and deployed a lot of improvements to the site in a short period of time.
If you’d like more info on our development process or would like to share your continuous delivery pro tips, leave a comment below or drop us a line!
April 15, 2014
This is the fifth post in our "How to Throw the Perfect Hackathon" series by Richard Murby, Developer Evangelist (a.k.a. Ultimate Hackathon Expert) at ChallengePost.
The civic hacking movement is growing rapidly. Almost 50% percent of new hackathons on ChallengePost have a civic or open data component. I’m thrilled to see such an interest in this area, but it’s important that organizers design these events carefully.
In particular, I want to focus on the problem statement. A problem statement defines a particular motivation or issue like improving morning commutes or medical record portability. This is different from a theme which is often broader, e.g. transportation or public health.
While I always recommend hackathons have a single theme, I think it’s good to have a number of problems statements for attendees to work on.
A good problem statement has three key characteristics. It should be: clear, actionable, and linked to impact.
The best civic hacking problem statements clearly define what the issue is and any hard boundaries. However, they leave space for hackers to find their own solution.
Always remember that the goal of a hackathon isn’t a finished solution but a more refined approach toward solving the problem. If you host a hackathon just to get some work done on an idea, then you are missing the opportunity to create value.
By describing the problem rather than your desired solution, you’re enabling attendees to apply all their creative energy to finding a viable solution.
However, it is important that you combine a clear statement of the problem with an explanation of the operating environment the solution will have to be designed for. For example, what tools do the intended users have access to? It’s a waste of everyone’s time if a team creates an application for a smartphone if the potential user group only have access to feature phones.
Problem statements should be actionable in two ways:
Scope of work - The problem statement needs to be something that a small team can move the needle on over a weekend. This gives the team a specific goal, an opportunity to iterate on their solution, and a way to measure their progress. Broadly scoped statements can lead to false starts as the team figures out their approach and reduces hacking time.
Resources - If the problem requires access to some data (and it likely does), then you need to ensure it is open and readily accessible to the team. By accessible I mean that the team can quickly access it in a ‘raw’ format with all appropriate context included. Open means that there are as few restrictions as possible of the teams usage of the data. While most developers are extremely mindful of data security - mistakes can happen, so try not to include sensitive data. If you have any doubt about the sensitivity of the data, consider providing a ‘fake / training’ data set.
Linked to Impact
When I was organizing civic focused hackathons at the World Bank, I saw that the problems which received the most attention were those that had a passionate and vocal advocate in the room.
Developers care about building things that matter and nowhere is this more true than at civic hackathons. An advocate who wants to work with the output of a civic hackathon is a powerful draw for potential attendees.
These people are often the best source of knowledge and resources necessary to make the problem statements successful.
Putting it all together
If your problem statement reflects all three characteristics above, your attendees have a real shot at making a concrete contribution to your cause.
Consider pre-testing problem statements. Brainstorm and share with friends you know from other hackathons. Keep editing until you have something clear that resonates with your target audience.
I’ve seen hackathon organizers announce problem statements the day of their events and also share them in advance. My preference is for the latter. By sharing the problem statements in advance you give people time to research the ideas, get excited about the event, and form teams to work on particular issues.
Lastly, don’t forget the feedback loop. After the awards have been handed out, highlight the community’s work by showcasing & publicizing the results. Sharing pain and progress helps deepen the engagement of all stakeholders.
P.S. I’d love to hear examples of problems statements you’ve seen or worked on. Tweet at me or send me a note. If you’re ready to host your hackathon, get started now at post.challengepost.com/hackathons. It’s free!
April 1, 2014
Let’s be honest, we carry our lives on our smartphones and tablets. They store our favorite games, they show snapshots of who we are and what we love though the pictures and videos we capture, and they give us access to people, email, news, and sites that matter most to us. If you could connect these devices to larger displays to share your story with others, wouldn’t you? With the help of technologies such as MHL® and WirelessHD®, all of this is possible. Both of these standards, supported by Silicon Image and other major mobile and CE players, address the growing connectivity demands of consumers by delivering the ultimate interactive HD experience.
Connectivity That’s in “Charge”
MHL is a technology that simultaneously charges mobile devices and enables them to output high-definition video and digital audio to TVs and monitors. With MHL, your phone can be transformed into a gaming console, a fully functional portable office, a home theater system, and an auto infotainment hub. The MHL ecosystem continues to grow with more than half a billion MHL devices on the market today. MHL-enabled products include smartphones, tablets, DTVs, monitors, projectors, automotive accessories, A/V receivers, Blu-ray Disc™ players, and more.
Key features of MHL technology include brilliant color with up to 4K Ultra HD resolution, 8-channel surround sound, support for simultaneous multiple displays, and fast charging of up to 10W – with no lag, making it ideal for video and game applications.
Look Ma, No Wires!
WirelessHD is the first global 60 GHz technology for wireless connectivity. It supports high-definition video and delivers near-zero latency by avoiding Wi-Fi network interference. WirelessHD gives you a cable-quality connection without the wires. WirelessHD’s near zero latency capabilities are ideal for mobile gaming, entertainment, and multimedia.
What’s Your View?
Here’s where you come in. Silicon Image is sponsoring a contest for Android developers to build new dual screen experiences. The Dual Screen App Challenge promotes the creation of games, entertainment, and productivity applications that leverage MHL and WirelessHD.
Submissions will be accepted until July 21 and winners will be announced at GDC Europe (August 11th – 12th, 2014 in Cologne, Germany). Winners will take home $100,000 in cash prizes for developing the best, most compelling dual screen mobile games and applications.
So, are you up for the challenge?
March 28, 2014
This is the fourth post in the “How to Throw the Perfect Hackathon” series by Richard Murby, Developer Evangelist (a.k.a. Ultimate Hackathon Expert) at ChallengePost.
By now, you should be well on you way to holding an incredible hackathon. You’ve selected a powerful theme, got everyone on the same page, and cleared your way ahead of any legal trouble. It’s going to be a great event. Now you just need to find somewhere to host it.
Finding a hackathon venue can be incredibly simple for some and maddingly difficult for others. But just because you have access to an event space doesn’t mean it’s the right one.
What Does A Venue Need?
This is the single most important aspect of selecting a venue. Are your attendees going to be safe coming, staying, and leaving? Consider the hours your hackathon will be running. Some commercial areas are safe in the day but dangerous at night. Talking to building security can be a great way to find out.
What are the building hours? Will participants be able to come and go as they please without security badges? Some office buildings are on lockdown at night. Make sure guests don’t get locked in/out.
You’re going to need really good wifi. If this isn’t a space that has hosted multiple hackathons before, speak with network operations. Make sure they know the number of people who are coming and that they will need an average of two IP addresses each. Also check for blocked ports. Sometime this will be unavoidable. If so, make sure you have the numbers of all the ones that are blocked.
Make sure everyone can get access to power. Two sockets per person is ideal, but you can get away with one. If possible, check in with the building electrician before your event. You don’t want to blow the switch. (Trust me…)
- Practicality & Comfort
This is slightly more intangible. However, ask yourself if you would be happy to work in the space for an extended period. Think about the teams. Will they have a space to call their own? Where can they discuss ideas without disturbing everyone else? Beyond desks and tables, is there space where people can curl up in their favorite coding position or take a break and relax?
I’ve learned the hard way to also check what the building’s air-conditioning plan is. I’ve been in spaces where the AC was off on the weekends. It wasn’t very comfortable until we managed to get an engineer to come and help us.
Also consider if you’re going to allow people to stay overnight: Do you have a space for them to take a nap? I’ve recently seen some of the large college hackathons offer sleeping rooms and access to showers. Even if you can’t provide showers, make sure you have a plan to keep the bathrooms operating and clean.
You’re going to need to feed people at your hackathon. Some buildings don’t allow you to bring outside catering into the venue. While the internal suppliers may be great, this can push your costs up. Agree on a plan with the hosts ahead of time.
- X Factor
Having an incredible venue can be the thing that makes your hackathon stand out from the crowd. StartupBus is held — on a moving bus, the UnGrounded Hackathon took place on a plane. These events align themselves perfectly with their venues and the “where” becomes part of the whole event ethos.
Here in New York City, we’re spoilt with iconic venues. I’m pretty sure a hackathon held at the Statue of Liberty would be a big hit.
As I’ve noted before, hackathons are as much about the experience as anything else. A chance to hang out and work in a cool venue can draw a lot of people to your event. Just make sure it meets the criteria above.
How do you actually find a venue?
If you don’t have direct access to a suitable space, it’s best to create a short list. Start by looking at where other hackathons have been hosted. Often if you reach out to the organizers of those events they’ll be happy to share their experiences and make introductions.
Do expect to budget for a space in your planning. Even if the venue is donated, you should (at the very least) offer to pay for professional cleaning afterwards.
Co-working spaces are often great venues for hackathons. However, they are often busy so make sure you reach out early if your dates are not flexible.
Sometimes sponsors will offer to host the hackathon in their space. This can be a fantastic solution. However, you still need to make sure the venue meets all of the criteria above — if it isn’t a great fit, don’t feel bad to politely decline.
March 27, 2014
A guest blog post by Christine Keung, an Economics undergraduate at Wellesley College in Boston, Massachusetts. She’s the lead organizer of the Rosie @ Wellesley Hackathon, and is expected to graduate this May. Here, she takes us through how she leveraged the diverse student body at Wellesley to power a successful and inspiring event.
Hackathons channel the innate human need to create. The liberal arts education fosters the broad intellectual capacities that surround the creative process. Yet, hackathons at liberal arts institutions are still a rare occurrence, due to the stereotype of hackathons being engineer-dominated, or the assumption that students of the liberal arts have neither the skills nor the interest to participate.
This March, Wellesley College hosted its first ever 24-hour, company-sponsored hackathon. Wellesley is a liberal arts institution and a women’s college, and its students represent a broad range of ethnicities, races, sexual orientations, ages, and majors. We wanted to create an event that would encourage women and minorities to consider opportunities in technology, and to have participation that reflects the diversity on campus.
We were ultimately successful at attracting a wide range of students to our event, with participants representing over 15 different majors. The winning team, who created an improved version of Wellesley’s Free and For Sale website, included not only computer science majors, but also students studying Sociology, Political Science, Economics, Biology, and East Asian Studies.
When my team and I planned the Rosie @ Wellesley Hackathon, we made it a priority to dispel any stereotypes that could intimidate potential participants. We made three important decisions that helped our event be more inclusive and accessible:
- Find the Right Sponsors
RosieApp, a fast-growing Ithaca-based startup that allows users to purchase groceries online, has worked closely with Wellesley students since its early stages. They were familiar with our school’s curriculum, our culture, and the broad range of skills our students brought to the team.
Rosie’s entire team came down from Ithaca for the hackathon weekend to mentor participants in the technical aspects of the competition, and to provide guidance for the presentation and pitch elements. They held entrepreneurship workshops and panels, parted wisdom from real-life experiences working at early-stage startups, and shared business insight that can’t be taught in the classroom.
Because the Rosie team actually met at a hackathon, they were also dedicated to making sure that participants were collaborating effectively, and most importantly, having fun!
- Go Beyond the Hackathon
Being a liberal arts college, many of our participants had limited or no computer science experience. We wanted to expose them to some of the technologies commonly used in hackathons before the actual event. So with the support of the Computer Science department, we hosted a series of workshops on mobile development, web development, and APIs during the two weeks leading up to the hackathon.
It was a great way to advertise the event, and it created a risk-free environment where all students could learn something new.
- Encourage Collaboration
By setting loose guidelines (e.g. no cap on team size) and judging criteria that had both technical and presentation components, we encouraged students to build interdisciplinary teams.
We hoped teams would include both experienced and beginner programmers, and that this would provide a positive learning experience for those with no technical backgrounds. We asked students to brainstorm and form teams on a shared spreadsheet before the event, and even allowed them to begin working on their projects before the hackathon. By making collaboration a key component to the event, we were able to attract teams composed not only of computer scientists, but also including political scientists, linguists, and economists.
Many hackathons aim to attract primarily software engineers, and their attendance thus reflect a lack of diversity in educational background, gender, race, age, and sponsorship. This not only restricts the number of students who are enriched and empowered by participating in a hackathon, but also limits the potential and impact of what is created.
By inviting liberal arts students to participate, we help foster creativity and innovation.
At the end of the day, hackathons are about bringing passionate individuals together to generate ideas, and any lack of diversity in attendance is a missed opportunity for inspiration.
More on the Rosie @ Wellesley Hackathon:
Event photos [Rosie @ Wellesley Facebook page]
Hacks presented [ChallengePost]
You’re invited to sign up to hear about the latest software competitions & hackathons on ChallengePost. If you’re interested in hosting a hackathon for free, get started now at post.challengepost.com/hackathons.
- Find the Right Sponsors