IMS Weekend Hackathon
I had the unique privilege to participate in an Investor Management Services (IMS) weekend hackathon. IMS is a Charlotte-based company that makes software for commercial real estate owners to manage investors and assets. Their development team expanded the Contacts portion of their real estate software platform, also called IMS.
As an aspiring product manager, they invited me to participate in their hackathon and observe their development process.
What’s a hackathon?
It’s an intense period of rapid software development with a particular focus. In this case, the IMS developers expanded the Contacts section of their application, in a single weekend.
IMS business stakeholders asked their team for a robust CRM, to store information about investors, their clients, and investment preferences.
The design team created a prototype based on business and customer requirements. The development team committed to a tight deadline. They decided a weekend hackathon was the best (and fun) format to accomplish the goal.
The hackathon team was 8 developers, 1 designer, and me, as the task organizer, and quasi-product manager.
This team impressed me. They were cohesive, focused, and highly proficient. I bet many companies would be jealous of this team’s effectiveness. And I don’t know many teams that would volunteer a full weekend, between two full work weeks, to advance their company’s product. I admired that.
Day 0 — Business goal
The business presented their goal: include a robust CRM into the IMS platform. This was the Spring Planning Scrum event.
Business showed the designer’s Invision prototype. We had a chance to ask clarifying questions. Everyone agreed what was doable, or outside what could get done in a 3-day weekend hackathon.
Day 1 — Planning and Broad Brush Strokes
Before writing any code, we planned with sticky notes and whiteboards. We made a Kanban board.
A Kanban board is a seemingly simple, but highly effective visual to-do list. There are three sections: To-do, Doing, Done. “To-do’s” are everything that needs to get done. This was our Sprint Backlog. “Doing” is the single task you’re working on. “Done” are the completed tasks.
We separated the Contacts section into 5 areas. We broke down each area’s features. Each feature went on the Kanban board as a sticky note. Then developers self-assigned themselves features.
After this initial planning, or Backlog Refinement in Scrum, the anxious developers began coding with clear direction.
Day 1 was about applying broad brush strokes — completing the big and easy features. The team created the 5 Contacts sections. They added all the visual parts, like the forms and tables. They organized database changes. This was the foundation for the more complicated features.
Day 2 — Tons of Programming
We started early on Day 2. With the 5 major sections created, the effort was filling in details. The team began working on the big list of “To-do” tasks on the Kanban board.
The neat thing about Scrum is that developers self-assign their own tasks. Tasks are not delegated. Naturally, developers pick the tasks that fit their strengths, but there are no hard rules about who does what.
I credit IMS’s developers for being truly full-stack developers. This means any developer can work on a front-end or back-end task. Yes, each had their preferences, like databases, logic, interfaces, etc., but full-stack means you can do any task to advance the product forward to meet the deadline.
The developers made a lot of progress on Day 2. I updated the Kanban board. I added new sticky notes as new tasks came up. I made sure they didn’t have road blocks. I coordinated when tasks overlapped.
As developers completed tasks, we physically (and with much gratification) moved their own sticky notes to the “Done” section.
Day 3 — Front-end meets back-end
Most features were present in the application at the beginning of Day 3. The next step was “wiring up” features. This meant connecting the front-end user interface to the back-end database. For example, we had a form to “Add a Note”, so the task was to connect the note fields to actually save into the database.
The developers also spent time on the edge-cases. These are less common areas of the application, or situations, that users may find themselves. For example, what happens if you “Add a Note”, enable a followup reminder, then edit the note, and remove the reminder. The database needs to properly reflect all those changes.
Day 3 had lots of peer programming and code reviews. This is when two or more developers work together to program, or review, code. These are effective methods that make for strong products. And they’re necessary when “wiring up” and validating features.
Presentation Results — Success!
At the end of Day 3, we presented the new IMS Contacts section to business. This is Sprint Review in Scrum. It’s a celebration of working software and hard work. We demonstrated the new features, what we accomplished, and the tasks that were unfinished.
Business considered it a success! We built a working Contacts section. And we all felt really cool.
Testing. Just because the software worked in a business demonstration, doesn’t mean it’s ready for production. IMS takes testing seriously. Some developers wrote and adjusted test scripts, as they completed coding tasks.
The next step is to continue testing. The developers will pass the codebase to their quality assurance (QA) team for rigorous end-to-end testing.
What we learned
We all appreciated the sticky notes and Kanban board over a traditional software ticketing system like Jira. The focus was on programming and forward progress, over maintaining tickets and statuses.
We did lose digital (remote) visibility and tracking history with our Kanban board. It’s a physical tool and only visible in person, but the huge momentum of new features and working software made up for that.
The team estimated the 3-day hackathon accomplished what would have taken 2–3 weeks of regular office hours. Why? Because they were completely focused on the single Contacts section, without the distraction of meetings, tracking tickets, bug fixes on existing software, etc.
We all learned that hackathons are fun! And they’re a lot of work.
The team was there because they wanted to be. It was great to work alongside a passionate group committed to their product. Plus, there was plenty of coffee, beer, La Croix, pizza, chicken wings, donuts, and snacks. We even had awesome hackathon tank-tops.
What I learned
I gained experience seeing front-end and back-end components came together. At times, the team operated separately. Then, they came together to “wire-up” features. This was really interesting because my experience focuses on front-end development. I learned how these two parts of an application communicate.
I saw how truly capable the IMS team was as full-stack developers. The team members seamlessly changed between front-end and back-end tasks. I was impressed how they self-assigned tasks. I liked how they took tasks because they needed to get done, independent of their individual strengths.
Finally, I learned a lot about Agile and Scrum. I have a good textbook understanding, but true understanding comes from a real project.
Thank you IMS
I’m grateful that IMS invited me to participate in their hackathon. IMS is doing their part to foster technology in Charlotte. They support people like me, and their own developers, with these unique opportunities to grow.
Who is IMS?
Investor Management Services (IMS) is a Charlotte-based company that makes software solutions for commercial real estate owners to manage investors and assets. IMS is a subsidiary of QuietStream Financial (QSF), who owns a portfolio of companies that serve commercial real estate owners, investors, borrowers, and related professionals.