diff --git a/README.md b/README.md index 592379c..9e32baf 100644 --- a/README.md +++ b/README.md @@ -1,54 +1,78 @@ + # Released Method -*The Released Method is a framework for overseeing the development of extensive software projects, aiming to deliver solutions promptly, within budget, and maintaining high quality.* +*The Released Method is a pragmatic, battle-tested framework for managing large-scale software projects. It’s designed to deliver results — on time, on budget, and with uncompromising quality.* + +--- ## Contents -* ### [Introduction](introduction.md) - Overview of the Method and its origins -* ### [Pillars](pillars.md) - Fundamental areas of the method -* ### [Systems](systems.md) - Essential systems utilised -* ### [Why?](why.md) - The rationale behind the model -* ### [Team](team-model.md) - The team structure + +- [Introduction](introduction.md) – Overview and origins of the Released Method +- [Pillars](pillars.md) – Core principles that guide the process +- [Systems](systems.md) – Key systems used to support delivery +- [Why?](why.md) – The rationale behind the method +- [Team](team-model.md) – Team structure and roles + +--- ## About the Method -Developed by Nick Beaugeard, with 20 years of leadership in software development teams, the Released Method is the culmination of his experience as a software architect and startup founder. His history includes: - -* Launch of Microsoft SMS Installer with ISU (2000) -* Launch of Bellerephon Desktop Deployment Service (2003) -* Launch of Dimension Data Dynamic Desktop Deployment (2005) - * Secured [3 Microsoft Partner Awards](https://www.computerworld.com.au/article/162101/dimension_data_awarded_three_microsoft_global_partner_awards_2006/) -* Launch of Dimension Data SLAM (2007) -* Launch of Community Engine (2008) -* Launch of HubOne Modern Practice (2010) - * ARN Software Developer of the Year Award - * AFR Top 100 Companies to Watch - * RedHerring 2011 Award -* Launch of HubOne Engine (2012) -* Launch of WorkflowMax PowerShell Library (2013) -* Launch of Scanned Document Manager (2014) -* Launch of H&R Block Training Portal (2015) -* Launch of Invicta Special Forces Management Tools (2016) -* Launch of CA Kairos (2017) - * ARN Software Developer of the Year Award -* Launch of CCH iFirm Document Manager (2018) - * Runner Up - ARN Software Developer of the Year Award -* Launch of Unblocked Platform (2019) -* Launch of World of Workflows (2023) - * Highly Commended - ARN Software Developer of the Year Award - -## Business Case -Utilising a proven, structured methodology, honed across numerous product cycles, ensures the application of lessons learned from developing millions of lines of tested code, preventing repeated learning for new projects. - -This approach leads to a project that: -* Achieves its Goals -* Cuts Costs -* Enhances Quality -* Minimises Risk -* Boosts Team Rhythm -* Improves Transparency -* Yields Commercial-Quality Outputs - -## Measure Yourself -To gauge your progress, visit the [Startup Checklist](startup-checklist.md). - + +The Released Method was created by **Nick Beaugeard**, drawing on two decades of experience leading high-performing software teams. As a software architect and founder, Nick has consistently delivered innovative products across enterprise, government, and startup sectors. + +### Key Milestones: + +- 🚀 *Microsoft SMS Installer with ISU* (2000) +- 🧠 *Bellerephon Desktop Deployment Service* (2003) +- 🏆 *Dimension Data Dynamic Desktop Deployment* (2005) + - [Three Microsoft Global Partner Awards](https://www.computerworld.com.au/article/162101/dimension_data_awarded_three_microsoft_global_partner_awards_2006/) +- 🔁 *SLAM – Software Lifecycle Automation Manager* (2007) +- 🌐 *Community Engine* (2008) +- 💼 *HubOne Modern Practice* (2010) + - ARN Software Developer of the Year + - AFR Top 100 Companies to Watch + - Red Herring 2011 Award +- ⚙️ *HubOne Engine* (2012) +- 🛠️ *WorkflowMax PowerShell Library* (2013) +- 📥 *Scanned Document Manager* (2014) +- 🎓 *H&R Block Training Portal* (2015) +- 🥷 *Invicta Special Forces Management Tools* (2016) +- 🔍 *CA Kairos* (2017) + - ARN Software Developer of the Year +- 📁 *CCH iFirm Document Manager* (2018) + - Runner-Up – ARN Software Developer of the Year +- 🔗 *Unblocked Platform* (2019) +- 🌍 *World of Workflows* (2023) + - Highly Commended – ARN Software Developer of the Year + +--- + +## The Business Case + +The Released Method applies structured, repeatable processes proven across dozens of product cycles and millions of lines of production code. It’s built to eliminate rework, cut through ambiguity, and get products to market faster — with less risk and more impact. + +### The Method Delivers: + +- 🎯 **Goal Alignment** – Stay focused on what matters +- 💸 **Cost Reduction** – Avoid waste and rework +- ✅ **Higher Quality** – Baked-in testing and QA from the start +- ⚠️ **Risk Mitigation** – Spot and solve issues early +- 🔁 **Stronger Team Rhythm** – Clear roles, steady cadence +- 👀 **Greater Transparency** – Track progress with confidence +- 🚢 **Commercial-Ready Output** – Not just code — real, shippable software + +--- + +## Measure Your Progress + +Wondering where you stand? Start with the [Startup Checklist](startup-checklist.md) to benchmark your team’s maturity. + +--- + ## Join the Journey -To contribute to the growth of the Released Method, start by reading the [Code of Conduct](CODE_OF_CONDUCT.md), then proceed to the [Contributing Guidelines](CONTRIBUTING.md). \ No newline at end of file + +Want to contribute to the evolution of the Released Method? + +Start here: + +1. Read the [Code of Conduct](CODE_OF_CONDUCT.md) +2. Review the [Contributing Guidelines](CONTRIBUTING.md) diff --git a/corporate.setup.md b/corporate.setup.md index eff72c1..42350f4 100644 --- a/corporate.setup.md +++ b/corporate.setup.md @@ -1,35 +1,104 @@ [Home](README.md) | [Why](why.md) | [Pillars](pillars.md) | [Systems](systems.md) | [Team](team-model.md) | [Corporate Setup](corporate-setup.md) # Corporate Setup -Establishing a corporate presence is a critical step in launching your business. This checklist outlines the essential tasks for setting up a single company, whether an LLC or PTY, which will engage in trading and hold all intellectual property. It is crucial to *seek professional advice* before proceeding, as the following steps are general in nature and may not encompass all specific needs. - -## Checklist -* [ ] **Choose a Company Name**: Select a unique and appropriate name for your company. -* [ ] **Register Your New Company**: Complete the legal formalities to officially form your company. -* [ ] **Open Bank Accounts**: Set up business banking accounts for financial transactions. -* [ ] **Register for Tax**: Ensure compliance with local tax regulations by registering your business. -* [ ] **Purchase and Implement Cloud Accounting Software**: Acquire accounting software for financial tracking and management. -* [ ] **Obtain a Domain Name**: Register a domain name that aligns with your company name. -* [ ] **Create a Website**: Develop a professional website detailing your company's information and offerings. -* [ ] **Create Email Addresses and Acquire a Cloud Commercial Email Platform**: Set up professional email accounts for your team. -* [ ] **Create a GitHub Repo**: Establish a repository for your software projects and code. -* [ ] **Create Required Cloud Accounts**: Set up necessary accounts for cloud services relevant to your business. -* [ ] **Decide Office Location**: Choose a physical location for your office, if necessary. -* [ ] **Create Basic Sales Kit**: Develop materials for your sales team, including brochures, presentations, and price lists. -* [ ] **Create Product Roadmap**: Outline the development timeline and milestones for your product(s). -* [ ] **Start Build**: Begin the development and building process of your product or service. -* [ ] **Start Selling**: Initiate marketing and sales efforts to promote and sell your product or service. - -## Extended Steps -* [ ] **Develop Branding and Marketing Strategies**: Create a strong brand identity and marketing plan to effectively reach your target audience. -* [ ] **Secure Business Insurance**: Obtain the necessary insurance to protect your company from various risks. -* [ ] **Implement Customer Relationship Management (CRM) System**: Set up a CRM system to manage customer interactions and data. -* [ ] **Hire Key Personnel**: Recruit essential staff for various roles in your organization. -* [ ] **Establish Company Policies and Procedures**: Develop clear policies and procedures to guide your team's operations. -* [ ] **Conduct Market Research**: Understand your industry, competitors, and customer needs through thorough research. -* [ ] **Develop a Financial Plan**: Create a detailed financial plan, including budgeting, forecasting, and funding strategies. -* [ ] **Establish Partnerships and Alliances**: Form strategic partnerships to enhance your business capabilities and reach. -* [ ] **Plan for Scalability**: Prepare strategies for scaling your business operations as you grow. -* [ ] **Set Up IT Infrastructure**: Ensure robust IT systems and networks are in place for efficient operations. -* [ ] **Compliance and Legal Checks**: Regularly review and adhere to legal and compliance requirements relevant to your business. -* [ ] **Engage in Continuous Learning and Development**: Invest in the ongoing learning and development of your team to keep skills sharp and up to date. \ No newline at end of file + +Getting your company structure right from the beginning avoids a mountain of legal, financial, and operational headaches later. This checklist assumes you’re setting up a single legal entity (LLC or Pty Ltd) to trade and hold IP. + +> 💡 **Warning:** This isn’t legal advice. Talk to an accountant and a lawyer. Shortcuts now will cost you down the track. + +--- + +## Core Setup Checklist + +* [ ] **Choose a Company Name** + Make it unique, available, and not embarrassing when said out loud. + +* [ ] **Register the Company** + Use a professional service or your accountant to set it up properly — this isn’t the time to DIY. + +* [ ] **Apply for ABN / ACN (or local equivalent)** + Essential for operating legally and getting paid. + +* [ ] **Register for Tax (GST, PAYG, etc.)** + Don’t mess around here — get this sorted early. + +* [ ] **Open a Business Bank Account** + Never mix personal and business funds. Ever. + +* [ ] **Buy a Domain Name** + Lock in your .com / .com.au and any variations that matter. + +* [ ] **Set Up Professional Email** + Use Google Workspace or Microsoft 365 — free Gmail is for amateurs. + +* [ ] **Get Cloud Accounting Software** + Xero, QuickBooks or similar. Your accountant should have a preference — go with that. + +* [ ] **Create a GitHub (or GitLab) Organisation** + Don’t wait until your code is all over the place. + +* [ ] **Set Up Core Cloud Accounts** + AWS, Azure, GCP — whatever you’re building on. Do it under the company, not your personal email. + +* [ ] **Create a Basic Website / Landing Page** + Doesn't have to be fancy — just a place to show you’re real. + +* [ ] **Decide on a Physical Office Setup (if any)** + Remote-first? Co-working? Hybrid? Figure it out and budget accordingly. + +* [ ] **Create a Starter Sales Kit** + One-pager, pitch deck, intro email template, and pricing doc — keep it lean but sharp. + +* [ ] **Write a Product Roadmap** + Doesn’t need to be a novel — just know what you’re building and why. + +* [ ] **Start Building** + Code, mockups, MVP — whatever "build" means for you, get on with it. + +* [ ] **Start Selling** + Don’t wait for perfection. Get your thing in front of real customers ASAP. + +--- + +## Extended Setup + +These aren’t "optional" — they just might not be day-one tasks. + +* [ ] **Branding and Positioning** + Logo, colour palette, tone of voice — get consistent, not cute. + +* [ ] **Marketing Strategy** + Who are you targeting? How are you reaching them? What’s the message? + +* [ ] **Business Insurance** + Public liability, professional indemnity, cyber — get a broker to help. + +* [ ] **CRM System** + Even a simple HubSpot or Notion setup is better than spreadsheets. + +* [ ] **Hire Foundational Team Members** + Don’t hire too early. But when you do, make sure they're mission-fit. + +* [ ] **Internal Policies and Procedures** + Keep it lightweight, but write down how things work as they scale. + +* [ ] **Market Research and Validation** + Talk to real users. Validate before you overbuild. + +* [ ] **Financial Model** + Build a forecast, set milestones, know your runway. + +* [ ] **Partnerships and Alliances** + Look for leverage — don’t try to do everything solo. + +* [ ] **Scalability Planning** + Think ahead: people, tech, systems. Avoid rebuilds mid-growth. + +* [ ] **IT Infrastructure and Security** + Use single sign-on, 2FA, password managers — basic hygiene. + +* [ ] **Compliance and Legal** + IP agreements, NDAs, terms of service, privacy policy — no excuses here. + +* [ ] **Learning and Development** + Build a culture of growth early. It’ll pay off. diff --git a/documentation.md b/documentation.md index 4325cba..2939244 100644 --- a/documentation.md +++ b/documentation.md @@ -1,33 +1,112 @@ [Home](README.md) | [Why](why.md) | **[Pillars](pillars.md)** | [Systems](systems.md) | [Team](team-model.md) # Documentation -Effective documentation is pivotal to the success of any project, especially in software development. It encompasses various elements, each aligning with different project phases, and collectively they ensure the project meets its objectives and is accessible to its intended audience. + +Documentation isn’t just a box-ticking exercise — it’s foundational to building, scaling, and supporting software that doesn’t fall apart under pressure. Good documentation brings clarity, reduces risk, accelerates onboarding, and improves long-term maintainability. This guide outlines the key types of documentation you should invest in at each stage of a software project. + +--- ## 1. Envisioning -Envisioning is the process of distilling complex goals into clear, concise statements. These statements should be memorable and repeatable, serving as guiding principles for the entire team. Effective envisioning statements set forth the purpose and anticipated impact of the product. For example: -> "Our product will enable seamless international travel by providing a secure, verifiable COVID-19 Vaccine passport." +Start with clarity. Envisioning is about boiling down ambition into simple, powerful statements that everyone on the team can rally around. These should be easy to remember, easy to repeat, and laser-focused on the end-user benefit. + +Examples: + +> "Enable seamless international travel through a secure, verifiable COVID-19 vaccine passport." +> "Help accountants reduce costs and delight clients with smart document automation." + +An effective vision is short, sharp, and motivating. If it doesn’t fit on a slide or get you excited, rewrite it. + +--- + +## 2. Architecture + +Your architecture sets the tone for everything else — get this wrong and you’ll be rebuilding in six months. Define the tech stack, design patterns, integration strategy, and architectural principles early. Focus on scalability, maintainability, performance, and security. Document: + +- Technology choices and rationale +- Core components and how they interact +- Integration points and boundaries +- Key design decisions and trade-offs + +--- + +## 3. Developer Documentation + +This is your dev team's bible. It should make it dead simple for internal and external developers to understand how things work, how to contribute, and how to stay aligned with standards. + +Include: + +- Coding conventions and code structure +- Branching strategy and pull request process +- CI/CD pipelines +- Deployment process and environments +- Testing frameworks and coverage expectations + +Good developer docs = faster onboarding + fewer stupid mistakes. + +--- -> "Our platform will empower accountants to save costs and enhance client satisfaction through efficient document management." +## 4. SDKs -Effective statements are concise, clear, and motivational, encapsulating the benefit to the end-user. +If external devs are building on top of your product, a polished SDK is non-negotiable. This isn’t just some API reference dump — make it easy for others to succeed. -## 2. Architectural -Like in physical construction, the foundation of software is its architecture. This involves establishing robust design principles and architectural guidelines that ensure the software is scalable, maintainable, and secure. This phase involves making critical decisions on technology stacks, design patterns, and system integrations. +An effective SDK should have: -## 3. Developer -Developer documentation is crucial for both internal and external developers. It should include guidelines on coding standards, source control management, pull request procedures, and automated build processes. This ensures consistency in development practices and eases the onboarding process for new team members. +- Well-documented APIs with examples +- Client libraries for common languages +- Authentication and usage instructions +- Sandbox/test environments +- Sample apps and “hello world” demos -## 4. SDK -Developing a Software Development Kit (SDK) is essential for facilitating external developers in integrating and building upon your software. The SDK should include comprehensive APIs, libraries, code samples, and clear documentation. +The goal is zero-friction adoption. -## 5. Implementation -Implementation documentation covers the practical aspects of deploying the software. This includes step-by-step guides for installation, configuration, and troubleshooting. It's vital for ensuring smooth deployment and operation of the software in different environments. +--- -## 6. Platforms and Release Management -This aspect of documentation focuses on the platforms supported by the software and the strategies for release management. It includes versioning, update policies, compatibility information, and release notes detailing new features, fixes, and improvements. +## 5. Implementation Documentation + +Think like a sysadmin. This documentation covers everything needed to install, configure, run, and troubleshoot your software in a real-world environment. + +Include: + +- Installation guides (automated and manual) +- Configuration options and templates +- Environment variables and secrets handling +- Common issues and how to fix them +- Upgrade/downgrade instructions + +Make it so clear that even a junior tech can follow it. + +--- + +## 6. Platforms & Release Management + +Track what you support, how you roll out changes, and what users can expect. Clear release documentation reduces support tickets and keeps customers happy. + +Cover: + +- Supported platforms (OS, browsers, hardware) +- Versioning policy (e.g. SemVer) +- Release notes (features, bug fixes, breaking changes) +- Update/rollback instructions +- EOL (end-of-life) policies + +--- ## 7. Documentation Quality Control -Quality control for documentation ensures accuracy, clarity, and usefulness. It involves regular reviews and updates to keep the documentation relevant and reliable. This process is key to maintaining the integrity and effectiveness of all documentation produced throughout the project's lifecycle. -Incorporating these pillars of documentation into a software project not only aids in the development process but also enhances the end-user experience and supports the long-term sustainability of the product. \ No newline at end of file +Docs go stale — fast. Set up a regular review cadence and assign ownership. Spelling mistakes and outdated steps kill trust. + +Quality control includes: + +- Peer reviews and style guides +- Doc versioning and change tracking +- Feedback loops from devs and users +- Automated link and code snippet testing +- Clear ownership for each section + +--- + +## Final Word + +Strong documentation makes everything easier — onboarding, scaling, debugging, selling, and supporting your product. Bake it into your process early. If your docs are an afterthought, so is your product. + diff --git a/glossary.md b/glossary.md index 59b343e..d46e9d4 100644 --- a/glossary.md +++ b/glossary.md @@ -2,11 +2,124 @@ # Glossary -## Burndown -A *burndown chart* visually represents the rate at which a team is completing tasks against the total effort required. It's a tool used in agile software development to track the progress of user stories (tasks or requirements) during each iteration. The chart typically shows the remaining work (often in terms of hours or story points) against time, providing a clear picture of whether the team is on track to complete the work in the given timeframe. +--- -## User Story -A *user story* is a short, simple description of a software feature from the perspective of the end user. User stories help to create a simplified description of a requirement and consist of three aspects: who (the user), what (the need or goal), and why (the benefit or value). They are a fundamental component in Agile and Scrum frameworks, acting as the primary unit of communication and planning, ensuring that development work focuses on user needs and value. +## Burndown +A *burndown chart* visually represents the team’s progress by showing how much work remains in a sprint or project over time. Commonly used in agile environments, it tracks user stories or tasks (often measured in hours or story points) against the sprint timeline to indicate whether the team is on pace to meet delivery goals. -## Iteration -An *iteration* in software development is a specific time frame during which a team works to complete a set number of user stories or tasks. It is a core concept in iterative development methodologies like Agile, where a project is divided into smaller segments with each segment being developed, tested, and reviewed in a repetitive cycle. Iterations are typically short (often 1-4 weeks) and aim to produce a working version of the product with each cycle, allowing for frequent reassessment and adaptation of the project goals and priorities. \ No newline at end of file +--- + +## User Story +A *user story* is a concise, user-centric description of a software feature or requirement. It typically follows the format: +**As a [user], I want [goal] so that [benefit]**. +User stories ensure work is focused on delivering value and are the foundation for planning, estimation, and discussion in agile sprints. + +--- + +## Iteration +An *iteration* (or sprint) is a fixed timebox (usually 1–4 weeks) during which the team delivers a working increment of software. Each iteration includes planning, development, testing, and review, enabling fast feedback and continuous improvement. + +--- + +## Quality Bar +The *quality bar* defines the criteria a feature or release must meet before being considered complete. It typically includes: +- All tasks closed +- No Sev 1 / Pri 1 bugs +- Completed testing and documentation +- Approval by the triage team +This ensures consistency, stability, and stakeholder confidence. + +--- + +## Triage +*Triage* is the process of reviewing, prioritising, and assigning bugs, tasks, and change requests. It ensures that high-priority work is addressed quickly, low-priority issues are logged for later, and nothing slips through the cracks. + +--- + +## Severity (Bug) +*Severity* indicates the **impact** of a bug on functionality: +- **Critical** – Breaks core functionality or causes data loss +- **Major** – High impact, with a workaround possible +- **Minor** – Low impact, mostly cosmetic or edge-case related + +--- + +## Priority (Bug) +*Priority* defines the **urgency** of fixing a bug relative to other work. Set during triage: +- **P1** – Immediate fix required +- **P2** – Fix in next sprint +- **P3** – Fix if time allows +- **Deferred** – Logged but not currently scheduled + +--- + +## Repro Steps +Short for *reproduction steps*, this refers to the detailed instructions necessary to consistently replicate a bug. A good repro includes: +- Preconditions +- Exact steps taken +- Expected vs actual result +Without this, bugs are harder to fix and verify. + +--- + +## Sprint +A *sprint* is a short, time-boxed iteration in agile development, usually 1–4 weeks. Each sprint includes planning, execution, review, and retrospective. The goal is to ship a working, tested increment of software by the end of each sprint. + +--- + +## MVP (Minimum Viable Product) +An *MVP* is the simplest version of a product that delivers value to early adopters. It’s built to validate assumptions, gather feedback, and test product-market fit without investing in full-scale development. + +--- + +## CI/CD +*Continuous Integration / Continuous Deployment* is a development practice that automates the building, testing, and deployment of code. +- **CI** ensures code is regularly merged and tested +- **CD** automates the release process for faster delivery + +--- + +## Static Code Analysis +Automated code review performed without executing the program. It detects syntax errors, coding standard violations, potential bugs, and security vulnerabilities — often as part of the quality bar process. + +--- + +## Code Coverage +A metric that measures the percentage of your source code tested by automated tests. While 100% coverage isn’t always practical, aiming for **80%+** helps ensure confidence in code stability. + +--- + +## Regression +A *regression* is a bug introduced by a change that breaks functionality that previously worked. Prevented through strong test coverage, automated test suites, and post-fix validation. + +--- + +## Release Authorization +The structured decision point before deploying to production. In the Released Method, this includes: +- Quality bar review +- Triage team approval +- Optional team-wide veto +It ensures releases are stable, intentional, and aligned. + +--- + +## Battlecard +A *battlecard* is a sales enablement tool. It summarises key talking points, competitive differentiators, objection handling tips, and product strengths — giving sales teams a fast reference during live calls and pitches. + +--- + +## Proposal Template +A standardised document that communicates your solution, pricing, scope, and value to prospects. It ensures professionalism and consistency in every sales engagement. + +--- + +## SDK (Software Development Kit) +An *SDK* includes APIs, libraries, tools, and documentation that help external developers build on or integrate with your platform. High-quality SDKs reduce support load and increase adoption. + +--- + +## Hustler / Hacker / Hipster +A popular trio representing the minimum viable founding team: +- **Hustler** – Drives sales, partnerships, business growth +- **Hacker** – Builds the product and manages tech +- **Hipster** – Crafts the user experience, branding, and design diff --git a/introduction.md b/introduction.md index 7ae9ffc..baf1807 100644 --- a/introduction.md +++ b/introduction.md @@ -2,28 +2,48 @@ # Introduction to the Released Method -Welcome to the Released Method, a comprehensive approach to managing and delivering large-scale software systems. Originating in the era of agile methodologies' emergence, the Released Method combines elements of various software development strategies. Its primary focus is to synergize the facets of a software product team, ensuring delivery of high-quality software that aligns with customer needs and expectations. +The **Released Method** is a pragmatic, real-world-tested approach to managing and delivering large-scale software systems. It was born during the rise of agile methodologies and blends the best of those practices with lessons learned from decades of hands-on experience. -The Released Method is not just about processes and technologies; it fundamentally relies on people. It necessitates a team equipped with both the technical skills relevant to their roles and strong communication abilities. This dual focus on expertise and collaboration is key to the method's effectiveness. +Unlike one-size-fits-all frameworks, the Released Method adapts to the scale, complexity, and structure of your software product team — while staying laser-focused on delivering value to customers. -Moreover, technology plays a crucial role. Although the method's creator has preferred technology stacks, the Released Method is versatile, adaptable to various technological combinations. For detailed technology requirements and recommendations, refer to the technology reference architecture. +--- -The diagram below illustrates the **People, Process, Technology** triangle, a model that emphasizes the importance of balancing these three elements in a project. The Released Method aims to achieve this balance by focusing on: +## What Sets It Apart -| Area | Investment | -|----------|----------------------------------------------------------------------------------------------| -| People | Utilizing an effective team model and ensuring all critical functions are competently staffed.| -| Process | Implementing the pillars of the Released Method to streamline and optimize processes. | -| Technology | Integrating comprehensive solutions to meet the system requirements of the method. | +The Released Method isn’t just about process. It rests on a three-part foundation: + +- **People** – Great software starts with great teams. This method depends on skilled, collaborative, cross-functional groups. +- **Process** – A flexible, lean framework built on proven agile principles, adapted for modern challenges. +- **Technology** – A practical, adaptable tech stack that evolves with the product. + +Each element must be invested in and balanced. Ignore one, and the whole thing topples. + +| Area | Investment | +|------------|----------------------------------------------------------------------------------------------| +| People | Hire and empower the right team, with all key roles filled by competent professionals. | +| Process | Implement the Released Method’s core pillars to drive focus, speed, and quality. | +| Technology | Use solid, scalable tools and platforms — no tech for tech’s sake. | ![PPP Triangle](img/people-process-technology.png) -## History of the Released Method +--- + +## Where It Came From + +The Released Method originated during the author’s time at Microsoft around the turn of the millennium — a time when the industry was shifting away from the rigid, misunderstood Waterfall method. + +Frustration with bloated, outdated processes gave rise to agile frameworks like Scrum and XP. While some of their early practices were radical, their underlying principles were sound. + +The Released Method builds on those foundations, refined and reworked to suit the scale, speed, and complexity of software development in the 2020s. + +--- -The Released Method's inception can be traced back to the author's experience at Microsoft around the millennium change. This period marked a pivotal shift in the software industry's approach, moving away from the traditional Waterfall Method, which was often misinterpreted from Dr. Winston W. Royce's concepts. The industry sought to rectify decades of misaligned process application, leading to the development of methodologies like Xtreme Programming, Scrum, and others. +## The Method in Practice -While some practices in these methodologies were considered unconventional, their core approach was largely on point. The Released Method is a refined iteration of these agile methodologies, tailored for the complexities and demands of the 2020s software development landscape. +This is not a rulebook — it’s a framework. The Released Method is: -## Approach of the Released Method +- **Principle-based** – Grounded in agile values, not ceremonies. +- **Flexible** – Designed to fit the real world, not an ideal one. +- **Outcome-driven** – Focused on delivery, quality, and user value. -The Released Method is the culmination of extensive experience in numerous software development projects. It offers a pragmatic, real-world-tested framework, embodying best practices in software development. This approach is not about rigidly adhering to a set of rules; instead, it's about understanding and applying agile principles in a way that makes sense for each unique project, ensuring flexibility, quality, and efficiency in software development processes. \ No newline at end of file +It’s shaped by years of hard-won lessons in shipping complex systems — and built to help teams navigate ambiguity, deliver with confidence, and scale without chaos. diff --git a/management-reporting.md b/management-reporting.md index 489c53d..0a16710 100644 --- a/management-reporting.md +++ b/management-reporting.md @@ -2,41 +2,67 @@ # Management Reporting -Management Reporting is a fundamental aspect of project oversight, providing crucial insights to management, investors, and executives about the project's progress and performance. It involves a range of metrics and indicators that collectively offer a comprehensive view of the project's health. +**Management reporting** is essential for tracking progress, anticipating issues, and communicating project health to stakeholders — whether that’s internal leadership, external investors, or delivery teams. Done right, it provides not just status updates, but actionable insight. -## Outcomes +--- -The key outcomes of management reporting include: +## Key Outcomes -* **Burndown**: A visual representation of the rate at which the team is completing user stories against the total effort. -* **Test and Regression Rates**: Indicators of the effectiveness of testing processes and the stability of the codebase. -* **Development Cadence**: A measure of the team's consistent pace in delivering increments of work. -* **Estimated Dates**: Projections for key milestones and deliverables. -* **Cost and Duration**: Financial metrics and timeline assessments of the project. +Management reporting should produce a clear picture of how the project is progressing. Core outputs include: -## How +- **Burndown** – Visualises how fast work is being completed versus total effort remaining. +- **Test & Regression Rates** – Reflects code stability and testing rigour over time. +- **Development Cadence** – Shows the team’s delivery rhythm and any variation. +- **Estimated Dates** – Forecasts for milestones and key deliverables. +- **Cost & Duration** – Tracks budget versus burn and projected completion time. -Management reporting typically involves a mix of detailed reports, graphs, and charts to convey information effectively. +--- -### Burndown +## How to Report -The burndown chart is an essential tool in agile project management. It illustrates the rate at which the team completes user stories in relation to the total effort required. Key insights from the burndown chart include: +The best reports combine numbers, visuals, and trends in a way that’s quick to grasp and hard to ignore. Use charts and concise commentary over spreadsheets full of noise. -- **Total Effort**: This is indicated on the left side of the chart. -- **Team's Velocity**: Shown on the right, this measures the work rate per iteration. -- **Iteration Work**: Work completed in each iteration. -- **Remaining Work**: The workload left to complete. -- **Completed Work**: Cumulative work done so far. -- **Expected Completion**: Projected timeline for completion based on current progress. +--- -A sample Burndown spreadsheet can be found [here](http://www.agilenutshell.com/assets/Sample-Burndown.xls). +### Burndown Charts -### Test and Regression Rates +Burndown charts are a staple of agile delivery — and for good reason. They offer a fast, intuitive view of progress over time. -Monitoring test and regression rates is crucial for maintaining quality. Key points include: +Key elements: -- **Increasing Test Rates**: As the project progresses, the number of tests should increase, identifying more bugs. -- **Zero-Bug Bounce**: A target where active bugs reduce to zero, meaning all known bugs have been addressed. -- **Regression Rates**: Monitoring regressions, where previously passing tests fail due to new changes, is vital. Low regression rates are indicative of stable, high-quality code. +- **Total Effort (Y-Axis)** – Work remaining, often measured in story points or hours. +- **Time (X-Axis)** – Iterations, sprints, or calendar days. +- **Velocity** – Average rate at which the team completes work. +- **Remaining vs Completed** – Visually shows if you’re on track or falling behind. +- **Projected Completion** – Based on current trend lines. -Effective management reporting in software development not only keeps stakeholders informed but also provides actionable insights for continual improvement of the development process. By closely monitoring these metrics, teams can make informed decisions, anticipate challenges, and maintain the momentum towards successful project completion. \ No newline at end of file +> ✅ **Tip:** Use a running average for velocity rather than a per-sprint measure to smooth out anomalies. + +📄 Sample burndown spreadsheet: [Download here](http://www.agilenutshell.com/assets/Sample-Burndown.xls) + +--- + +### Test & Regression Metrics + +Tracking test and regression metrics helps keep quality visible — not just a “dev problem.” + +Report on: + +- **Test Coverage Growth** – More tests over time = confidence in growing codebase. +- **Bug Trends** – Track open bugs, fix rates, and age of unresolved issues. +- **Zero-Bug Bounce** – A milestone where all known issues are cleared (if only briefly). +- **Regression Rate** – How often new changes break previously working features. Lower = healthier codebase. + +> 📉 High regression = tech debt or flaky tests. Either way, it’s a red flag. + +--- + +### Final Word + +Management reporting isn't about ticking boxes. It’s about maintaining visibility, enabling smart decisions, and catching issues early — before they derail timelines or blow budgets. + +Keep it: + +- **Focused** – Stick to what matters. +- **Honest** – Don’t sugar-coat or hide behind averages. +- **Regular** – Weekly is typical; fortnightly is the minimum. diff --git a/pillars.md b/pillars.md index 3e2eda3..62218c4 100644 --- a/pillars.md +++ b/pillars.md @@ -1,25 +1,51 @@ -[Home](README.md) | [Why](why.md) | **[Pillars](pillars.md)** | [Systems](systems.md) + +[Home](README.md) | [Why](why.md) | **[Pillars](pillars.md)** | [Systems](systems.md) # Pillars of the Released Process -The Released Process is founded on six essential pillars that guide the end-to-end development and management of software projects. Each pillar represents a critical aspect of the software lifecycle, from planning to sales, ensuring a comprehensive and effective approach to software delivery. +The **Released Process** is built on six core pillars that support the full lifecycle of software delivery — from initial planning through to commercial success. Each pillar addresses a critical dimension of what it takes to deliver great software at scale: strategy, execution, quality, release, clarity, and customer reach. + +--- + +## 1. [Management Reporting](management-reporting.md) + +Management reporting provides the visibility needed to steer a project with confidence. It tracks critical metrics like burndown, test coverage, regressions, cadence, cost, and delivery estimates. The goal is simple: deliver insights, not noise — and enable fast, informed decision-making at every level. + +--- + +## 2. [Software Planning and Development](software-planning.md) + +This is where ideas become reality. From defining scope and timelines to allocating resources and adopting agile practices, this pillar ensures development is aligned with business goals. It’s not just about writing code — it’s about delivering the right thing, the right way, at the right time. + +--- + +## 3. [Testing and Quality Assurance](testing-qa.md) + +Quality isn’t optional — it’s embedded. This pillar covers robust test frameworks, automation, CI/CD pipelines, and regression tracking. The aim is to catch issues early, ship confidently, and maintain high standards without slowing down delivery. + +--- + +## 4. [Release Management](release-management.md) + +This is where planning meets execution. Release management defines how software moves through environments — from dev to test to prod — with minimal risk and maximum control. It includes deployment strategies, versioning, environment control, and go-live readiness. + +--- + +## 5. [Documentation](documentation.md) + +Documentation underpins everything: onboarding, development, support, and adoption. This pillar covers technical guides, SDKs, install instructions, release notes, and user-facing content. Good documentation saves time, reduces friction, and increases product value. + +--- -## 1. Management Reporting -[Management Reporting](management-reporting.md) plays a pivotal role in providing insights into the project's progress. It involves tracking and reporting on key metrics like burndown rates, test and regression rates, development cadence, and estimated completion dates. Effective management reporting enables informed decision-making and ensures transparency across all levels of the project. +## 6. [Selling](sales-kit.md) -## 2. Software Planning and Development -[Software Planning and Development](software-planning.md) is the cornerstone of the process, where ideas are transformed into actionable plans and tangible products. This pillar encompasses defining project scopes, setting timelines, resource allocation, and adopting agile methodologies for iterative development. It ensures that development efforts align with business objectives and customer needs. +The final pillar ensures your software reaches the market and resonates. This includes sales kits, pricing models, positioning, customer targeting, and marketing assets. Selling isn’t a separate phase — it’s an integrated part of building something people want and are willing to pay for. -## 3. Testing and Quality Assurance -[Testing and Quality Assurance](testing-qa.md) focuses on maintaining the highest standards of software quality. This includes implementing robust testing frameworks, continuous integration and delivery (CI/CD) practices, and ensuring that every release meets stringent quality benchmarks. This pillar is crucial for identifying and rectifying defects early in the development cycle, thereby reducing risks and enhancing product reliability. +--- -## 4. Release Management -[Release Management](release-management.md) involves the strategies and processes used to manage, plan, schedule, and control a software build through different stages and environments. This includes deployment methodologies, version control, and ensuring seamless transitions between development, testing, and production environments. Effective release management ensures that software releases are reliable and delivered in a timely manner. +## Bringing It All Together -## 5. Documentation -[Documentation](documentation.md) is essential for providing clear and comprehensive information about the software. This pillar covers everything from technical documentation for developers to user manuals for end-users. Well-structured documentation is vital for supporting both the development process and the user experience, facilitating easier adoption and usage of the software. +These six pillars form a complete, battle-tested framework for managing modern software delivery. They're not standalone functions — they’re interdependent. Weakness in one affects the others. -## 6. Selling -[Selling](sales-kit.md) is the final pillar, encompassing the strategies and materials used to market and sell the software. This includes developing sales kits, marketing strategies, pricing models, and customer outreach programs. The selling process is crucial for ensuring that the software reaches its intended audience and achieves commercial success. +The Released Process brings them together in a structured, adaptable way — ensuring every product is not just built well, but delivered, adopted, and scaled successfully. -Together, these six pillars form the foundation of the Released Process, creating a robust framework for managing software projects from conception to market. Each pillar is interdependent and crucial for the overall success of the software, ensuring that projects are not only technically sound but also commercially viable and aligned with market needs. \ No newline at end of file diff --git a/release-management.md b/release-management.md index d36f4df..160aa6b 100644 --- a/release-management.md +++ b/release-management.md @@ -2,46 +2,101 @@ # Release Management -Release Management is a critical component of the Released Method, encompassing various processes and checks to ensure that each software release is robust, reliable, and meets quality standards. This pillar includes key elements such as Quality Bar, Automated Release Process, Staging and Production Platforms, Release Authorization, and Version Control. +**Release Management** is a critical pillar of the Released Method. It ensures every software release is reliable, production-ready, and aligned with quality expectations — without dragging delivery timelines or relying on luck. This pillar covers five core areas: + +- **Quality Bar** +- **Automated Release Process** +- **Staging and Production Environments** +- **Release Authorization** +- **Version Control** + +--- ## Quality Bar -The Quality Bar defines the criteria for determining when a product or release is ready for deployment. It balances the need for perfection with the practicality of meeting release deadlines. The Quality Bar is essential for guiding teams on when the software is sufficiently refined and tested to be considered "shippable". This criterion varies but typically includes measures like: -- Number of outstanding tasks. -- Number of outstanding bugs. -- Proportion of tasks tested. -- Proportion of tasks documented. +The **Quality Bar** defines what “ready to release” actually means. It provides a clear, objective threshold for when software is stable enough to ship — balancing quality with time-to-market. + +Your bar should be high, but realistic. Typical criteria include: + +- Remaining open tasks +- Open bug count and severity +- Percentage of features tested +- Percentage of features documented -Each task in a user story or feature undergoes various states from New (Unassigned) to Closed, ensuring comprehensive development, testing, and documentation. +Each feature/task progresses through tracked phases to ensure nothing is missed. -### Task Phases -- **New**: The task is proposed and awaiting approval. -- **In Development**: Once assigned, the developer iterates until the task reaches code completion. -- **In Test**: The task undergoes thorough testing. Bugs are identified and logged. Testing metrics, such as code coverage, are considered (see [Testing & QA](testing-qa.md)). -- **In Documentation**: Post-testing, the task moves to documentation, where its usage and functionalities are detailed. Documentation itself is tested for completeness and accuracy. -- **Closed**: The task is deemed complete, with ongoing bug resolution. +### Task Lifecycle + +- **New** – Proposed and awaiting triage or assignment +- **In Development** – Actively being built; iterated until code complete +- **In Test** – Undergoes validation, regression, and coverage checks (see [Testing & QA](testing-qa.md)) +- **In Documentation** – Features documented and docs tested for clarity and completeness +- **Closed** – Task fully delivered; ongoing bug fixes tracked separately ### Quality Bar Metrics -1. **All Tasks Closed**: Signifies the end of active development for the release. -2. **No Open Bugs**: Indicates that no critical bugs are pending for the current release. -3. **Punting**: Deciding to move a task to a subsequent release based on its severity and priority. -### Released Method Quality Bar -In the Released Method, the quality bar is defined by: -1. Completion of all tasks. -2. Absence of open Sev 1, Pri 1 Bugs. -3. Consensus from the Triage Team for release. +- ✅ **All tasks closed** – No active development pending +- 🐞 **No open Sev 1 / Pri 1 bugs** – Showstoppers are resolved or blocked +- 🚩 **Punting** – Deliberate deferral of tasks that no longer meet release scope or timing +- 👥 **Triage Team sign-off** – Final approval from the cross-functional release authority + +This gives you a shared, unambiguous definition of “done” at release scale. + +--- ## Automated Release Process -Implementing an automated release process streamlines deployment, reducing human error and enhancing efficiency. This involves automated builds, testing, and deployment scripts, ensuring consistent and reliable release cycles. -## Staging and Production Platforms -Separating staging and production environments is crucial for safe testing and deployment. Staging environments replicate production settings for final testing, while production environments host the live, user-facing application. +Manual deployments are slow, error-prone, and unsustainable. The Released Method mandates **automation by default** — from build to release. + +Automation should include: + +- Build pipelines (CI/CD) +- Automated tests (unit, integration, regression) +- Packaging and deployment scripts +- Environment validation checks + +Your goal is repeatable, reliable, hands-off releases. + +--- + +## Staging and Production Environments + +You ship with confidence when your testing environment mirrors the real world. That’s why the Released Method separates: + +- **Staging** – Mirrors production as closely as possible; used for final validation +- **Production** – The live, customer-facing environment + +Staging is not optional. It’s your last safety net. + +--- ## Release Authorization -Release authorization is a collaborative decision-making process, often involving a Triage Team. Any member can veto a release to address significant concerns, ensuring thorough review and consensus before deployment. + +Shipping software is a team sport. **Release authorization** is a structured process led by the Triage Team, which includes engineering, QA, product, and sometimes support or marketing. + +- Any member can veto a release based on serious concerns +- Final go/no-go is based on agreed Quality Bar metrics +- Releasing is a decision — not a default + +This ensures accountability without bureaucracy. + +--- ## Version Control -Effective version control is indispensable for managing changes in software development. It tracks modifications, supports concurrent work, and facilitates collaboration, ensuring a coherent and organized development process. -The Release Management pillar is fundamental in ensuring that each software version is released with confidence, meeting the high standards of quality and reliability that are hallmarks of the Released Method. \ No newline at end of file +Version control underpins all of this. It’s more than just source history — it’s the foundation for traceability, rollback, and collaboration. + +Your version control strategy should: + +- Support parallel development (branching model) +- Tie changes to tasks and bugs (issue tracking integration) +- Maintain clean release tags and history +- Be accessible to all team members, including QA and support + +Git is the standard. Use it well. + +--- + +## Final Word + +Release Management isn’t just a checkpoint at the end — it’s a continuous discipline. The Released Method bakes it in from day one to ensure every build is production-worthy, every release is predictable, and your customers never get a “rough edge” build again. diff --git a/sales-kit.md b/sales-kit.md index 8411774..cc4b7e1 100644 --- a/sales-kit.md +++ b/sales-kit.md @@ -1,36 +1,94 @@ [Home](README.md) | [Why](why.md) | [Pillars](pillars.md) | [Systems](systems.md) # Selling -The Selling pillar of the Released Method focuses on developing key materials and strategies to effectively market and sell the software product. This involves creating a comprehensive suite of sales tools designed to address different aspects of the sales process, from presentations to competitive analysis. -## Key Deliverables for Sales Process +The **Selling** pillar of the Released Method equips your team to effectively position, promote, and sell your software. It’s not just about flashy presentations — it’s about having the right tools and messaging to engage decision-makers, overcome objections, and close deals. -### Sales Presentations -[Sales Presentations](saleskit/sales-presentations.md) are essential tools for communicating the value proposition of the product to potential customers. Different lengths and depths are prepared to cater to various scenarios: - * **1 Slide**: A concise overview of the product, ideal for quick pitches. - * **3 Slide**: A brief presentation highlighting key features and benefits. - * **15 Slide**: A more detailed presentation, suitable for initial meetings with potential clients. - * **30 Slide**: An in-depth presentation covering all aspects of the product, designed for detailed discussions. +This pillar focuses on building a complete, repeatable sales kit that can scale with your business and adapt to different stages of the sales funnel. -### Proposal Template -[Proposal Template](saleskit/proposal-template.md) provides a standardized format for sales staff to present the solution to prospects, ensuring consistency and professionalism in sales proposals. +--- -### Brochure -[Brochure](saleskit/brochure.md) serves as a customer-facing document that offers an engaging summary of the product, its benefits, and uses. +## 🔑 Key Deliverables for the Sales Process -### DataSheet -[DataSheet](saleskit/datasheet.md) is a technical document that provides an in-depth view of the product's features, benefits, and specifications, catering to more technically-oriented clients. +Each of the following components plays a role in moving prospects from curiosity to commitment. -### Sales Battlecard -[Sales Battlecard](saleskit/sales-battlecard.md) is a quick-reference tool for sales and marketing personnel. It includes key talking points, product strengths, and unique selling propositions to effectively position the solution during discussions. +--- -### Competitive Analysis -[Competitive Analysis](saleskit/competitive-analysis.md) compares the product with its competitors, highlighting advantages and unique features to help the sales team position the product effectively in the market. +### 📊 [Sales Presentations](saleskit/sales-presentations.md) -### Pricing Matrix -[Pricing Matrix](saleskit/pricing-matrix.md) outlines the different pricing options for the solution, providing clear and flexible pricing structures for various customer needs. +These are your front-line tools for storytelling. Different versions are tailored for different audiences and scenarios: -### Web Site -[Web Site](saleskit/web-site.md) is a dedicated microsite or section of the company’s main website that provides comprehensive information about the product, including features, benefits, testimonials, and contact information. +- **1-Slide Pitch** – Sharp, bold, and fast. Ideal for elevator pitches or intro calls. +- **3-Slide Deck** – A quick but compelling overview for early-stage interest. +- **15-Slide Presentation** – Covers features, benefits, and use cases in detail — great for discovery sessions. +- **30-Slide Deep Dive** – Comprehensive product walkthrough for serious buyers or technical audiences. -These deliverables form the backbone of the Selling pillar, ensuring that the sales team is equipped with all necessary resources to effectively communicate the value of the software to prospects and customers. By carefully crafting each component, the Released Method enhances the likelihood of successful market penetration and sales growth. \ No newline at end of file +--- + +### 📝 [Proposal Template](saleskit/proposal-template.md) + +A standardised, professional format for presenting pricing, scope, and timelines. This keeps your proposals consistent, branded, and easy for prospects to digest and compare. + +--- + +### 📄 [Brochure](saleskit/brochure.md) + +Customer-facing marketing collateral that tells your product’s story — visually rich, benefits-focused, and easy to hand over at events, meetings, or digitally. + +--- + +### 🧾 [DataSheet](saleskit/datasheet.md) + +Technical buyers care about the details. The datasheet lays out features, specs, integrations, and system requirements — all in a format that builds trust and confidence. + +--- + +### 🥊 [Sales Battlecard](saleskit/sales-battlecard.md) + +A quick-hit reference guide for the sales team. Includes: + +- Key talking points +- Objection handling tips +- Unique selling propositions +- Competitive angles + +Helps reps stay sharp and focused in live conversations. + +--- + +### 🆚 [Competitive Analysis](saleskit/competitive-analysis.md) + +A structured comparison between your product and its key competitors. Highlights your strengths and key differentiators — helping the sales team position your solution confidently and tactically. + +--- + +### 💰 [Pricing Matrix](saleskit/pricing-matrix.md) + +Transparent, scalable pricing options. This tool lays out tiers, features, and licensing models clearly, so prospects can quickly see where they fit — and what value they’re getting. + +--- + +### 🌐 [Web Site](saleskit/web-site.md) + +A product-focused microsite or dedicated section of your main site. It includes: + +- Product overview +- Customer success stories +- Demo requests or trials +- Feature lists and FAQs +- Clear CTAs for conversion + +Your website is often your first salesperson — make it count. + +--- + +## Why It Matters + +Sales enablement isn’t optional — it’s what turns great products into successful businesses. The Selling pillar ensures your team isn’t improvising on calls or chasing down one-off assets. Everything’s packaged, polished, and ready to use. + +Done well, this leads to: + +- Faster sales cycles +- Higher conversion rates +- Better-qualified leads +- Stronger market positioning diff --git a/software-planning.md b/software-planning.md index 624b8e6..4e277cb 100644 --- a/software-planning.md +++ b/software-planning.md @@ -2,44 +2,112 @@ # Software Planning and Development -The Software Planning and Development pillar of the Released Method is structured around a cyclical lifecycle model that incorporates agile principles, focusing on iterative development and continuous improvement. This model is executed through a series of **sprints**, each delivering valuable, functional software that aligns with customer needs and adapts to changing requirements. +The **Software Planning and Development** pillar is the engine room of the Released Method. It follows a structured, agile-aligned lifecycle designed to ship working software at a consistent cadence — while staying flexible enough to respond to change. + +Built around iterative **sprints**, the process focuses on delivering functional, tested, and valuable software at every step. It promotes collaboration, innovation, and a relentless focus on the end-user. + +--- ## Agile Alignment -Adhering to the principles of the [Agile Manifesto](https://agilemanifesto.org/), the Released Method prioritizes customer satisfaction, embraces changing requirements, and emphasizes collaboration between business stakeholders and developers. The process is designed to maintain a sustainable pace, ensuring long-term project viability and technical excellence. + +The Released Method adheres to the principles of the [Agile Manifesto](https://agilemanifesto.org/) — valuing individuals, interactions, working software, customer collaboration, and responding to change. + +It aims to: + +- Prioritise customer outcomes +- Embrace evolving requirements +- Sustain a consistent, manageable delivery pace +- Foster tight alignment between business and development teams + +Agile isn’t a label here — it’s embedded in how planning, building, and delivery actually happens. + +--- ## Sprint Structure -Sprints within the Released Method are time-boxed periods that typically range from one to four weeks. The focus is on delivering a working increment of the software at the end of each sprint, aligning with the agile principle of frequent delivery. -## Lifecycle Phases in Detail -The four phases of the lifecycle - Envision, Prototype, Architect, and Validate - encompass a range of activities: +Sprints are **time-boxed iterations** (usually 1–4 weeks), each designed to produce a potentially shippable increment of the product. Every sprint includes structured activities from across the full lifecycle — from ideation to validation. + +At the end of each sprint, the team should be able to demonstrate *real, working software*, not just progress or plans. + +--- + +## Lifecycle Phases + +The Released Method incorporates four key phases in every sprint cycle. These aren’t linear — they loop and adapt as needed: + +--- + +### 1. **Envision** + +This is where ideas are born and refined into actionable hypotheses. + +- **Brainstorm** – Free-thinking, collaborative idea generation +- **Hypothesis** – Formulate possible solutions to user problems +- **Wild Ideas** – Deliberately stretch beyond the obvious + +💡 **Output**: A structured set of GitHub issues, split into: +- Functional requirements +- Non-functional requirements +- Prioritised backlogs + +--- + +### 2. **Prototype** + +Validate assumptions before committing to full-scale development. + +- **Build** – Rapid prototype creation +- **Verify** – Quick user testing and validation +- **Fail Fast** – Kill bad ideas early and learn quickly + +Customer feedback is key here — the goal is real-world input, not perfection. + +--- + +### 3. **Architect** + +This is where ideas become product. + +- **Develop** – Turn validated prototypes into robust, secure features +- **Document** – Capture how features work and why they exist +- **Refine** – Improve design, performance, and structure + +Architecture doesn’t mean heavyweight planning. It means thoughtful, scalable design from the ground up. + +--- + +### 4. **Validate** + +Final phase to ensure what’s built is fit for purpose. + +- **Validate** – Test against specs, edge cases, and business goals +- **Optimize** – Improve code performance, efficiency, and clarity +- **Enhance** – Apply feedback to raise the quality bar + +Every sprint should result in validated, production-ready work — not "works on my machine" builds. + +--- -### Envision -- **Brainstorm**: Encourages creative thinking and idea generation without constraints. -- **Hypothesis**: Formulates potential solutions or approaches to the identified problems or needs. -- **Wild Ideas**: Promotes out-of-the-box thinking to explore innovative solutions. +## Sprint Execution in the Released Method -The output of this phase includes a set of GitHub issues, categorized into functional requirements, non-functional requirements, and priorities. +Each sprint incorporates **all four phases** to maintain momentum, encourage feedback loops, and support continuous improvement. This makes each sprint a mini product cycle, ensuring: -### Prototype -- **Build**: Develops initial prototypes to test the viability of the ideas. -- **Verify**: Tests and validates these prototypes against predefined criteria. -- **Fail Fast**: Emphasizes quick learning from unsuccessful ideas to refine the development process. +- Balanced workloads +- Regular customer checkpoints +- Ongoing technical excellence +- No dead sprints or pointless refactoring loops -Customer engagement during this phase is critical for feedback and ensuring the prototypes align with their expectations and needs. +Key ceremonies include: -### Architect -- **Develop**: Transforms prototypes into fully functional features, incorporating necessary elements for a robust, secure, and reliable product. -- **Document**: Ensures comprehensive documentation for each feature, aiding in clarity and future development. -- **Refine**: Involves fine-tuning features for optimal performance and quality. +- **Sprint Planning** – What are we solving, and how? +- **Stand-ups** – Daily alignment and block removal +- **Reviews/Demos** – Show, don’t tell — real work, real value +- **Retrospectives** – Improve the process, not just the product -### Validate -- **Validate**: Rigorously tests each component to ensure it meets the agreed specifications and client requirements. -- **Optimize**: Focuses on enhancing code efficiency, performance, and scalability. -- **Enhance**: Incorporates feedback to improve and add value to the product. +--- -## Enhanced Sprint Process -In the Released Method, each sprint is meticulously planned to include aspects from all four phases. This comprehensive approach ensures that every sprint contributes to the project's overall goals while remaining adaptable to evolving customer needs and market dynamics. +## Final Word -The sprints are structured to encourage a balanced workload, foster team collaboration, and promote a culture of continuous learning and improvement. Regular reviews and retrospectives are integral, allowing the team to reflect on their progress, adapt their approach, and enhance their effectiveness. +The Software Planning and Development pillar is where strategy becomes execution. It blends agility with rigour, creativity with accountability, and iteration with direction. -In summary, the Software Planning and Development pillar of the Released Method integrates agile principles into a robust, iterative process. This approach fosters flexibility, encourages innovation, and ensures a consistent focus on delivering high-quality software that meets and evolves with customer needs. \ No newline at end of file +It ensures your team doesn’t just *write code* — it delivers working, tested, valuable software that evolves with your users and your business. \ No newline at end of file diff --git a/startup-checklist.md b/startup-checklist.md index 7a177da..d7cfbbc 100644 --- a/startup-checklist.md +++ b/startup-checklist.md @@ -2,62 +2,83 @@ # Startup Checklist -This checklist serves as a comprehensive guide for technology startups to ensure they are structured for success. While adherence to this checklist doesn't guarantee success, it helps establish a strong foundation for a startup's operations, development, and growth. - -## Team -An effective team is the backbone of any technology startup. Ensure your team comprises skilled individuals in these critical roles: - -* [ ] **Architect**: Responsible for the overall technical design and structure of the software. -* [ ] **Developer(s)**: The core team members who write and maintain the software. -* [ ] **Tester(s)**: Specialists in testing software to ensure its reliability and usability. -* [ ] **Build and Release Automation Designer**: Focuses on automating the build and deployment processes. -* [ ] **User Experience Developer(s)**: Ensures the software is user-friendly and meets customer needs. -* [ ] **Designer(s)**: Creates the visual design and aesthetics of the software. - -## Process -Documented and well-followed processes ensure consistency and efficiency in operations: - -* [ ] **Daily Triage Process**: Manages and prioritizes daily tasks and issues. -* [ ] **Issue Management Process**: Tracks and resolves issues effectively. -* [ ] **Task Life-cycle Process**: Oversees the progression of tasks from inception to completion. -* [ ] **Automated Build Process**: Streamlines the process of integrating and compiling code. -* [ ] **Automated Release Process**: Ensures smooth and consistent software releases. -* [ ] **Peer Review Process**: Encourages collaborative review of code for quality assurance. -* [ ] **Quality Bar Process**: Sets and maintains quality standards for software releases. -* [ ] **Static Code Analysis Process**: Analyzes code for potential errors without executing it. -* [ ] **Code Coverage Process**: Measures the extent to which the source code is tested. -* [ ] **Documentation Process**: Ensures comprehensive documentation of the software and processes. -* [ ] **Sprint Planning and Execution**: Organizes and manages agile development sprints. - -## Technology -Implement robust technology systems for efficient and effective operations: - -* [ ] **Issue Management System**: Tracks and manages software development issues. -* [ ] **Task and Work Item Planning System**: Organizes and schedules tasks and work items. -* [ ] **Software Version Control**: Manages changes to the software codebase. -* [ ] **Development Analytics System**: Provides insights into the development process. -* [ ] **Artifact Management System**: Manages the versions of binary artifacts. -* [ ] **Automated Build System**: Compiles and builds the software automatically. -* [ ] **Automated Test System**: Executes tests automatically to ensure software quality. -* [ ] **Automated Release System**: Automates the process of software deployment. -* [ ] **Documentation System**: Manages and stores software and process documentation. - -## Minimum Viable Team -A core team with diverse skills is crucial for driving startup success: - -* [ ] **Hustler**: A versatile business leader who oversees various business operations including sales, marketing, and brand presence. -* [ ] **Hacker**: A technology visionary skilled in building scalable, high-quality systems. -* [ ] **Hipster**: A user experience aficionado responsible for design, user interaction, and customer education. - -## Documentation -Comprehensive documentation is a hallmark of successful projects: - -* [ ] **Code Commenting**: Annotated code for better understanding and maintenance. -* [ ] **API Documentation**: Detailed information about the application programming interfaces. -* [ ] **Design and Purpose Documentation**: Outlines the design rationale and objectives of the software. -* [ ] **Risk and Issues Documentation**: Identifies potential risks and issues with mitigation strategies. -* [ ] **Sprint and Project Planning Documentation**: Details the planning and progress of sprints and overall project. -* [ ] **End User Documentation**: Guides and manuals for end-users. -* [ ] **SDK Documentation**: Documentation for Software Development Kit, aiding external developers. - -By meticulously following this checklist, a technology startup can establish a robust framework for its operations, enhancing its chances for success in the competitive tech landscape. \ No newline at end of file +This checklist is your go-to guide for launching and scaling a technology startup. It doesn’t guarantee success — nothing does — but it gives you a solid operational foundation and eliminates the most common early-stage mistakes. + +--- + +## ✅ Team + +A strong team isn’t optional — it’s the engine of your startup. Make sure these roles are covered: + +* [ ] **Architect** – Owns the system design and technical direction +* [ ] **Developer(s)** – Build, test, and ship the product +* [ ] **Tester(s)** – Ensure reliability, performance, and edge-case coverage +* [ ] **Build/Release Automation** – Sets up the CI/CD pipelines to support rapid delivery +* [ ] **UX Developer(s)** – Designs workflows that make sense for users +* [ ] **Designer(s)** – Creates the visual identity and UI components + +--- + +## ⚙️ Process + +Define your processes early. It’s how you stay efficient as you grow. + +* [ ] **Daily Triage** – Prioritise and unblock the team every day +* [ ] **Issue Management** – Track and resolve bugs and feature requests +* [ ] **Task Lifecycle** – Define how tasks move from idea to done +* [ ] **Automated Build** – CI builds on commit — no manual compiling +* [ ] **Automated Release** – Scripted, repeatable deployments +* [ ] **Peer Review** – No code gets merged without another set of eyes +* [ ] **Quality Bar** – Shared definition of what’s “ready for release” +* [ ] **Static Code Analysis** – Catch bugs before they’re bugs +* [ ] **Code Coverage** – Know how much of your code is tested +* [ ] **Documentation** – Write it down, so people don’t ask twice +* [ ] **Sprint Planning/Execution** – Use agile ceremonies with intent + +--- + +## 🛠️ Technology + +You need the right tools in place before you scale — not after. + +* [ ] **Issue Tracker** – JIRA, GitHub Issues, Linear, etc. +* [ ] **Task Planning System** – Kanban or sprint-based +* [ ] **Version Control** – Git is mandatory; use it properly +* [ ] **Dev Analytics** – Track velocity, throughput, and cycle time +* [ ] **Artifact Repository** – Store built packages safely +* [ ] **Automated Build System** – CI pipelines for consistency +* [ ] **Automated Test Suite** – Unit, integration, and regression tests +* [ ] **Automated Release Pipeline** – One-click deploys to staging and prod +* [ ] **Documentation System** – Wiki, Notion, GitBook — just make it accessible + +--- + +## 👥 Minimum Viable Team + +Startups move fast — you need a well-rounded core from day one: + +* [ ] **Hustler** – Drives the business: sales, marketing, partnerships, and funding +* [ ] **Hacker** – Builds the product: writes code, solves problems, scales infrastructure +* [ ] **Hipster** – Owns the user experience: design, UX, storytelling, brand + +Don’t start until you’ve got all three. + +--- + +## 📚 Documentation + +Good documentation makes everything easier — onboarding, support, scaling, and investment. + +* [ ] **Code Comments** – Keep them relevant and helpful +* [ ] **API Docs** – Clearly explain endpoints, payloads, and auth flows +* [ ] **Architecture & Design Docs** – The “why” behind your system decisions +* [ ] **Risk Register** – Track risks and mitigations like a pro +* [ ] **Sprint/Project Planning** – What’s happening, when, and why +* [ ] **End-User Docs** – Help users get value from your product +* [ ] **SDK Docs** – Make it dead simple for others to build on your platform + +--- + +## Final Word + +Use this checklist to build your foundation. It won’t eliminate risk, but it will make you more resilient, more credible, and more likely to ship something that matters. \ No newline at end of file diff --git a/systems.md b/systems.md index 39becc8..85792f7 100644 --- a/systems.md +++ b/systems.md @@ -2,46 +2,109 @@ # Systems -In the Released Method, systems are integral components that facilitate efficient and effective software development, testing, and collaboration. Below is an enhanced overview of the critical systems vital for the success of a technology startup or software development project. - -## Document Management -**Importance**: Central to managing and maintaining project documentation. -- **Version Control Integration**: Ideally, integrates with the software version control system, syncing documentation with software changes. -- **Accessibility and Searchability**: Ensures easy access and searchability of documents for the team. - -## Software Version Control -**Criticality**: Essential for tracking and managing changes in the software. -- **Popular Systems**: Git is increasingly the standard, but others like Subversion are also used. -- **Branching and Merging**: Facilitates efficient handling of multiple development streams, like feature development and bug fixing. - -## Work Item Management -**Functionality**: Manages tasks and tracks progress. -- **Types of Work Items**: Includes bugs, tasks, features, and user stories. -- **States of Work Items**: Follows states like New, Active, Resolved, Documentation Required, Testing Required, and Closed. -- **Integration with Sprints**: Aligns with agile methodologies, linking work items to sprints or iterations for better tracking. - -## Release and Build -**Automation**: Crucial for consistent and reliable software delivery. -- **Multiple Environments**: Supports testing in various environments before market release. -- **Frequency**: Adaptable to different release frequencies, from rapid deployments to scheduled releases. - -## Automated Testing -**Necessity**: Increases efficiency and reliability of testing. -- **Types**: Ranges from unit testing to full-scale automated user experience testing. -- **Code Coverage Goal**: Aim for over 80% coverage to ensure robustness before initial release. - -## Management Reporting -**Insights**: Provides visibility into project status and progress. -- **Dashboards and Reports**: Tools to visualize project velocity, status, and metrics, guiding decision-making and planning. - -## Collaboration -**Connectivity**: Facilitates team communication and collaboration, especially important for remote or distributed teams. -- **Tools**: Preference for platforms like Microsoft Teams, offering instant messaging, voice and video calls, and document sharing. -- **Record Keeping**: Maintains records of communications for reference and continuity. - -## Development Tools -**Resource Investment**: Allocating resources for the best available development tools. -- **IDE Selection**: Choose IDEs that best suit the project's technology stack. -- **Library and Tool Access**: Ensure the team has access to necessary libraries and development tools to enhance productivity and innovation. - -These systems, when effectively implemented and utilized, create a robust infrastructure for software development, enabling teams to work efficiently, adapt to changes, and deliver high-quality software products. \ No newline at end of file +In the Released Method, **systems are not just tools — they’re enablers**. They underpin everything from collaboration and tracking to automation and deployment. The right systems, implemented well, remove friction, reduce risk, and supercharge productivity. + +This guide outlines the essential systems every technology startup or software team should have in place to support high-velocity, high-quality delivery. + +--- + +## 📄 Document Management + +**Why it matters**: Documentation is only useful if people can find it — and trust it. + +- **Version-Controlled** – Tightly integrated with your codebase or change history +- **Searchable and Accessible** – Easy to navigate and locate what matters +- **Centralised** – One source of truth, not scattered across drives or inboxes + +🛠 Tools: Notion, Confluence, GitBook, Markdown in GitHub/GitLab + +--- + +## 🔁 Software Version Control + +**Non-negotiable**: You need version control from day one. + +- **Git is the standard** – Use hosted services like GitHub, GitLab, or Bitbucket +- **Branching Strategy** – Define how features, hotfixes, and releases are managed +- **History and Traceability** – Know who changed what, when, and why + +🚨 Tip: Enforce pull requests and code reviews. It’s your first quality gate. + +--- + +## 🗂️ Work Item Management + +**Purpose**: Organise your backlog, prioritise work, and track progress. + +- **Work Item Types** – Features, bugs, tasks, tech debt, and spikes +- **State Lifecycle** – New → Active → In Test → In Docs → Closed +- **Sprint Integration** – Link tasks to sprints or iterations for visibility and accountability + +🛠 Tools: Azure DevOps, Jira, Linear, GitHub Projects + +--- + +## 🚀 Build and Release Automation + +**Goal**: Deliver with confidence, speed, and zero surprises. + +- **Multiple Environments** – Dev, staging, UAT, and production +- **Scripted and Repeatable** – No manual deployment steps allowed +- **Release Cadence** – Supports both rapid and scheduled release cycles + +🛠 Tools: GitHub Actions, Azure Pipelines, CircleCI, Octopus Deploy + +--- + +## ✅ Automated Testing + +**Why it matters**: You can’t scale quality without automation. + +- **Test Types** – Unit, integration, regression, and UI tests +- **Coverage Targets** – Aim for 80%+ code coverage pre-release +- **Fast Feedback** – Tests should run automatically on every push or PR + +🛠 Tools: Jest, NUnit, PyTest, Selenium, Cypress + +--- + +## 📈 Management Reporting + +**Purpose**: Make data-driven decisions, not guesses. + +- **Dashboards** – Visualise burndown, velocity, cycle time, code quality +- **Status Reporting** – Show what’s done, what’s blocked, and what’s next +- **Forecasting** – Estimate delivery dates and resource usage + +🛠 Tools: Power BI, Looker, Azure DevOps Dashboards, Jira Reports + +--- + +## 💬 Collaboration + +**Essentials**: Communication must be fast, fluid, and recorded. + +- **Centralised Chat** – Real-time communication via Teams or Slack +- **Video & Screen Sharing** – For pair programming, demos, and retrospectives +- **Persistent Channels** – Keep conversations searchable and structured +- **Linked to Work** – Conversations should tie back to tasks, PRs, and goals + +🛠 Tools: Microsoft Teams, Slack, Zoom, Miro, Loom + +--- + +## 🧰 Development Tools + +**Investment**: Good tools make good developers faster. + +- **IDE of Choice** – Based on stack and preference (VS Code, JetBrains, etc.) +- **Toolchain Access** – Linting, debugging, profiling, testing +- **Library Management** – Package managers (npm, NuGet, pip) must be secure and up to date + +🛠 Support your team with licenses, automation, and performance tools. + +--- + +## Final Word + +The right systems won’t fix a broken team — but the wrong systems *will* slow down a good one. In the Released Method, systems aren’t an afterthought. They’re baked in, integrated, and constantly improved to support fast, sustainable, and high-quality software delivery. diff --git a/team-model.md b/team-model.md index 17a7b7a..35f1087 100644 --- a/team-model.md +++ b/team-model.md @@ -2,51 +2,81 @@ # Team Model -In the Released Method, the team model is foundational for a startup's success, delineating essential roles and functions necessary at various stages of growth. Inspired by insights from Angela Bee Chan of [Hackathons Australia](https://www.hackathonsaustralia.com/), this model outlines the minimum viable team structure and the additional roles required as the startup matures and scales. +The **Released Method** recognises that startups live or die by the strength of their teams. This team model maps out the essential roles needed at each stage of growth — from day-one hustle through to scale. -## Minimum Viable Team -### Hustler -- **Role**: Often the CEO or business leader. -- **Responsibilities**: Drives the overall vision, business strategy, marketing, sales, financial planning, and revenue generation. +Inspired by insights from Angela Bee Chan of [Hackathons Australia](https://www.hackathonsaustralia.com/), the model focuses on lean execution early, followed by smart role expansion as the product matures. -### Hacker -- **Skills**: Essential coding and technical skills to build the initial product. -- **Expansion**: As the startup progresses, the need for a dedicated Tester becomes crucial for quality assurance. +--- -### Hipster -- **Design Expertise**: Responsible for user interface and experience design, branding, website development, and visual communication. +## 🧪 Minimum Viable Team -## Release Team -To transition from prototype to market-ready product, additional roles are vital: +Your startup doesn’t need a 30-person team on day one — but it does need coverage across **business, tech, and design**. That’s where the classic trio comes in: -### Accountant -- **Value**: Manages financial operations including accounting, invoicing, and billing systems. -- **Importance**: Crucial for financial health and compliance. +### 🧠 Hustler +- **Who**: The founder, CEO, or commercial lead +- **Drives**: Vision, business strategy, customer acquisition, sales, marketing, revenue, and funding +- **Why it matters**: No one buys unless someone sells. -### Lawyer -- **Legal Guidance**: Provides essential legal support, drafting terms, NDAs, privacy policies, and contracts. +### 💻 Hacker +- **Who**: The technical co-founder or first engineer +- **Builds**: The first version of the product +- **Expansion**: Eventually joined by testers or automation engineers as technical complexity grows -### Tester -- **Quality Assurance**: Focuses on identifying and reducing bugs in the software. -- **Evolution**: In advanced stages, can contribute to automated testing and release processes. +### 🎨 Hipster +- **Who**: The designer or frontend lead +- **Owns**: UI/UX, branding, website, and visual storytelling +- **Impact**: Turns your product into something people *want* to use, not just *can* use -## Scale Team -As the startup enters the market and begins to grow, the team needs to expand to support scaling: +This trio forms your initial launch team. Without them, you’ll be building blind. -### Support Team -- **Customer Interaction**: Addresses customer inquiries and troubleshoots issues, enhancing customer satisfaction and loyalty. +--- -### Developers -- **Expanded Development**: Takes on the development of new features, maintenance, and ongoing improvements to the software. +## 🚀 Release-Ready Team -### Designers -- **Creative Expansion**: Continues to enhance the visual and user experience aspects of the product. +Once you're past MVP and aiming for market, you need to strengthen operational and legal foundations: -### Testers -- **Ongoing Quality Assurance**: Persistently works towards identifying and solving bugs, ensuring the product's reliability. +### 💰 Accountant +- **Handles**: Bookkeeping, invoicing, tax compliance, financial reporting +- **Why now**: You’re starting to generate revenue — time to track every dollar. -### Administrative Roles -- **Operational Support**: Includes roles in accounting, sales, HR, and administration, crucial for a growing organization. -- **Timing**: These roles become necessary as the startup achieves profitability and operational complexity increases. +### ⚖️ Lawyer +- **Advises on**: Contracts, IP, privacy, NDAs, compliance +- **Protects**: Your business and your product from early legal landmines -By adhering to this team model, a startup can effectively navigate through different phases of its lifecycle, from inception and prototyping to market release and eventual scaling. The right team composition at each stage is essential for balancing innovation, technical excellence, business acumen, and operational efficiency. \ No newline at end of file +### 🧪 Tester +- **Focuses on**: Manual and exploratory testing +- **Adds value**: Catches issues before your customers do +- **Next stage**: Can grow into automated QA and CI/CD pipeline integration + +--- + +## 📈 Scale-Up Team + +As your user base grows, so does your team. You’ll need to invest in specialised roles to support scale and stability: + +### 🎧 Support Team +- **Frontline**: Handles customer queries, bug reports, and onboarding +- **Retention booster**: Happy users stick around and spread the word + +### 👨‍💻 Developers +- **Expand capacity**: Build new features, squash bugs, and maintain the codebase +- **Essential for**: Keeping up with demand and scaling architecture + +### 🖌️ Designers +- **Evolve the experience**: Iterate on UI/UX, brand, and communication +- **Critical for**: Differentiation and usability + +### 🧪 Testers +- **Go deep**: Expand coverage, build automated test suites, stress test edge cases +- **Part of**: A mature, sustainable release cycle + +### 🧾 Administrative Roles +- **Includes**: HR, finance, legal ops, sales ops, and executive assistants +- **When to add**: Post-product-market fit, when complexity starts to bite +- **Why**: Free up your core team to focus on growth, not admin + +--- + +## Final Word + +Startups don’t scale by accident — they scale by evolving the team at the right pace. The Released Method team model helps you build lean, grow strategically, and ensure that every function — from code to customer — is covered. \ No newline at end of file diff --git a/testing-qa.md b/testing-qa.md index 5a1fc20..bc4a374 100644 --- a/testing-qa.md +++ b/testing-qa.md @@ -2,66 +2,110 @@ # Testing and Quality Assurance -In the Released Method, Testing and Quality Assurance are pivotal for ensuring software reliability and customer satisfaction. This process follows a comprehensive and structured approach, encompassing various types of testing and a systematic handling of bugs. +In the Released Method, **Testing and Quality Assurance (QA)** are not afterthoughts — they’re embedded into the development process from day one. This pillar ensures your software is reliable, robust, and ready for real-world use, with a disciplined, layered approach to testing and a streamlined system for managing bugs. -## Testing Methodologies -The testing process incorporates multiple layers to ensure thorough evaluation: +--- -### Unit Tests -- **Purpose**: Tests individual components or functions for expected operation. -- **Automation**: Typically automated to run frequently during development cycles. +## 🔍 Testing Methodologies -### Code Analysis -- **Objective**: Identifies potential issues at a code level using automated tools. -- **Scope**: Includes checking for syntax errors, potential bugs, and style inconsistencies. +The Released Method applies multiple layers of testing to catch issues early, reduce risk, and improve maintainability. -### Automated Tests -- **Focus**: Simulates user interactions with the UI to verify functionality. -- **Benefits**: Reduces the need for manual testing and ensures repeatability. +### ✅ Unit Tests +- **What**: Test individual components, functions, or classes in isolation +- **Why**: Catch bugs early at the smallest level of code +- **How**: Automated, fast, and run continuously in CI pipelines -### Manual Tests -- **Role**: Performed by human testers to catch issues that automated tests may miss. -- **Importance**: Critical for assessing usability and real-world application scenarios. +--- -## Bug Reporting and Management -A structured approach to bug reporting enhances the efficiency of resolving issues: +### 🔬 Code Analysis +- **What**: Static analysis tools that scan source code without executing it +- **Why**: Identify syntax issues, bugs, vulnerabilities, and style violations +- **Tools**: ESLint, SonarQube, StyleCop, etc. -### Bug Report Components -- **Title**: Concise summary of the issue. -- **Id**: Unique identifier for tracking. -- **Description**: Detailed account of the issue, reproduction steps, and impact. -- **Severity and Priority**: Assessed to prioritize bug fixing efforts. -- **Comments**: For ongoing updates and communication regarding the bug. -- **Labels**: For categorizing and workflow management. -- **Originator and Owner**: Denoting the reporter and current handler of the issue. +--- -### Reproduction (Repro) -- **Necessity**: Clear, step-by-step instructions to replicate the bug. -- **Details**: Includes conditions under which the bug occurs and why the behavior is incorrect. +### 🤖 Automated UI & Integration Tests +- **What**: Simulate real user flows and system-level interactions +- **Why**: Validate end-to-end functionality, catch regressions early +- **When**: Run on each build or deployment -## Severity Levels -Defines the impact of the bug on user experience or product functionality: +--- -1. **Critical**: Renders the product unusable or causes major malfunctions. -2. **Major**: Significant impact but with potential workarounds. -3. **Minor**: Annoying issues that do not significantly impede normal operation. +### 🧪 Manual Testing +- **What**: Human-driven exploratory and scenario testing +- **Why**: Catch issues automation misses (usability, edge cases, design quirks) +- **When**: Especially valuable before major releases or after new features -## Priority Setting -- **Determined in Triage**: Prioritization is essential for effective bug resolution order. -- **Categories**: Ranging from high urgency (priority 1) to lower urgency (priority 2, 3, etc.). +--- -## Triage Process -Triage is a crucial stage where bugs and requests are evaluated and actioned: +## 🐛 Bug Reporting and Management -- **Actions**: Include Investigate, Approve, Reject, or Defer. -- **Resolver Assignment**: Allocates a team member to address the approved issues. -- **Review and Feedback Loop**: Ensures continual assessment and action on bugs. +A good bug tracking system enables fast resolution and accountability. Every bug should include: -## Post-Triage Actions -Once a bug is resolved, validation and regression testing are key: +- **Title** – Short and descriptive +- **ID** – Unique identifier for tracking +- **Description** – What went wrong, steps to reproduce, expected vs actual behaviour +- **Severity & Priority** – Set during triage +- **Repro Steps** – Clear instructions to consistently recreate the issue +- **Labels** – For categorisation and workflow automation +- **Comments** – For status updates and team communication +- **Originator** – Who reported the bug +- **Owner** – Who is currently assigned to fix it -- **Validation**: The originator verifies the resolution of the issue. -- **Regression Testing**: Development of tests to prevent recurrence of the same issue. +--- -## Closing the Loop -After successful validation and regression testing, the bug is marked as closed, indicating a complete resolution. This comprehensive approach to Testing and Quality Assurance in the Released Method ensures that software products are robust, reliable, and meet the highest standards of quality. \ No newline at end of file +## 🧨 Severity Levels + +Severity defines how badly the bug impacts the product: + +1. **Critical** – System is down, data loss, or security risk +2. **Major** – Key functionality broken, but with a workaround +3. **Minor** – Cosmetic or non-blocking issue + +--- + +## 📌 Priority Levels + +Priority defines how urgently the bug should be fixed. Set during triage: + +- **P1** – Fix immediately +- **P2** – Fix in next sprint +- **P3** – Low urgency, fix when convenient +- **Deferred** – Logged, but not scheduled + +--- + +## 🩺 Triage Process + +Triage is a regular session to assess, prioritise, and assign bugs or feature requests. + +- **Actions**: Investigate, Approve, Reject, or Defer +- **Assignment**: Allocated to a developer, tester, or analyst +- **Review Loop**: Continuous reassessment ensures relevance and proper priority + +--- + +## 🔁 Post-Triage: Fix, Validate, Regress + +Once fixed, bugs go through validation and regression checks: + +- **Validation** – The originator or QA confirms the bug is resolved +- **Regression Testing** – New tests are added to ensure the issue doesn’t return +- **Closure** – The bug is marked as Closed only after confirmation and coverage + +--- + +## 🧠 Why It Matters + +QA in the Released Method isn’t about bureaucracy — it’s about confidence. Testing ensures: + +- Your product behaves as expected +- Your team isn’t firefighting post-release bugs +- Your users trust your software +- Your business avoids downtime, rework, and customer churn + +--- + +## Final Word + +Testing and QA in the Released Method are disciplined, automated where possible, and reinforced by strong bug triage and feedback loops. It’s a system that scales with your team — and protects your reputation as you ship faster, smarter, and with fewer surprises. diff --git a/why.md b/why.md index 13ac160..09cddc9 100644 --- a/why.md +++ b/why.md @@ -2,31 +2,76 @@ # Why Choose the Released Method? -In the diverse landscape of software development methodologies, each with its own strengths and focus, the Released Method stands out for its specific orientation towards delivering successful and high-quality software products for modern startups. Unlike more generic methodologies, it is fine-tuned for environments that demand rapid innovation and lean operations. +In a world full of software development methodologies, most frameworks either aim for broad applicability or lean heavily on dogma. The **Released Method** is different. It’s purpose-built for startups, skunkworks teams, and innovation-led environments that demand speed, adaptability, and quality without the bloat. -## Focused Goal -The primary aim of the Released Method is to bring a commercially viable product to the market efficiently. It caters specifically to projects with direct executive control, where the principal external influences are market demands and customer feedback, making it ideal for startups and skunkworks projects. +--- -## Key Features -The Released Method distinguishes itself through several critical features: +## 🎯 Clear Focus: Get to Market, Fast -- **Quality Software**: Emphasizes the development of high-quality, robust software solutions. -- **Testing**: Integrates comprehensive testing strategies to ensure reliability and performance. -- **Automated Release**: Utilizes automated release processes for efficient and consistent deployment. -- **Team Management**: Focuses on effective team collaboration and role definition. -- **Agility**: Adapts quickly to changing requirements and market conditions. -- **Reduced Cost**: Aims to minimize costs without compromising on the quality of the output. +The primary objective of the Released Method is simple: +**Deliver a commercially viable product efficiently and predictably.** -## Business Case -The volatile and unpredictable nature of software development projects, especially in a startup context, poses unique challenges: +It’s designed for projects with direct executive oversight, minimal red tape, and tight market feedback loops — ideal for: -- **Predictability Issues**: Unlike physical engineering projects like bridge construction, software projects have numerous unknowns that make cost and time predictions challenging. -- **Agile Flexibility**: Agile development methodologies add to this unpredictability, as they are designed to be fluid and adaptable. -- **Control vs Prediction**: Traditional command-and-control approaches are less effective in such dynamic environments. +- Early-stage startups +- Product incubators +- Internal innovation teams +- Founder-led technical builds -### The Released Method's Approach -- **Sprint-Based Delivery**: Breaks down the project into sprints, each with defined objectives, budgets, and timelines. This approach increases predictability and control over the project’s progression. -- **Adaptability**: The method is agile enough to adapt to fixed budgets and changing requirements, ensuring delivery within set constraints. -- **Assured Quality and Outcome**: Even with budget and time constraints, the Released Method is structured to deliver a reliable and quality product. +When time, budget, and reputation are on the line, the Released Method provides a framework that delivers. -In summary, the Released Method is a tailored solution for startups and innovative software projects that require a balance between agility, quality, and cost-effectiveness. It is designed to navigate the complexities of modern software development, providing a structured yet flexible framework that adapts to the unique challenges of each project. \ No newline at end of file +--- + +## 🔑 What Sets It Apart + +Unlike generic methodologies, the Released Method is fine-tuned for execution: + +- **Quality-First Mindset** – High-quality, production-ready code is the default +- **Embedded Testing** – Unit, integration, and regression testing are built into the lifecycle +- **Automated Release** – CI/CD pipelines ensure repeatable, low-risk deployments +- **Lean Team Model** – Clear role definitions matched to the startup phase +- **Agility Without Chaos** – Responsive to change without sacrificing structure +- **Cost-Conscious Delivery** – Budget-aware planning that still delivers value + +--- + +## 💡 A Realistic Business Case + +Let’s be blunt: software isn’t like building a bridge. + +- Requirements shift +- Markets move +- Users surprise you +- Timelines slip +- And budgets are always tighter than you’d like + +Traditional “command-and-control” or heavyweight methodologies break down in this environment. Even pure Agile, while flexible, often lacks enough structure to keep fast-moving teams aligned and accountable. + +--- + +### 🚀 The Released Method Difference + +The Released Method brings discipline to agility — and structure to startup speed: + +- **Sprint-Based Planning** – Each sprint has clear goals, a defined budget, and tight feedback loops +- **Built for Change** – Handles evolving scope without derailing the roadmap +- **Predictable Outcomes** – Increases control over time, cost, and quality — even under uncertainty +- **Outcome-Driven** – Every cycle ends with a working, shippable increment +- **Aligned With Reality** – Built from 20+ years of real-world product delivery, not academic theory + +--- + +## 🧩 In Summary + +The Released Method is the execution engine your startup needs — especially when: + +- You need to ship fast but not break everything +- You care about code quality and customer experience +- You want structure without bureaucracy +- You can’t afford to get it wrong the first time + +It’s not a silver bullet, but it *is* the pragmatic, founder-tested framework for building high-quality software with limited resources and evolving goals. + +--- + +Want to apply the Released Method to your current project or startup? Let’s get you up and running. \ No newline at end of file