CANA's Software Development Methodology

By Joe Moreno

The first time you do it, it’s a hack.

The second time you do it, it’s a trick.

The third time you do it, it’s a best practice.

CANA has developed an ideal modern approach to software development called CANABAN that’s perfect for project-based, budget-driven organizations. CANABAN’s 11 steps melds the best of Agile/Scrum and Kanban with project management’s best practices. We’ve successfully applied our CANABAN process to both product development and custom software for commercial and government clients, enabling effective asynchronous collaboration across a fully remote workforce spanning from Maine to Hawaii.

Waterfall is the first, formalized software development process going back to the 1950s. Waterfall is a linear process where work flows in fixed stages, typically Requirements → Design → Implementation → Testing → Deployment → Maintenance before returning back to the first step. This is similar to how large-scale physical systems were developed. Think: Mercury, Gemini, and Apollo space programs. It was inherently a bad idea to change something during, say, the implementation stage that wasn’t incorporated into the requirements or design stage when building physical systems. However, over time, it was noticed that moving electrons, as is done in software development, is much more flexible and forgiving than moving atoms when creating interoperable systems. That led to the development of a range of Agile software development methodologies. While Waterfall is linear, Agile is iterative and adaptive, with frequent feedback, incremental delivery, and automated testing. Waterfall treats software development steps as discrete events, while Agile treats them as a continuous process.

The rise of the World Wide Web in the early 1990s created a demand for many software engineers searching for the best way to develop and deliver software. In 2001, the Agile Manifesto was published with a focus on four key values:

1. Individuals and interactions over processes and tools.

2. Working software over comprehensive documentation.

3. Customer collaboration over contract negotiation.

4. Responding to change over following a plan.

Not only was software development changing rapidly in the 1990s and 2000s, but so was software deployment especially with the advent of cloud computing in 2006. 

Today’s Two Leading Software Development Methodologies 

The two leading Agile software development methodologies in use today are Scrum and Kanban. Scrum is known for its timeboxed iteration periods of software development called Sprints. Kanban is known for the exact opposite, continuous flow and incremental improvement without fixed iterations.

Scrum originated before cloud servers, when deploying software was a major undertaking handled by system administrators. Each software release had to be fully packaged and production-ready, much like shrink-wrapped software distributed on disks or CD/DVD-ROMs.

Cloud computing made deploying software to servers much easier by enabling automation in a process now known as Development/Operations (DevOps). Developers could simply check their code into a software repository which kicked off an automated build of the final product for testing and deployment. 

While Scrum was a fast and iterative process, DevOps removed the need to tie deployments to fixed dates and times. Instead, as soon as a new feature was completed, it could be deployed into production. With DevOps, Developers and Operations Engineers (system administrators) could now work on the same team, or even be the same people. The old days of packaging software with a specific version number were gone when it came to deploying software on a server. In other words, Scrum works nicely for client software running on an individual’s computer (such as an updated operating system or web browser version); whereas software running on a server could be deployed multiple times in a day or week. We are familiar with different versions of Windows or macOS running on our computers such as Windows 11 24H2 or macOS Tahoe 26.2. But we don’t think of different versions of Facebook or X.com since updates can be deployed at any time. For example, Facebook typically deploys new code with bug fixes and new features three times per business day (morning, afternoon, and evening).

CANABAN: The CANA Secret to Software Development

The software challenge faced at CANA is that we are a matrixed organization. Our team members will work on multiple projects throughout the month so they are matrixed into different teams while working remotely and as asynchronously as possible. This allows us to share resources across multiple projects by giving everyone at the company monthly project time allocations. One person might spend 80 hours on Project A and another 80 hours on Project B; meanwhile, another person might spend 40 hours working on four different projects throughout the month. 

So how do we ensure everyone is working as quickly as possible while keeping our developers, Project Managers (PMs), and Subject Matter Experts (SMEs) all in sync, on time, and within budget while maintaining expectations at every step? That’s where CANA’s 11 steps of CANABAN solved this challenge. 

CANA’s CANABAN combines the best of Scrum with Kanban using Jira as the PM tool.

1. Backlog: Anyone on a project can add issues to the backlog, such as new feature requests, bugs, tasks, user stories, etc.

2. SME Prep: “Definition of Done” – Subject Matter Experts/Project Leads, through discussions with software developers, add details and clarification to each Jira issue with the goal of providing minimal future guidance. User interface (UI) mockups are ideal tools for conveying a feature’s intended behavior and user experience (UX).

3. Needs Estimate: Software developers, through discussions with the SMEs, estimate how long it will take for a developer to complete and component-test a Jira issue along with creating end-to-end tests scripts. Software developer estimates are exclusive of administrative overhead such as meetings, rework, SLA, etc. Additional administrative overhead estimation is the responsibility of the Project Manager. Ideally, estimates should be generated by the developer who will be coding the tasks. Estimates older than one month should be revisited and updated if necessary. 

4. Estimated: The software developer will transition a Jira issue to Estimated once they have estimated a Jira issue.

5. Funded: The Project Lead evaluates which of the estimated tasks can be completed within the allocated budget of time, money, and resources available (e.g. quarterly, etc.). Funded tasks are prioritized by the Project Lead and assigned a Label tag for the month’s targeted completion.

6. To Do (with month’s due date): The Project Lead will transition tasks targeting the upcoming/current month from Funded to To Do in order to prioritize software developer efforts and update the Label with the targeted month.

“If blocked then get ahead”: If a software developer with remaining allocated hours has completed all planned Jira issues for the current month, or they are blocked from transitioning any of their other active Jira issues, they should choose a Jira issue that’s most likely to target the following month and transition it to the To Do status. When doing this, they will update the month’s due date to the following month so PMs/PLs/SMEs recognize that this Jira issue was not required to be completed in the current month.

7. In Progress: Software developers will transition Jira issues they are actively working on from To Do to In Progress. 

8. Demo Ready: Software developers will transition a Jira issue from In Progress to Demo Ready when they are prepared to review it with the SME or Project Lead. Additionally, the software developers will write end-to-end test scripts using the Cypress framework. Over time, all of these test scripts are collected and automatically run when deploying into production, creating a growing suite of regression tests.

9. In Testing: The Tester, typically a Subject Matter Expert (SME) or Project Lead, will conduct a comprehensive assessment of a Jira issue in a testing environment to ensure it functions effectively and aligns with the overall needs, scope, and integrity of the product.

10. Done: The Tester will transition a Jira issue to Done once they have validated that it meets the definition of done. Trivial work (enhancements, adjustments, or changes) may be negotiated based on resource availability. Non-trivial work may require reprioritization of incomplete Jira issues or a new Jira issue added to the appropriate workflow step (i.e. Backlog, SME Prep, Needs Estimate, Estimated, or Funded).

11. Accepted: The Product Owner transitions the Jira issue from Done to Accepted once they certify that it meets the needs of the broader business or user requirements and is ready for release or deployment. This is the final step in the workflow, as the task has passed all stages, including both development and formal approval, ensuring alignment with business needs.

CANABAN is more than just a set of steps; it's CANA's proven secret to effectively managing a matrixed, remote workforce within budget. By combining the best of Scrum's structure and Kanban's continuous flow, CANABAN ensures that developers, Project Managers, and Subject Matter Experts stay in sync, delivering value efficiently and consistently from the backlog all the way to customer acceptance. CANABAN embodies the CANA culture by creating an environment that allows our Team and Clients more time to focus on the things that matter most.

About

Joe Moreno is the Director of Software Development at CANA, LLC. He cut his software development teeth while working as a software engineer at Apple Inc. during the Steve Jobs era.