How we work
We work with Agile methodologies. Our process is influenced by Scrum, Kanban and XP, taking the core principles and leaving behind some of the more prescriptive doctrine so that we are able to tailor our process for the project and client we’re working with.
Our processes are designed to make our team more efficient, more focused, and more consistent. The more efficient we are the faster we get results; the more focus we have the better the code; and the more consistent we become the more predictable our output and accurate our planning.
Agile principles that guide our process
Our process is collaborative. We work closely with the client and other stakeholders from project discovery, through requirements gathering, development, testing and delivery.
Our process is transparent. Our clients know what we’re working on and how long it takes. We’re always available to answer questions and you’ll have the final say on prioritisation.
Our process is user-centered. All project requirements are cast in terms of end user value, from the way requirements are written to the way their acceptance criteria are tested.
Our process is iterative. We work in cycles with regular deliveries. We periodically review the product with you, and are able to change priorities and introduce new requirements.
What are the benefits?
Being Agile helps us reduce risk. With short sprints of well-defined tasks we are able to start delivering working software as soon as possible. We track metrics on the team’s performance so that we can make evidence-based estimates.
Being Agile helps us manage change. At the end of each sprint we reassess the requirements with the client. Features and tasks can be re-prioritised or changed according to business need, user feedback or changes in the budget.
Being Agile helps us deliver maximum value. The client can weigh the business benefit against relative cost of each task when prioritising. Tasks with greater business benefit can be identified and completed first. Resource is directed to the most effective areas and requirements tailored to fit the budget.
How does it work?
The diagram below describes a basic project cycle. Each project begins with a discovery phase and is followed by any number of iterative development cycles. Each cycle or ‘sprint’ is 2-4 weeks.
The discovery phase is undertaken at the beginning of the project. It will consist primarily of requirements gathering workshops, interviews with key stakeholders and users of the end product. The key output of this phase is the Backlog. This is a set of all the identified requirements written as ‘user stories’. Writing requirements from the user perspective forces the project team to think about who the feature is for and why it’s important.
We host the backlog on an issue tracking tool. The ‘Product Owner’ - a team member from the client side - is responsibile for prioritising the backlog each sprint.
The backlog is a working document, and can be amended at any time during the project.
At the beginning of each sprint we hold a ‘Sprint Planning’ session. The whole team attends Sprint Planning and it’s where we discuss the highest priority stories in the backlog, specify them in detail, create tasks and estimate them. Each user story is given acceptance criteria or a description of the test it must pass to be considered ‘done’.
We estimate tasks using a relative points based system rather than hours required. We project how many points can be achieved in a sprint by using the velocity metric. This is an evidence-based technique which averages our past performance across sprints and helps improve the accuracy of our estimates over time.
We start each day with a daily scrum. This is a time-boxed stand-up meeting of no more than 15 minutes. Each member of the team covers what they did yesterday, what they will do today, and what blockers they may face. These meetings enable us to track progress, remove obstacles and keep the team motivated and on-task.
At the end of each sprint, we do a ‘Sprint Demo’. We run through each user story and demonstrate how it’s been implemented. The Product Owner decides whether to accept the implementation based on the acceptance criteria.
If accepted, the user story is considered done. A task must be 100% complete to be done; partially complete stories do not have end-user value.
We also hold a ‘Sprint Review’ session, where all team members are invited to discuss what went well, what could have gone better and what actions we can take to improve the process.
Potentially shippable product increment
Following the sprint demo, all tasks considered ‘done’ can be delivered to the end user.
Atchai were extremely professional, patient, and showed a great understanding of our often changing requirements and priorities. Their Agile approach to development, along with regular and effective communication allowed us to accommodate change and react quickly to evolving business and user requirements.
Oliver Holmes, Turner Broadcasting