We borrow heavily from the Agile methodology in our own unique approach to projects.
- Commercial Terms
- Bug Classification
- Design Guidelines
- Go Live Checklist
- Harvest Forecast
- Roles and Responsibilities
- Running a Demo
- Trello
- Continuous Improvement, Support & Hosting
We have learnt that the best products are built when we work side-by-side with our clients, as a partner, in a collaborative and iterative manner. This proximity promotes trust and drives enthusiasm to build something awesome!
The Big Reveal at the end of a traditional waterfall project has proven time and again to be a set-up for trouble. If what the developer understood is different than what the client expected, it is expensive to change course after months of development. An iterative approach allows for feedback on a daily and weekly level; if we miss the mark on a sprint we only loose one week, not months.
We trust our team to manage their own time within their sprints. This means they should be escalating to the team as soon as they see delays or unexpected challenges. Proactive communication ensures we can deliver support where needed and make the right decisions to keep the project on track.
To play their best, pro-athletes need to recover between games. We believe that our professionals need to recover between sprints. We work hard during the day, but strive to keep a sustainable pace and weekends work-free. That said, when the chips are down we pride ourselves on putting in the effort to get critical milestones across the line.
We request our clients join us on Slack and GitHub, so they can follow progress as it happens and be responsive to any questions. This is essential in shortening feedback loops and promoting iterative development. We don't maintain any parallel 'black-ops' back channels to exclude the client. A shared conversation between the client and our team is key to ensuring that the technical team understand the functional drivers for client scope requirements.
- Project kick-off
- Discovery
- Backlog preparation
- Sprint planning
- Standups
- Backlog grooming
- Sprint review
- Retrospectives
We start all projects with a collaborative discussion where we establish what success looks like and explore the challenges in getting there. We bring the technical team into this discussion so they are clear on the business goals of the project and can identify those challenges.
- Roles and responsibilities - introductions to the project team
- Overview - goals and success metrics
- Scope and deliverables
- Project management process
- Requirements and dependencies
- Timelines / Project Plan
- Risks (new technology, changing scope, unknown codebase etc.)
- Define client's Information Security requirements
- Communications
- Often begins with a workshop with the customer or stakeholder
- Designers and engineers involved from the start
- Output will often be draft user stories, prototypes, story boards etc
We break-down the tasks into weekly sprints, ordered by priority. We aim to encapsulate specific feature sets in each sprint, so at the end we have something tangible that we can start testing/playing with. Work packages should be broken into small enough pieces to be completed in one day. This enables us to clearly see if scope is being completed in line with the sprint expectations.
- This will be a collaborative effort
- Recommended format for user stories:
- As a… I want to… so that…
- Acceptance criteria where needed
- Relevant designs in the card
- All the information required to begin work on the card should be in place at the beginning of a Sprint
Sprints are both fluid and collaborative and are not enforced, arbitrary deadlines. Working in this manner ensures we attack the most relevant scope, which can change during the project. We understand and expect that the project scope may change during development and being flexible will allow us to build the best possible product.
- Sprints are typically 2 weeks in length
- Sprint planning will be where we discuss the stories and agree what we’ll work on in the next sprint
- Involvement of the whole team is essential - should last an hour
- Video call
- Only user stories that are ready to be worked on will be taken forward
- Opportunity to discuss implementation and design questions
- Estimate the size of each task
- Commit as a team to delivering a set of stories for the sprint
The projects we work on typically require multiple skill-sets, from designers through to back-end developers. We don’t operate with project managers in the traditional sense, but each project will have an advisor.
The advisor is typically not ‘in the weeds’ and will check-in weekly to offer a fresh perspective and provide any advice where required. If there is a product manager they will provide the business scenarios, but the development team will determine how to best implement. We will have a senior developer on each project, who use their experience to act as solution architect and coach the rest of the team.
Day-to-day, the team working on the project are responsible for communicating with the client and making sure the work gets done. We start each day with a stand-up in Slack to get the team on the same page and help overcome challenges together.
- Run daily by designated Scrum master
- Video conference recommended
- Participants update on cards they’ve been assigned to and if they have any blockers
- Maximum standup length is 15 minutes. If further discussion is required it should be followed up in a separate call
- 1 or 2 times a week, 30 mins
- Product team creates cards
- Led by product manager
- Design and engineering team feed into cards
- Each sprint presented by the team to the client or internally
- Run through completed stories and highlight those that are not
- Demos for all completed stories (even back-end tasks)
At the end of each sprint we run a retrospective to extract any relevant lessons, which are shared across DVELP to ensure we continuously learn from our mistakes and our successes.
- Reviewing previous retrospective actions
- What went well? What could be done better from the previous sprint?
- Agree measurable actions
- Assign responsibility
- Retrospective recorded in Retrospective Trello board and shared in Slack channel
- Flexible and varied