• Home
  • News and Updates
  • Hack-a-thon Provides Lessons Learned for Refining the Delivery Process while Improving Quality

Hack-a-thon Provides Lessons Learned for Refining the Delivery Process while Improving Quality

In the age of ever-changing requirements, system complexities, and high customer demand, software development and delivery professionals find themselves in the cross hairs of expectation. Agencies have the daunting task of keeping their constituency satisfied by providing features that help them accomplish their goals. This need underscores why there is urgency to find ways of accelerating delivery. Along the way, much of this conversation is exacerbated by teams adopting Agile and promoting an MVP as the sole way of responding this need.

As a community of IT professionals and federal employees in the government IT industry, we know this is not enough. Understanding the true benefits of Agile, DevOps and CI/CD is critical to success. Speed to market and Minimum Marketable Product vs. an MVP supports the need to keep the constituents satisfied and productive. Continuous delivery allows Agile to be implemented as smaller and more manageable releases; this is acceptable if releases can be implemented at a rate that does not slow overall progress of a project. Refining the process of delivery while improving the quality of the product is the key to success and is supported by the culture of DevOps using feedback loops.

We used our hack-a-thon as a vehicle to demonstrate this capability. We created an environment where teams were to modify a product and deliver it to production in 6 hours. The teams were given 17 tasks that were scored and given a prebuilt pipeline. We also included judges that have federal mission/operations experience to provide a diverse perspective. The teams were given the previous night to configure and test their environment. On the day of the hack-a-thon, each team was given an area and user stories, and they began coding to meet the deadline. The process was similar to a demo or challenge that has become more frequently used to differentiate vendor capability during the procurement process. We created this environment to demonstrate and learn from the process to see how we could improve rapid delivery concepts and provide feedback for the demo/challenge process.

At the end of the day we convened for our retrospective and shared our thoughts with each other about how the day went. A few notable items for feedback include the following.

  • Scrum Master: It was evident that in a rapid pace with significant time constraints, the approach was as large of a factor as the implementation. Teams had just minutes to determine if a story was too large or if a story was not clear. The scrum master became a critical component of strategist and scheduler in an effort to maximize the coding time for the developers.
  • Pipeline: We made a decision to ensure that there was a pipeline established in advance. This actually contributed to a better product and a better experience. We did encounter a few issues during setup, but they were quickly solved. Our teams spent more time on providing the solution, which underscored the criticality of the pipeline and provided the opportunity to demonstrate the skill of the team. Strong delivery teams have a problem-solving mentality. By providing challenges that teams tackle together and limiting factors that inhibit the time spent on solution, we can train and vet talent appropriately.
  • Tech Stack: The stack was chosen for the teams. In this instance we chose a simple stack of Node.js and Angular 5 with a Postgres RDS in AWS. However, it was interesting to see that each team still had an adjustment period to setup their environments and manage code delivery based on the level of familiarity with the stack.
  • User Stories/Problem: There was considerable feedback on user stories. User stories with acceptance criteria or a problem set that was clear and defined made a difference. Six hours is a very short time in the world of software development. Each module must have defined stories, acceptance criteria, testing framework, testing scripts, time for solution sessions, developing, testing, acceptance and deploying. The expectation should be that velocity will increase over time, but the initial iterations will be focused on ensuring an understanding of what is to be delivered.
  • Team/Collaboration: In our review, there was a one-to-one correlation between the team that had high levels of collaboration and a clear strategy on how to move forward as a team; the scrum master and the product owner were as involved with the solution as they were with the building the product roadmap. The cross-functional nature of the team provided the agility needed to deliver more tasks at a rapid pace. One note, is that teams were assigned. We wanted to see how the teams would react to each other as new team members. One team actually held an icebreaker and named their team shortly after the start. It is no surprise that the same team demonstrated strong collaboration and the ability to be nimble.
  • Epics: We intentionally created larger stories/epics to review the teams’ ability to decompose. Consistently we saw that given a constraint of time and a lack of clarity to decompose some epics, teams chose to deliver part of the story or not deliver any of the story. From an agile sprint perspective, this is a common and acceptable practice. From a customer delivery perspective, we often find ourselves “behind” or deficient in some way when this happens. In a contractual relationship, the vendor often struggles with the concept of team, as the product owner is usually the customer and not a team member. In making choices on product development and MVP, the product owner as part of the team has the responsibility to determine how (and in what intervals) the product is released. Although we did not have this barrier during our hack-a-thon, we felt it was a notable impact to delivery to discuss.

It was fascinating to observe the teams collaborate and strategize on how to deliver tasks given the constrains of time, tech stack and team composition. We accomplished a great deal for learning and demonstrating some of the constraints to success with rapid delivery and demo environments. As the popularity for these types of challenges increase, it is very important for judges and evaluators to intentionally pick evaluation criteria that demonstrate agility, collaboration, and ingenuity. For example, the ability to decompose stories and deliver based on business value demonstrates that the team understands agility. Overall strategy to deliver shows a team’s understanding of how CI/CD intersects with agile practices. The pipeline and platform became somewhat insignificant as a factor for development; this provided more time to demonstrate a team’s ingenuity to discovering a solution and their process for delivery.