Skip to content

Latest commit

 

History

History
129 lines (54 loc) · 9.09 KB

rules.md

File metadata and controls

129 lines (54 loc) · 9.09 KB

Red Ant Rules of the Road

1. Purpose

Welcome to Red Ant. We look forward to partnering with you on many successful digital projects. The aim of this guide is to explain how we will work together - what you can expect from us and what we need from you.

This document forms part of our agreement with you.

2. How We Work

Red Ant will provide an outline and time estimates of all work to be performed in the Statement of Work ("SOW").

We approach our work with a pragmatic Agile approach. Agile has been adopted worldwide as an ideal approach to efficiently building software. Agile helps teams respond to unpredictability through incremental, iterative work and allows for user and client feedback during the development.

This means your project will be broken into Sprints - that are blocks of time (usually 1 or 2 weeks) with a specific goal to be achieved based on the information available to us when work commenced.

The goals, time estimates and cost of each Sprint will be detailed in the SOW. These goals, time estimates and costs may vary as each Sprint progresses as a result of new information becoming available to Red Ant. At the end of each Sprint therefore, we will review progress, discuss any necessary changes or new information, and plan the goals for the next Sprint. One purpose of having this regular Sprint discussion is to review achievements, time estimates and time spent in light of progress and any new information.

3. Communication

Regular and open communication is vital to our relationship. The project will include each of the following communications and must involve all key people who are stakeholders in each project:

  • Task based questions - these will be managed in our project management tools and come to you as emails.
  • Regular Sprint planning sessions - at the start of each Sprint of work (so every week or second week depending on Sprint duration). These meetings must either be in person or as a screen conference.
  • Sprint showcases - at the end of each Sprint, we will showcase work done and review progress, as well as plan the next Sprint in detail. These meetings must either be in person or as a screen conference.
  • Every 3 months a Road Map meeting where we can discuss the progress of your project(s) as well as plan for future developments. Ideally these will be face to face meetings.

These meetings are essential to our Agreement and the progress of the project. Failure to provide feedback at critical time points can cause delays and cost increases down the track.

We like to work closely with our clients. We may require information, content, customer data at critical points in time.

4. Key People

The Key people who will be working on your project and their key responsibilities are set out in each Statement of Work.

Whilst it is our intention that these people will perform these roles throughout the term of this Agreement, we both acknowledge that this may not always be possible. We will advise you as soon as reasonably possible of any changes to these key people and of any known leave (and alternate contacts during periods of leave). After a period we may rotate some people, so more people on our team get exposure to your project and develop knowledge on how it runs.

You must also let us know if there are any changes in your team especially people responsible for supplying information and approving any work.

5. Standard working hours

Red Ant is based in Sydney, Australia. Our offices are usually contactable from 9am - 5pm, Monday to Friday, excluding public holidays.

Most of our work is conducted at these premises, during this time. However, we are happy to work with you on projects that may be primarily based in different time zones or countries, or may need Red Ant's attention on the weekend. Please raise it with your project manager if this is your situation, so this may be included in our estimate.

6. Photo Libraries, Source Materials and other Tools

You warrant and represent to us that you and, consequently, we are entitled to use anything you provide to us in the course of the project such as tools, content, images or information (collectively "the information"). You warrant and represent to us that you have the necessary licenses and approvals to use the information, and you grant Red Ant the right to use, reproduce and modify the information in the process of developing and maintaining your project. This is an essential term of this Agreement.

Taking an example of a photo from an image library. Some images you buy once and own outright. Some you're "renting" for a period of time or specific context. You agree that it is your sole responsibility to ensure that you have the necessary licences and approvals to use and continue to use these.

If we purchase images on your behalf, the responsibility for maintaining licences for the images will ultimately be yours once the work has been completed.

7. Standard web browsers

This is a common question - which web browsers will my project be tested in. Web browsers are continually changing and new versions being released. There is a common published standard, but unfortunately each of the browsers and versions have their own idiosyncrasies. This means that making something look right in browser X will break it in browser Y.

We will develop to common W3C standard for web development. We will also check in the current or most popular version of the top 3 popular browsers:

  • Mozilla Firefox
  • Google Chrome
  • Apple Safari

If there is a reason that you need the project to work on a particular version of a particular browser or device, please let us know prior to commencing the work and we’ll add it in the Statement of Work as part of the project brief. This will mean some additional time will be allocated to testing and making changes for that browser. If you notify us after we have commenced we will need to revise our Statement of Work and estimate.

8. Bugs and Warranty of work

A software bug is an error, failure or fault in software that causes it to produce an incorrect or unexpected result, or to behave in unintended ways.

Bugs are a very normal part of any development process.

Just as we plan and allocate development time to writing code for the initial work, we also need to do the same for finding, testing and resolving bugs.

To be clear: the work involved in addressing bugs doesn’t come free. As a basic guide, we normally allocate about 10-15% of the development budget for this. We’re also working within your project budget. If extra work is required, this will cost more.

Our work will be of high quality and we will warrant that what we will deliver will be of a suitably high standard. Here are three (hypothetical) examples to cover common scenarios:

Background: In your project, you need a button that turns red when a user clicks it.

Example 1: We estimated time to build and test the button, and our actual effort of code + testing was within the estimate. We have confirmed we have fully tested the feature, and we hand it over and tell you "when you click this button, it will turn red" in our test coverage summary. And when you click the button, it turns green. Or when you click it, it turns "fred" instead of red (a silly typo).

This is something we'll fix at no cost.

Example 2: we have created the Red Button feature, and your team starts using it. They discover if you click on it really quickly five times, it stops working. This is a bug, but isn't a scenario we had anticipated or tested for, and work is required to address this. This is not free - additional development time is needed.

Example 3: we have created the Red Button feature, and when your team starts using it they realise that after the first click, the button will always be red. No one had thought about what should happen after you click. Perhaps someone on your team had an expectation that the button would automatically turn itself off again after a period of time. Perhaps you feel that this was really obvious that it should turn off again. But remember that hindsight is a wonderful thing. This could also be described as a bug, but the work to make it turn off again automatically isn't free.

We try to be as clear as possible about what the features are that we're working on, and how they have been tested. You’ll find these in the Test Coverage section of your Project Summary.

9. Your Obligations

To help us do our work, you will:

  • provide us with all instructions, documentation and technical information necessary for us to provide the services to you;
  • use reasonable efforts to ensure that all your information provided to us is accurate, up-to-date and complete;
  • ensure that, if necessary, we and our employees, agents and contractors have full, free and safe access to your premises at all reasonable times for the purposes of providing the services to you and performing our obligations under this Agreement; and
  • co‑operate fully with us and our personnel regarding the provision of the services, and provide adequate facilities on your premises and all reasonable assistance to enable us to perform our obligations under this Agreement; and
  • attend all meetings scheduled.