Our Smart Approach to Software Development

At Legal Innovation Lab Wales, we may be a small team, but we're making significant strides in software development by working efficiently and intelligently.

Our approach is inspired by "Getting Real," a methodology used by Basecamp. While we don't strictly adhere to the book's methodology, we embrace its core principles.

  • Our primary focus is on developing prototypes that serve as proof of concepts to address specific problems. These prototypes are designed to be simple and laser-focused on solving particular challenges. We're not aiming to create the next Facebook or Amazon; instead, we're engineering innovative solutions tailored to the needs of our users. This approach allows us to rapidly build and iterate, sidestepping unnecessary complexity and reducing the cost of change.

  • You might wonder why we don't adopt the Agile methodology. While Agile works well for many, it involves continuous two-week sprints and predefined feature sets. We prefer simplicity—both in our code and our processes. Agile can sometimes feel like a relentless conveyor belt, whereas we believe in pausing to ensure the quality of our work.

  • Before diving further into our approach, it's important to note that this isn't a declaration that our way is the best or the only way. Our approach may not suit everyone or every project. Flexibility and adaptability are key, and we tailor our methodology to each project's unique needs.

Our Approach Explained

Planning

Our journey starts with planning. Collaborating closely with stakeholders, we outline their ideas, identify the problems they aim to solve, and suggest engineering solutions. Collaboration and conversation are the cornerstones of this planning phase. We prioritise requirements, often using the MoSCoW method, to determine which features to focus on initially.

MoSCoW is a prioritisation technique used in project management and software development to categorise and prioritise requirements or features based on their importance. The acronym "MoSCoW" stands for:

  1. Must-Have: These are the critical requirements or features that are essential for the project's success. They represent the core functionality that must be delivered for the project to be considered complete. Without these, the project would likely fail to meet its objectives.

  2. Should-Have: These are important requirements or features that are not as critical as "Must-Have" items but are still necessary for a successful project. They contribute significantly to the project's value and functionality. "Should-Have" items are implemented after addressing the "Must-Have" requirements.

  3. Could-Have: These are desirable requirements or features that would be nice to have if resources and time permit. They are not critical to the project's core functionality but can enhance the user experience or provide additional benefits. "Could-Have" items are considered after addressing both "Must-Have" and "Should-Have" requirements.

  4. Won't-Have (or Would-Have-But-Not-This-Time): These are requirements or features that are explicitly identified as not being part of the current project scope. They are deferred to future phases or projects. While they may have value, they are intentionally excluded to maintain project focus and prioritise essential elements.

The MoSCoW method helps project teams and stakeholders make informed decisions about what should be included in the project and what can be deferred or omitted. It provides clarity on priorities and ensures that the most critical aspects are addressed first, reducing the risk of scope creep and project delays.

Development

With the plan in place, we embark on a 6-week development cycle, constructing the identified features. We begin with Entity-Relationship Diagrams (ERDs) to inform the backend design. We choose an appropriate framework (often Ruby on Rails) to build upon. Collaboration continues as we work on different aspects of the project in parallel, periodically consulting stakeholders for input.

We emphasise quality, aiming for extensible and maintainable code. We'd rather invest time in building fewer features exceptionally well than rush through many. Our philosophy: "Build Something Beautiful," applies to both user interfaces and code. An elegant front end is easier to test, and clean, well-formatted code is simpler to debug.

The Project Lifecycle

Our work follows a structured project lifecycle:

  1. Idea Generation: A need is identified, and an idea for a solution is formed. Ideas come from various stakeholders: Our Team, the School of Law, Business Partners, or the wider community. During this phase, we answer the Five Ws (Who, What, Where, When, Why) about the idea and gather background information.

  2. Feature Definition: What does your idea need to do? We create an initial list of features required. Our development team collaborates with you to refine this list.

  3. Estimation: For each feature, the development team estimates technical complexity and project duration.

  4. Prototype Development: We build and test a prototype, following a 6-week development cycle with incremental steps, reviews, and testing.

  5. Testing & Launch: Once the team is satisfied with the prototype, we showcase it to stakeholders.

Our approach focuses on building something functional, elegant, and efficient. If you believe our approach can benefit your project, don't hesitate to reach out!

The Five Ws for Project Ideas

In the journey of developing new products or services, understanding the "Five Ws" is essential. These questions dig deeper into initial ideas, helping shape them effectively:

  1. Who: Who faces this problem? Is it widespread, and is there sufficient evidence of the problem?

  2. What: What problem does it address? What need does the solution serve?

  3. When: When do people encounter this problem, and in what context? When would they use a solution?

  4. Where: Where would they use it? On a phone, computer, on the go, or in a courtroom?

  5. Why: Why would someone use this proposed solution? Does it improve existing ideas or processes? How does it outperform off-the-shelf alternatives?