The Catalpa Handbook
  • The Catalpa Handbook
    • Handbook guidelines
  • 1. ABOUT CATALPA
    • 1.1 About Catalpa
    • 1.2 Vision, Values and Strategic Plan 2022
    • 1.3 Governance at Catalpa
    • 1.4 Organisational structure of Catalpa
    • 1.5 Our projects and key contacts for each
    • 1.6 Our key products
      • Bero
        • Content
          • Exams
          • Targeting Content to Users
            • Resizing images for Bero
        • Design
        • Requirements
        • Theming
      • Gathr
      • Openly
  • 2. OUR PEOPLE AND HOW WE WORK
    • 2.1 How we work and the tools we use
      • Google Drive
      • Trello
      • Github
      • InVision
    • 2.2 Communicating internally
      • All Hands Stand-up (weekly / Mondays)
      • Tutorial Tuesdays
      • Show & Tell
      • Guide to Slack
      • Team meetings
      • Other Events
    • 2.3 Mission Driven Teams
    • 2.4 Recruitment and Onboarding
      • Hiring Guidelines
    • 2.5 How we support our people to thrive
      • Onboarding a new hire
        • Onboarding Trello
        • Onboarding buddy guide
        • 30/60/90 Day Plan
      • Goal Setting
      • Regular work/task based 1X1's
      • Quarterly Catch Up's
      • Feedback
      • Managers - Managing Underperformance
    • 2.6 Offboarding
    • 2.7 Leave and public holidays
      • Leave
      • Public Holidays
    • 2.8 Supporting our Mental Health
    • 2.9 Working from home & remotely
    • 3.0. Learning & Development Allowance
  • Page
  • 3. EXTERNAL COMMUNICATIONS
    • 3.1 Guide to Communication
      • Describing Catalpa
      • Guide to photography
      • Guide to social media
      • Writing: style guide
      • Writing: grammar
    • 3.2 Procedures for the collection, storage and use of stories, photos and video
    • 3.3 External Complaints and Feedback Policy
  • 4. PARTNERSHIP AND GROWTH INCLUDING BUSINESS DEVELOPMENT
    • 4.1 Introduction / overview
    • 4.2 Pre-bid stage including networking and partnering
      • Networking
      • Positioning for priority bids
      • Tracking bid opportunities
      • Partnering
        • Partnership brokering
        • Due diligence of downstream partners /subcontracting agencies
        • Pre-bid agreements
    • 4.3 Go / No Go
      • Go / No Go meetings
      • Selection criteria and guidelines
    • 4.4 Tender planning and preparation
      • Project planning and design pre-submission
      • Key templates and links for bid planning and preparation
      • Bid Writing - full proposal or concept note
        • How to appoint an external bid writer
        • Key templates
        • Commonly required building blocks / required materials for tenders
        • Guides
    • 4.5 After a bid has been submitted
  • 5. PROJECT AND PRODUCT CYCLE MANAGEMENT
    • 5.1 Introduction
    • 5.2 Planning and pre-submission design
      • 5.2.1 Monitoring, Evaluation & Learning
        • Project-level M&E
        • Catalpa's organisational approach to MEL
      • 5.2.2 Risk Management
      • 5.2.3 Cross-cutting issues in projects
        • Gender equality
        • Disability inclusion
    • 5.3 Mobilising a new project
      • Handover from BD team to PM team
      • Program Summary Document
      • Team Kickoff Meeting
      • Team Charter
    • 5.4 Post-contract implementation
      • Stage 1 - Learn: Design and Discovery
        • Human Centred Design
        • Our Tools
        • Creating a product
      • Stage 2: Create and Ideate
        • Our model
        • Agile Project Management
          • Getting started
          • Product design and development phases
            • 0. Contracting
            • 1. Learn
              • 1.1. Prepare
              • 1.2. Discovery
              • 1.3 Empathise
            • 2. Create
              • 2.1 Ideate
              • 2.2 Implement
            • 3. Refine
            • 4. Evaluate
          • Product Roadmap
          • Defining releases
          • Create the solution
          • Make a global plan
          • User Stories
          • Prototyping
          • Incremental development
          • UX & UI
          • Conducting tests
      • Stage 3: Refine and Release
        • Introduction and overview
        • Data privacy on a project basis
        • How-tos
          • Retrospective
        • Scrum methodology
          • Daily standup
          • Sprints
          • Sprint prep
          • Sprint meeting
        • Release
          • Epics
          • Epic selection
          • Epic planning
          • Product Q&A, deployment and implementation
          • Make it available
          • Delivery
      • Stage 4: Evaluate
        • Define the maintenance support plan and team
        • Customer support
        • Ongoing user data collection and analysis
      • Glossary of Terms
    • 5.5 Project close-out
      • Product transition and handover
      • Transition to governmen
      • SMA
      • Licenses / handover documents
      • Migrating to Gov owned data-center or cloud hosting
  • 6. POLICIES AND PROCEDURES
    • 6.1 Register of policies and compliance
    • 6.2 Policy Development Procedure
    • 6.3 Code of Conduct
    • 6.4 Data Privacy & Storage Policy
    • 6.5 Human Resources Policies
      • Breastfeeding and Work Policy
      • Occupational Health and Safety Policy
      • Domestic and Family Violence Policy
      • Gender Equality Policy
      • Disability & Discrimination Policy
      • Use of Catalpa Vehicles Policy - PNG
      • Anti-Bullying, Harassment and Discrimination Policy
    • 6.6 Safeguarding Policies, Templates and Training
      • Child Safeguarding Policy
      • Prevention of Sexual Exploitation, Assault and Harassment Policy (PSEAH)
      • Safeguarding templates
      • Safeguarding training
      • Safeguarding procedure for collecting, storing and using images / stories
    • 6.7 Financial and Asset Management
      • Fraud & Corruption Policy
      • Vehicle Use
    • 6.8 Complaints and Feedback
      • Internal Complaints and Feedback Policy
      • External Complaints and Feedback Policy
      • Whistleblower Policy
    • 6.9 Contract Development Procedure
