--- title: "The Devign Inspiration" author: "Moonward" url: "https://books.moonward.com.au/2/the-devign-methodology" --- #Foreward I’ll be honest, we first started designing the Devign Methodology, I didn’t expect it to hit me the way it did. After all, I’d already been in the trenches for years, building a multi-million-dollar software agency, scaling from my bedroom to a five-star office in the heart of Brisbane, and shipping 150+ software products into the world. I’d seen every methodology, every framework, every “next big thing” promising to make software development easier, faster, or cheaper. But Devign is different. What struck me was its clarity. Devign isn’t about cranking out features to check boxes. It’s about building outcomes. Real, tangible outcomes that matter to businesses, to users, and to the teams who pour themselves into creating them. That shift alone from “what can we build” to “what will this actually achieve” is a game changer. In my own experience leading Moonward, I’ve seen projects stumble because they got lost in the “how” far too early. Devign flips that on its head. It forces you to pause and align first on the what and the why. It embraces the reality that we don’t have every answer at the start and that’s okay. The magic happens when you have the right team, a clear vision, and the courage to collaborate your way forward. And here’s the part I love most: Devign is deeply human. It reminds leaders to avoid micromanaging every detail and to empower people. To provide direction when needed, and then get out of their way. Over the years, I’ve come to believe that the most successful software products are born when a clear vision, a deep desire for success, and collaboration collide. Devign puts that belief into practice. It gives teams a framework to rally around, one that creates momentum, keeps focus sharp, and most importantly, that the work you’re delivering actually offers value. So, whether you’re a founder trying to shape your first product, a developer tired of features that go nowhere, or a leader searching for a methodology that respects both outcomes and people this book is for you. Read it. Apply it. Challenge it. My bet is, like me, you’ll look back and wonder how you ever built software without it. — Andrew Owen CEO, Moonward #What is Devign Methodology Want to build successful software? Inspiration alone is not enough, though. That’s why we created the Devign Methodology: to give structure to creativity, discipline to discovery, and transparency to trust. Devign Inspiration provides the vision; the Devign Methodology provides the path. #About Moonward What started as a single app in a small town in New Zealand, has burst into a Software Design and Development Agency in Brisbane Australia. We are an intentionally boutique team who creates and ships software. We want every customer to go on a journey of discovery with us. Finding new and better ways to realise their dreams and goals, and creating new ones along the way. We want them to look back on their project and say what one of our first customers said, ”Thanks for taking me to the Moon.” #Our why We are active investors in the two rarest commodities in software development. Trust and Transparency. In this industry, they are often hard to find. Too many projects are clouded by uncertainty, hidden processes, and unclear communication. We want to break down those barriers so you always know where we’re headed and how we plan to get there. That’s why we wrote this book - for both you and our team - to keep these principles front and centre. Our commitment to trust and transparency has led to long, meaningful relationships with our clients. These partnerships are fulfilling because they’re built on the confidence that both sides are working together toward the same goal: creating the best outcomes possible. #Our rules - **We fly together** - each person has a role on the team. Why? To help us accomplish the goal of the team. We are going to get there together or not at all. - **Find the way on the way** - what’s around the riverbend? well, we can’t always know for certain. That is why we understand that the way forward is a journey. See Tabula R.A.S.A - **No hired actors** - we are a team of genuine people who deeply care about what we do. - **We choose to go to the Moon** - ‘…But why some say the moon? Why choose this as our goal? And they may well ask, why climb the highest mountain? Why 35 years ago fly the Atlantic? We choose to go to the moon. We chose to go to the moon. We choose to go to the moon in this decade and do the other things not because they are easy, but because they are hard…’JFK #Our Mantras **Outcomes over output** Shipping features is not the finish line - delivering impact is. Our Devign Methodology is grounded in continuous discovery, where every release is measured not by the number of outputs, but by the outcomes they create for people. Our team is not here to simply deliver features or tick off a list. We are here to create a software product that generates meaningful outcomes for you and your clients. This principle is always at the forefront when we decide what to build next. **Tabula R.A.S.A** Every project begins with a clean slate. Our Devign Methodology makes no assumptions on the best path to a technological solution, because the best solution yesterday is unlikely to be the best solution today. Our focus is on Rapid Adaptation of existing tech and Swift Adoption of new tech (R.A.S.A). We have learned that it is more expeditious to find the way on the way. We call this approach: Tabula R.A.S.A Rapid Adaption of existing tech Swift Adoption of new tech **To The Moon** Aim high, think big, look beyond. #About our Devign Methodology The app and software development industry has grown into something inefficient, and difficult to deal with for customers. Traditionally, it’s divided into front of house (who the client deals with) and back of house (where the design and development takes place). In this model, the FOH staff become barriers between the clients and their project. Traditional BOH is also divided. Design and development working separately, often in different countries, and handing over their progressed files at intervals. This causes hold ups and delays as issues aren’t identified in real time and problems take several cycles to resolve. We have created a new approach. A smarter, more transparent methodology. All of our design and development occurs in Australia, in-house, in one office. Design and development are not separated. They are fused together in a symbiotic partnership.It is a hybrid environment where day by day, hour by hour, each discipline can see potential problems and potential opportunities appearing in real-time. Clients aren’t kept at arms length, they are brought into the process and get to ‘see where the sausage is made.’ They participate in integrated and collaborative sessions with their team where they learn to understand the technical limitations and opportunities. It isn’t just a faster way of working, it is a smarter way of working, and it compresses project timelines by 143% or more. We have taken Development + Design out of their siloes and created a new vision of software creation: Devign Methodology. #How this helps us compress project timelines by 143% Our software solutions reflect the combined experience of all our seasoned developers, product owners, analysts and designers. Our unique collaborative process has proven to work best when every member of the team is constantly connected directly to the challenge, in-house. Software development is difficult to manage. Preserving the integrity of a project when design and development is split across seperate teams (and locations) is challenging. In the traditional model, client touch points are infrequent and provide late visibility of errors and miscommunications. Design and developer teams are often misaligned, communicate poorly and lack common priorities. Devign addresses these hurdles with an in-house collaborative project team of Engineers, Designers and Product Owners. Your team is connected directly to the project and frequent client touch points begin at 2 weeks. The Devign Model retains integrity, agility, transparency and quality control. ![TRADITIONAL CHART BLACK.png](https://books.moonward.com.au/u/traditional-chart-black-3PLnAL.png) ![DEVIGN CHART BLACK.png](https://books.moonward.com.au/u/devign-chart-black-zu5LlI.png) #What the Devign Methodology pushes for **An Outcome** We don’t design and develop for the sake of filling screens or writing code. Every sprint, every feature, and every decision is anchored to an outcome. Whether it’s the Product Outcome or the Sprint Outcome, the question is always the same: “What value does this create?” If the answer isn’t clear, we strip it back. **Less Bloat, More Clarity** Less code means fewer bugs. Fewer features mean simpler decisions. Simpler products mean happier users. The Devign approach pushes for refinement, not expansion - prioritising what truly matters over what simply fills space. Yes, we can build complex systems. Yes, we can modernise legacy products. But the goal isn’t to do more - it’s to do better. Sometimes that means forcing tough prioritisation calls. Sometimes it means saying no. The truth is: the fewer moving parts, the stronger the product. **Underdo the Competition** Instead of competing on size, we compete on focus. By deliberately doing less, we leave room to do the essentials exceptionally well. That’s what makes products stick, what makes users come back, and what makes investments worthwhile. #We didn’t invent the system, we refined it The Devign Methodology is a blend of many different frameworks, models and ways of working. With years of refinement and trial and error, Moonward has taken the best of all these systems and adapted it to suit us. #Why it works 1. Creates clarity and team focus 2. Align teams and clients around clear deliverable outcomes 3. Increases delivery predictability and quality #The Roles within the Devign Methodology **You, the Client** You are the visionary - the Da Vinci, the Michelangelo. You’ve already seen the statue within the marble; it’s your role to share that vision with us so together we can carve it out. **The End User** The muse of the project. The person who will ultimately use the product and define its success. Their needs, frustrations, and aspirations guide every decision we make. **The Devign Master** The guardian of the Devign Methodology. This role is internal to Moonward, responsible for ensuring every sprint, every artefact, and every event is carried out with precision and purpose. The Devign Master keeps the team aligned with the methodology and safeguards its integrity throughout the project. **The Product Owner** Acting on behalf of both the client and the end user, the Product Owner bridges vision and execution. They set the product goal, define the sprint objectives, and prioritise the work that matters most. Always close to the process, they ensure the team is building the right thing, at the right time, for the right people. **The Engineer** Our front-end and back-end developers are the builders of the product. Highly skilled and technically minded, they bring the architecture, logic, and functionality of the software to life. Their perspective is crucial to shaping not only what is possible but also what is sustainable and scalable. **The Designer** The voice of experience and usability. Designers focus on uniting User Experience (UX) and User Interface (UI) into a seamless journey. They test, refine, and ensure every interaction is intuitive, enjoyable, and aligned with both user needs and business goals. **The QA Tester** The guardian of quality. QA Testers rigorously evaluate the product to catch issues before they reach the end user. They ensure functionality, reliability, and performance meet the highest standards, protecting both the client’s vision and the user experience. #The Devign Methodology: A Journey Through Events and Artefacts At Moonward, the Devign Methodology is not a set of disconnected rituals or static documents. It is a living system: a rhythm of events that guide the team, and artefacts that capture and evolve our understanding. Each event creates or refines an artefact, and each artefact sets the stage for the next event. Together, they tell the story of how we move from a blank page to a delivered product. **Events** The heartbeat of the Devign Methodology. These are the moments when the team gathers - to align, to question, to decide, to learn. Each event is a deliberate pause in the rush of delivery, giving space for clarity, collaboration, and course correction. **Artefacts** The living record of our work. Not dusty documents, but evolving blueprints - shaping and shaped by every discussion, decision, and discovery. Each artefact captures where we are now and lights the path for where we’re going next. #We work in Sprints At Moonward, you’ll often hear us talk about a Sprint. A sprint is a focused two-week cycle where our development team works to deliver a specific outcome or product increment. Two weeks is the “sweet spot” - long enough to achieve meaningful progress, but short enough to maintain momentum and adapt quickly to new insights. #Sprint Schedule ![Screenshot 2026-02-06 at 11.31.29 AM.png](https://books.moonward.com.au/u/screenshot-2026-02-06-at-11-31-29-am-MLdBZH.png) Please note, Daily Stand Ups, Go/ No Go and Monthly Devign Inspiration Workshops are not pictured. ## Finding our Moon Every project begins with clarity of purpose. That clarity lives in the **Product Requirement Document (PRD)**. ### **PRD (Artefact)** - **Purpose:** Details the project’s main Objectives and Outcomes. - **Contents:** - Summary: What we’re doing & why (max 5 lines) - Customers & their Problem - Outcome Goals & KPIs (with measurable targets) - Scope (MVP) & Non-Goals - Top Requirements - Risks & Mitigations - Rollout & Measure - Owners & Dates From the PRD, the **Product Backlog** is created — the ever-evolving list of work that moves us toward the vision. ### **Client Discovery Document (Artefact)** - **Purpose:** Captures essential insights about the client — their personality, motivations, goals, and communication preferences — to guide collaboration and ensure the team works in harmony with the client throughout the project. - **Contents: Client personality type (using the Red, Blue, Yellow, Green Framework):** Identifies the client’s working and communication style to tailor collaboration approaches effectively. - **Client motivations and drivers:** Outlines what inspires and drives the client — whether it’s speed, quality, innovation, or collaboration — to align delivery with their priorities. - **Goals for this product and desired outcomes:** Defines the objectives the client wants to achieve with the product and the measurable results they expect. - **Key dates and milestones important to the client:** Captures critical deadlines, events, or checkpoints that must be respected throughout the project lifecycle. - **Notable points, preferences, or considerations mentioned in meetings:** Records specific requests, working preferences, sensitivities, or contextual insights shared by the client that may impact delivery. - **Storage & Maintenance:** Stored in Confluence and treated as a living document. - Updated continuously as the relationship evolves and new insights emerge. ### **Product Backlog (Artefact)** - **Purpose:** Continuously prioritised, clarified, and refined by the Product Owner. - **Structure:** - Epics → broken down into **Product Backlog Items (PBIs)** - PBIs are either **User Stories, Tasks, or Bugs**. **Product Backlog Items (PBIs)** - **User Stories**: Written from the persona’s perspective. - *As a [X], I want to [Y], so I can [Z]* - Must include Acceptance Criteria & Design Reference - Owned by Product Owner, completed before the first Devign Inspiration session (min. 2 sprints ahead) - **Tasks**: Non-functional items (e.g. deploy environment, configure payment gateway). - **Bugs**: Use a clear format: - *Expected Behaviour: [X]* - *Actual Behaviour: [Y]* ## Inspiration and Refinement With a backlog in place, the team begins preparing work for sprints. This happens in **Devign Inspiration**. ### **Devign Inspiration Workshop (Event)** - **Time Box:** 90 minutes - **Frequency:** Every Month - **Owner:** Product Owner - **Attendees:** Devign Master, Product Owner, Developers, Designer - **Purpose:** Aligns the team on upcoming work, refines stories, explores innovation, and estimates effort. This workshop isn’t just a backlog grooming exercise—it’s our space to **push boundaries and innovate**. The goal is not only to understand *what* we’re building but to ask *why* we’re building it and *what else might be possible*. This is the team’s opportunity to bring their best thinking to the table, challenge assumptions, and collectively discover better paths forward. **Must-haves before the session:** - Prioritised Epics and User Stories - Draft requirements and acceptance criteria - Quick **market scan / research notes** on existing tools, frameworks, or approaches that might apply (prepared by Developers or Designers before the session) **How it runs:** 1. **Presentation & Clarification** - Product Owner presents backlog items. - Developers and Designers ask clarifying questions to ensure shared understanding. 2. **Exploration & Innovation (Tabula R.A.S.A)** - Pause to ask: *Is there a better way?* - Explore alternatives and emerging technologies. - Encourage everyone to bring one idea, however small, that could improve the outcome. - Apply the **Rapid Adaptation / Swift Adoption** lens: what can we test quickly, and what could we adopt fast if it works? 3. **Technical Discussion** - Define architecture, risks, dependencies. - Split/refine large or vague stories. 4. **Documentation** - Record session notes in Confluence (*Project X → Devign Inspiration*). - Update/refine PBIs in Jira. **Why it matters:** The Devign Inspiration Workshop ensures we’re not just executing a backlog but actively shaping it. By carving out space for innovation every sprint, we balance delivery with discovery—keeping the product alive, relevant, and forward-thinking. The output of this session feeds directly into the **Sprint Backlog**. ### **Sprint Backlog (Artefact)** - **Purpose:** Contains the work selected for the sprint. - **Requirements:** - Must include a **Sprint Outcome**. - At least 2 sprints worth of work mapped ahead. ### **Sprint Outcome (Artefact)** - **Purpose:** Guides the sprint, focusing the team on *outcome* rather than output. - **Key Principles:** - Created during Sprint Planning. - Describes value/result, not just tasks. - Realistic, achievable, and unifying. - Serves as a decision filter: *Does this still help us meet our Sprint Outcome?* ## Committing to the Sprint Once work is refined, the team meets for **Sprint Planning**. ### **Sprint Planning (Event)** - **Time Box:** 45 minutes - **Frequency:** Every Sprint - **Owner:** Devign Master - **Attendees:** Devign Master, Product Owner, Developers, Designer - **Purpose:** Defines what will be done and how it will be achieved. **How it runs:** 1. **Define Sprint Outcome** - Product Owner proposes priorities. - Team aligns outcome with Product Outcome. 2. **Select & Plan Work** - Team commits to PBIs from the top of the backlog. 3. **Documentation** - Sprint Outcome + Sprint Backlog recorded in Confluence (*Project X → Sprint Planning*). ## Executing the Sprint Now the rhythm of the sprint begins, powered by one event that maintains alignment and accountability. ### **Daily Standup (Event)** - **Time Box:** 15 minutes - **Frequency:** Every day - **Owner:** Devign Master - **Attendees:** Devign Master, Product Owner, Developers, Designer - **Purpose:** Surface blockers and keep momentum. **How it runs:** 1. What was completed since yesterday? 2. What is being tackled today? 3. What’s blocking progress? Follow-up: Actions noted in Confluence (*Project X → Sprint XXXX*) and Slack summary shared. ## Reviewing the Work As the sprint closes, focus shifts to ensuring quality and sharing results. ### **Sprint Go / No Go (Event)** - **Time Box:** 1 hour - **Frequency:** Ad hoc, as required per sprint - **Owner:** Scrum Master - **Attendees:** Scrum Master, Product Owner, Development team involved in product, Designer involved in product, QA, either the CEO or COO - **Purpose:** Internal checkpoint to validate that the product goal has been achieved before a client demo **How it runs:** 1. Was the Product Goal achieved and validated across the relevant features? 2. Confirm deployment to QA/Staging. If “No”, pause the demo. Ensure the QA environment is clean and client-ready, with all test data (e.g. “TestingDec”, “Testing testing 123”) removed to maintain a polished and professional experience. 3. Review the demo end-to-end against Moonward quality standards. 4. Validate completion against the agreed plan and outcomes. 5. Identify any gaps, risks, or follow-up actions. 6. Scrum Master documents findings by creating relevant Jira tickets during or immediately after the session. All tickets are reviewed and agreed by the team before being committed to the sprint schedule or backlog. 7. Stakeholders vote Go / No Go. Any “No” pauses the demo. 8. If the outcome is No Go, the session is rescheduled for the following day and repeated until a clear Go is achieved. 9. Approval marks the session as complete and demo-ready. ### **Sprint Review (Client Demo) (Event)** - **Time Box:** 1 hour - **Frequency:** Every Sprint - **Owner:** Product Owner - **Attendees:** Product Owner, Developers, Designer, Client - **Purpose:** Showcase the **Product Increment** and gather feedback. **Must-haves:** - Demo from QA environment. - Work deployed & verified day before. **How it runs:** 1. Team ready 5 mins early. 2. Welcome & introductions. 3. Product Owner revisits Sprint Outcome. 4. Developers demo functionality. 5. Stakeholders ask questions. 6. Product Owner shares backlog/roadmap updates. 7. Feedback & adjustments gathered. 8. Notes documented in Confluence (*Project X → Sprint Review*). ### **Product Increment (Artefact)** - **Purpose:** The actual deliverable — code, design, or solution. - **Definition of Done:** - Shared understanding of completion. - Items not meeting DoD are not released. - Failed items returned to backlog, marked **QA Blocked**. ### **Devign Update (Event)** - **Time Box:** 30 minutes - **Frequency:** Every Sprint - **Owner:** Product Owner - **Attendees:** Product Owner, Designers, Client - **Purpose:** Quick touchpoint for transparency, roadblock escalation, and alignment on priorities. **How it runs:** 1. Team ready 5 mins early. 2. Welcome & introductions. 3. Product Owner shares progress. 4. Highlight challenges. 5. Designer delivery is reviewed and prioritised to provide the development team with work for upcoming sprints. 6. Document in Confluence (*Project X → Sprint Review*). ## Learning and Improving The cycle ends not with delivery, but with reflection. ### **Sprint Retrospective (Event)** - **Time Box:** 45 minutes - **Frequency:** Every Sprint - **Owner:** Devign Master - **Attendees:** Devign Master, Product Owner, Developers, Designer - **Purpose:** Learn from the past sprint and commit to improvement. **How it runs:** 1. Welcome & introductions. 2. Gather insights (*Continue, Stop, Start*). 3. Identify root causes. 4. Brainstorm solutions. 5. Select one actionable experiment. 6. Summarise actions. 7. Document in Confluence (*Project X → Retro*). ## The Cycle Restarts With insights captured and improvements chosen, the team returns to **Devign Inspiration** - refining the backlog once more, carrying forward lessons learned, and recommitting to the vision. Over time, these artefacts and events build not just products, but momentum. A rhythm of adaptation, delivery, and learning - the Devign Methodology in motion. #The Devign Experience At Moonward, delivery matters, but the Devign Experience is about more than delivery: it’s about how people feel while working with us. That means understanding not just what the client wants, but who they are. It means bringing structure and clarity to every interaction, so nothing slips through the cracks. It means owning outcomes with absolute focus, keeping our “desks” tidy so communication flows freely, and reducing decision fatigue with simple, repeatable templates. It means shipping often - so clients can see, touch, and shape their product in real time. The Devign Experience is deliberately different from traditional frameworks such as Agile or Waterfall. While those methods focus heavily on outputs, timelines, and rigid processes, they often place less emphasis on the human side of the project - the client relationship, the nuanced communication, and the personal context that shapes decisions. Devign prioritises understanding the client and integrating them into every step of the journey, creating a collaborative and empathetic process without sacrificing efficiency or quality. The Devign Experience is built on trust. And trust is built in the details: in how quickly we respond, how clearly we communicate, how reliably we deliver, and how well we adapt to the personalities in front of us - whether they’re bold Reds, imaginative Yellows, steady Greens, or precise Blues. This is the Devign difference: not just building products, but creating a fresh, personable, and deeply human experience. One that feels structured yet creative, professional yet warm, consistent yet flexible. Because in the end, the experience is just as important as the delivery. #Understanding the Client Understanding the client goes far beyond deadlines, features, or outputs. It means recognising their personality, their pressures, ambitions, and even their blind spots. By investing in this understanding - and documenting it. Documenting insights about the client provides benefits for both sides. For the client, it ensures they feel seen, heard, and understood - fostering confidence and trust in the team. For our team, it creates clarity, reduces miscommunication, and guides decisions in a way that aligns with the client’s goals and working style. This foundation of empathy transforms a typical project into a collaborative journey where priorities, compromises, and solutions are informed by real human context. Just as Surrounded by Idiots helped us frame the different ways people think and act, we use those insights to tailor not just our communication, but the experience itself. When we adapt to the person in front of us - whether they’re a bold Red, an imaginative Yellow, a steady Green, or a precise Blue — we create an experience that feels fresh, personable, and deeply human. That’s the Devign difference: not just building products, but building relationships that last. **1. Red: The Dominant Type (The "Doers")** Key Traits: Assertive, goal-oriented, competitive, and results-driven. Red individuals are natural leaders who thrive on challenges and like to be in control. Work Style: They prioritise results over processes and can be quick decision-makers. In an app development context, Reds might push for fast delivery and are focused on achieving goals efficiently, sometimes at the expense of details. How to Work with Them: Be direct, avoid unnecessary details, and focus on the end goal. Give them clear challenges and avoid wasting time on lengthy discussions. **2. Yellow: The Influential Type (The "Inspiring Visionaries")** Key Traits: Enthusiastic, creative, and socially focused. Yellows are outgoing, energetic, and enjoy brainstorming ideas with others. Work Style: Yellows often bring creativity and innovation to the table, making them great at coming up with new features or thinking outside the box. They enjoy collaboration but may struggle with routine tasks and deadlines. How to Work with Them: Encourage their creative ideas and make meetings interactive. Provide them with opportunities for social interaction and creative expression. Keep communication positive and open. **3. Green: The Steady Type (The "Supportive Team Players")** Key Traits: Calm, empathetic, and cooperative. Greens value stability, harmony, and relationships within a team. They are patient listeners and often avoid conflict. Work Style: Greens are great collaborators, helping to maintain team morale and smooth interactions. They may be slower to make decisions but are very reliable. They like to ensure everyone is on the same page. How to Work with Them: Be patient and provide reassurance, as they may need time to adapt to change. Create a supportive environment and avoid pressure or high-stakes situations that may cause stress. **4. Blue: The Analytical Type (The "Detail-Oriented Experts")** Key Traits: Precise, analytical, logical, and methodical. Blues are perfectionists who focus on details and accuracy. They tend to be organised and prefer structure. Work Style: Blues excel at tasks that require careful analysis and attention to detail. In an app development environment, they might be the ones focused on ensuring quality control, documentation, and problem-solving. How to Work with Them: Provide clear instructions and data-driven decisions. Allow them time to analyse information thoroughly and avoid rushing them. Appreciate their focus on quality and accuracy. Quick Summary: - Reds are fast-paced and driven, preferring direct action and quick results. - Yellows bring creativity and energy, excelling in collaboration and idea generation. - Greens focus on harmony and stability, working well with others in a steady and reliable manner. - Blues are detail-oriented and analytical, ensuring that work is done with precision and accuracy. #Taking Ownership Every project outcome needs a clear owner. Not a committee, not “the team,” but one person who takes extreme ownership of the result. **Ownership means:** - Clarity – Everyone knows who is accountable for driving the client outcome. - Focus – That owner is hell-bent on achieving the goal, removing blockers, and making decisions. - Trust – The client feels confidence because someone is visibly steering their success. - Not skipping meetings Extreme ownership isn’t about doing everything yourself. It’s about taking responsibility for ensuring everything gets done - rallying the team, making the hard calls, and carrying the outcome across the line. When ownership is clear, accountability is strong, and outcomes are delivered. #Keep a Tidy Desk A tidy desk isn’t just about physical space. In the Devign Methodology, your “desk” is your digital workspace: Slack, email, project boards, and client communication channels. A cluttered desk creates missed messages, delayed responses, and frayed trust. A tidy one keeps focus sharp and communication clear. **1. Daily Slack Clear** 2. At the end of each day, clear your Slack messages. Use simple emoji signals to keep the flow obvious: - 👀 Seen and will respond soon - ✅ Actioned and closed This small discipline prevents forgotten tasks and gives your team visible confirmation that nothing is lost in the noise. **2. Daily Email Clear** Treat your inbox like a to-do list, not a storage box. File emails into folders once they’re read or actioned, leaving only open items visible. An empty inbox isn’t about perfection - it’s about making sure you always know what truly needs attention. **3. Close the Loop** Not every message can be answered on the spot - but silence creates anxiety. If you can’t respond fully, let the sender know when they’ll hear from you. “I’ll get back to you by tomorrow” is always better than leaving someone in the dark. **4. Don’t Go to Bed Angry** Most tension in projects doesn’t come from failure - it comes from unspoken frustration. Anger is often just communication left unsaid. Close the loop. Speak the truth. Reopen the channel. Go home with clarity, sleep well, and if needed - fight again tomorrow with a clearer head. A tidy desk creates a tidy mind. And a tidy mind builds the kind of steady, reliable client experience that Moonward is known for: fresh, personable, and trustworthy. #Template what you can Barack Obama once shared that during his presidency he wore the same style of suit and tie every day. Why? Because every small choice eliminated gave him more energy for the big ones. This principle matters just as much in software as it does in politics. Decision fatigue is real. In a single day, a team might weigh technical trade-offs, design compromises, product priorities, client expectations, and business outcomes. The last thing you want is to waste headspace crafting a one-off email or trying to remember the right structure for a sprint update. That’s where templates come in. Templates don’t make things robotic; they make them reliable. They ensure that the important details never slip through, while freeing up your creativity and focus for the work that truly matters. We don’t just template tasks - we template moments of trust. Every Slack message, email, and meeting structure is an opportunity to reinforce to clients that they’ve made the right investment. By leaning on clear, repeatable frameworks, we create consistency, reduce errors, and deliver an experience that feels professional and intentional—without the noise. **What we can template:** - Slack updates – so clients always know what’s happening, and blockers are visible. - Email updates – so communication feels polished, clear, and complete every time. - Meeting structures – so no important question goes unanswered. - Our communication style – so tone is always fresh, personable, and trustworthy. Templates aren’t about limiting expression. They’re about removing friction, so both the team and the client experience the Devign Methodology as clear, thoughtful, and worth every cent. #Fortnightly Deployments A deployment is the act of releasing the work completed during a sprint into a live or test environment, making it available for the client or end users to see, test, and interact with. At Moonward, unless flagged in the Go / No Go meeting, every sprint’s outcome is deployed at the end of the fortnight. This rhythm ensures a constant flow of progress - small, focused increments released regularly. **Fortnightly deployments mean:** - Faster visibility – Clients see results quickly, not months later. - Earlier feedback – We learn what’s working (or not) while there’s still time to adapt. - Lower risk – Smaller, regular deployments reduce the chance of big failures. This cadence keeps momentum high and trust strong. The client isn’t left wondering when something will arrive - they know exactly when to expect progress, and they’re invited to respond in real time. #Remember The experience is just as important as the delivery. The _experience_ is just as important as the _delivery_.