Insights

Chamonix was awarded the contract to develop and manage a mobile channel for an Australian government agency, aimed at improving the healthcare management experience for everyday Australians.

After a year of workshopping, development, testing, and remediation, the team successfully launched a national app that was well received by both the client and the public. In this post, we’ll explore our processes that led to this success, including important considerations for best practice application development.

Developing a successful mobile app comes with a good deal of responsibility, especially when destined to be in the hands of millions of people! But with the right processes and practices in place, it’s possible to create an app that not only meets client needs but also delivers a great user experience.

In this post, we’ll take a closer look at the development of a national app and the processes that led to its success. Specifically, we’ll examine three key practices that were instrumental in the development of the app:

Follow Design Practices and Process, they are there for a reason.

Throughout this project (including the very start) it was important to define and understand our ways of working, development processes and coding patterns.

At the start we established that the best approach and structure we could undertake for this project was to use/follow short one-week agile sprints. This was very beneficial to the success of this project as it allowed us to work and focus on very fine-grained work items/objectives, reflect frequently and improve as a team, and importantly it allowed us to work very closely with our client, ensuring everyone involved was able to deliver the best possible app!

Another important aspect for the success of this project was clearly defining our approach to development processes and patterns, not only defining but understanding and following them, and updating them as needed.

Working with your client.

Short one week sprint cycles allowed us to work very closely with our client. Having one-week sprints consisting of fine-grained work items meant we could easily reach out and discuss with the client’s cyber security, design, and infrastructure teams, and work through any blockers, or ambiguity that arose throughout the process. As a result of weekly sprints, we also had weekly planning, demo and retrospective sessions.

Weekly demos (weekly test releases after a few sprints too) would allow us to showcase all progress we had made towards the app, but more importantly allowed the client to see how their idea/concept had come to life, and how it would compare to their existing web-site counterpart.

Weekly planning meant working with our client to establish a clear picture of what was being worked on and allowed the client to incorporate feedback into the workflow based on the demo or build they were shown or given in the previous week. This also allowed the client to have an active role in what development was prioritized to account for any timeframe/timeline they were following.

Everyone Knows/Knowledge sharing.

One of the most important processes the team followed was ensuring that everyone had an understanding and knowledge across the project. This allowed two things; the team could easily focus and target specific areas/features as required and could remediate any bugs or issues as they were identified (and they sure did come up as a result of constant thorough testing), without being reliant, restricted or dependent to any single member of the team.
As a result of this, anyone could swiftly resolve bugs/issues for any feature developed without waiting for the initial developer of the feature and more importantly features could continue to be developed, preventing unnecessary context switching and complete focus on the task at hand.

In spirit with the project, the knowledge sharing was broken down to smaller fine-grained processes. This is primarily constructed from working closely with one another, two-person minimum code reviews, regular workshops, and documentation.  

The team would often be on a team’s call when working remotely or alongside one another when in the office. This encouraged and enabled the team to easily ask questions and partake in discussion as features were implemented and bugs were remediated. This would often lead to paired programming when creating complex solutions for challenging problems.

Two-person minimum code reviews was an approach used for quality assurance and knowledge sharing. This meant that any code (new or modified) would have to be looked at by at least two separate individuals (not involved with the code change itself), additionally there were not any review tasks created as part of the work item (feature/bug) and this would often encourage more than two people to look at and review changes to the codebase, enabling a mix of various team members having not just an understanding of what was being changed or implemented, but also enabled an understanding or insight into what was being changed and how something was being implemented. Regular workshops/ walkthroughs also occurred, where a developer of a couple of closely related features that potentially had additional complexities or obscurity such as the implementation of accessible features, deployment pipelines, and the card template system used within the medical history timeline. This allowed more in-depth discussion and expanding understandings into how things worked and any design/development considerations that occurred.

Finally, documentation was the other major process that occurred that enabled and aided knowledge sharing and a clean readable codebase that the entire team could understand. Everyone would include comments within the codebase for every method, function and service, as well as additional comments for any complex logic, design decision, implementation reasoning or anything else that would enable others (or themselves when revisiting) to understand what was happening. This would often be one of the first things someone would look for when reviewing code, if there weren’t comments good chance it wasn’t getting through to the main code base.

Additional documentation was created as part of the codebases wiki, to outline and provide better coverage for complex or obscure code, as well as establishing a clear process and convention for using templated code and modifying existing code.