Powered by GitBook
On this page
  • Minimum Viable Product (MVP)
  • Building Incremental Software
  • Planning for the available timeline

Was this helpful?

  1. 5. PROJECT AND PRODUCT CYCLE MANAGEMENT
  2. 5.4 Post-contract implementation
  3. Stage 2: Create and Ideate
  4. Agile Project Management

Incremental development

Minimum Viable Product (MVP)

This is a definition made popular by Eric Ries on his book "The Lean Startup" — a great read for anyone involved in creating new products. His own definition is as follows.

The minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.

Despite the name, it's not exactly about creating the smallest product possible but rather about building the minimum amount of functionality, using the least amount of iterations, that will allow us to validate what fit the people that will use it.

Planning for and building an MVP adds some overhead and one might be tempted to ignore this step. In reality, there are a number of good reasons for not implementing an MVP — the main one being that the product is already simple by design. However, in most cases, the learnings that can be obtained from a well planned MVP will definitely be helpful when expanding the product later on.

Building an MVP isn't exactly the same as building a product using small iterations.

Learn more about incremental development here

Building Incremental Software

While building an MVP, one wants to make sure that every decision is informed. It's pointless to keep progressing towards a result that might be void of value. To tackle this challenge, efficient teams have been leveraging build-measure-learn feedback loops.

The Build-Measure-Learn feedback loop is a technique that helps you to realise when you've got things wrong, before it's too late to turn initial failure into eventual success. In practice, the model involves a cycle of creating and testing hypotheses by building something small for potential users to try, measuring their reactions, and learning from the results. The aim is to continuously improve your offering so that you eventually deliver precisely what those that will use your product want.

Plan — Obviously, before you can build anything, you need to plan for it. This is the moment when initial hypothesis are formulated, based on a more or less informed discovery phase.

Build — Once the hypothesis is formulated, the team can start creating the MVP.

Measure — By adopting an iterative approach, you create several opportunities to test the initial assumptions and understand if they are being successful.

Learn — With each iteration, there's a new opportunity to learn if the product has acceptance, proving its success. If you find that it doesn't, it's time to try to understand why and pivot in a different direction.

The lesson learned may come in different sizes, from small pivots to having to completely toss a few features. This shouldn't deter the team from moving forward and keep trying to find what will work. Evidently, the greatest cap to this process is the available runway — timeline, funds or both. You have to learn to adapt your cycles to the available runway.

Planning for the available timeline

People often start a new challenge trying to estimate how much time it will take. This approach, while innevitable when it comes to assess what resources are needed, has the potential to push a team away from practicing an iterative attitude towards the problem.

A better approach is to understand how much time is available for development. Knowing this, you should scope your solution towards that reality, setting the necessary deadlines along the way so that one epic doesn't take the whole timeline. Doing this allows the team to more easily understand progress and forces them to keep making decisions along the journey that will shape the product into what reality allows.

As a consequence, if the team is able to work efficiently and the timeline allows, you can expect to deliver a complete product in a timely fashion. On the other hand, if unexpected delays happen or if the team finds out that the initial goal was too optimistic, then you can rest assured knowing that the best decisions were made so that the team delivers the best possible, most relevant result.

PreviousPrototypingNextUX & UI

Last updated 11 months ago

Was this helpful?

It's quite common for our programs to have a timeline to which development is bound to. The initially proposed solutions that we plan to implement are often described at a very high level which can lead to an overwhelming start while trying to understand what the next step is. Take a look at the manuals to find out more about how to plan.

Agile Project Management