How we work
Our delivery process has evolved a lot over the years, in recent years, we have heavily invested in building a strong culture around agile principles.
However, we acknowledged that this wasn’t enough, with many agencies playing lip service to agile, we wanted to be different and we pride ourselves on an agile process which allows both flexibility and control.
With help from the Agile Business Consortium, we have adapted the DSDM framework to successfully deliver on time and on budget projects for our clients.
Our projects consist of a number of key phases: Pre-project → Feasibility → Foundations → Design Direction → Evolutionary Development
All projects consist of a Feasibility and Foundations phase before we commence development.
What is Foundations?
All our projects start off with a Foundations phase. Foundations is a term in DSDM - the agile method we follow at Deeson, in other places this phase might be referred to as discovery.
The primary purpose of this phase is to
“ensure we design and build a solution which is fit for purpose and we move fast when we start development.”
Here are some of the activities that typically happen in this phase
Stakeholder interviews
User interviews
Desk research
Solution design workshops
Wireframing
User journey mapping
User story mapping
Prototyping
User testing
Design direction
Technical investigations also known as technical spikes
Project planning
However, there is no one size fits all and therefore the activities will vary project to project depending on the size of the project, how well defined the solution is, and how much research has been done to date.
Instead of focusing on deliverables, our teams are encouraged to focus on the outcomes which will ensure everyone involved is confident to commence development. These outcomes are:
Design direction signed off
Technical strategy defined and challenges de-risked
Development environments set up Hosting
Project readme
Base site setup
Building automation tooling (path to live)
First Timebox of user stories refined and estimated
A component list which reflects our current understanding of the scope of the project
Epic sizing to convey split of budget across epics
Testing strategy
A delivery plan
So who is responsible for what?
A more detailed list of tasks and accountabilities can be referenced here.
Things to factor in / consider as part of planning
Billable travel
If you’re going to be on-site with the client make sure that for any workshops your Forecast time reflects the amount of time you’ll be billing e.g. it factors in travel time
Handover between lead developer and rest of the development team
This needs to be factored both into the budget for Foundations and in Forecast
How we manage projects
We use JIRA, as our project management tool. JIRA can be configured in a few different ways. We have adopted a dual board process which separates the refinement of tickets from tickets which are ready to be worked on. Often agile is an excuse for laziness and tickets can often make it into development without clear requirements or having had the insights from a multi-disciplinary team. This workflow ensures the key project roles all have the opportunity to input into a ticket before it’s worked on.
The prep board
Purpose: this is where you can view upcoming tickets planned for future Timeboxes.
Activities that are undertaken here: acceptance criteria are added, designs are added, estimates are provided and once approved the tickets are moved to ‘Ready for sprint’. At this point, we deem the ticket ready to be worked on. Tickets are then either moved to the next Timebox or to the backlog.
The work board
Purpose: this is where you can view tickets currently being actively worked on during a Timebox.
Activities: this is where tickets are implemented, internally tested and then reviewed and approved by yourself.
The backlog
Purpose: This is a holding space for tickets that have been fully refined i.e. have been through the prep board process and are ready to be worked on in a future Timebox.
Timebox best practice
All team members are responsible for ensuring:
Tickets are assigned to the correct individual
Tickets are in the correct column i.e. the status reflects the progress of the ticket
When you move a ticket you also add a comment explaining what the next action is and for who e.g. “Rachael this is now ready for you to test” or “I’ve fixed that issue, please can you re-test”
Time remaining is accurate and realistic (this should be updated at least once per day)
When a ticket is ready to be tested you notify the person responsible for testing on your project via Slack rather than JIRA
When a ticket fails QA - you take responsibility to screen share or pair with a designer to avoid JIRA tennis
You raise blockers* on stand up or on Slack and bring that attention to both the lead developer and Delivery Manager on the project
You manage your allocated budget and inform the lead developer and Delivery Manager at the earliest opportunity if you think you need more or less time scheduled
You raise to the lead developer / Delivery Manager if a ticket goes overestimate - this will allow us to ensure the Timebox goal is still achievable and don’t put unnecessary pressure on you or the team if something has arisen that we couldn’t have planned for
Tracking time and budget
Harvest
Harvest is where you log all your time, both billable work and nonbillable. This is what we use to invoice clients, it’s therefore really important that your timesheets are accurate and that you’re logging your time to the correct project.
Some clients request a breakdown of where the budget was spent at the end of each month, it’s therefore important that you also add a clear description detailed what you were doing - where possible reference a JIRA ticket.
JIRA
JIRA has its own time tracking tool, we don’t use this data for invoicing but we do use it regularly to check we’re on track to deliver each Timebox. Most developers find it useful to log time in Harvest and then update JIRA once at the end of the day or before stand up to match their Harvest.
The time remaining on a ticket will normally automatically update when you log time to the ticket, however, sometimes the time remaining will not match the time you’re exactly anticipating to spend e.g. a ticket could have been more or less complex than you had anticipated. In this eventuality, it’s also important to update the time remaining to match how much time you think you’re likely to spend on this ticket before it’s considered done.
When a ticket passes through PR/internal testing, you’ll be encouraged to reduce the time remaining if you have more than ~30 minutes left so we’re not over accounting when we’re looking at how much work we have left to do.
Forecast
Forecast is a scheduling tool, this is where you’ll be able to see what you’re working on from day to day and week to week. You’re in charge of making sure Forecast matches up with what you’re planning to work on. Harvest and Forecast integrate nicely together which enables project teams to see when they’re likely to overspend or underspend. individual team members are responsible for managing their own budget allocations.
How do I manage my budget?
Within Harvest, you should have access to view each project you’re working on. Under the ‘Team’ tab, you should see your name and allocated budget and spend to date with the remaining budget on the right. If you hover on the Forecasted spend you should see how many future scheduled hours you have. You can then compare your forecasted hours with your remaining budget, your Forecast spend should now exceed your remaining budget.
If it does and you think you need the full amount you have left scheduled - let your delivery manager know.
If you have more time scheduled than you think you need, update your Forecast to reflect that.
Stand ups
A good stand up is more than just a status update or a time to do JIRA admin - it’s a useful and productive conversation about delivery. A chance to collaborate, ask for help and ensures team members are joined up i.e. working as a team delivering against a Timebox goal rather than individuals delivering tickets
What we expect from you
You're on time - ideally, arrive a minute or two before the stand-up starts
Mute yourself when you’re not speaking
You’ve reviewed the board and happy that the board is up-to-date
You can clearly and concisely articulate the following: What you did yesterday
What you commit* to achieve today and what involvement you’ll need from the team to make that happen
Any blockers that may impact the success of the Timebox
*Commitments
Be specific about your commitment for the day e.g. I’m working to get these into “internal testing” or into “client acceptance”. It’s very difficult to Forecast and plan if you only state the ticket you’re planning to work on that day.
However, be realistic - don’t commit to more than is realistic or unachievable, it’s fine to say I’m unlikely to get this done today because of ‘x’
What is a blocker?
Anything which is either getting in the way of you delivering your work and/or could potentially have an impact on the budget or commitment of the Timebox. That could be but is not limited to:
A ticket taking longer than estimated
Being blocked by another team member e.g. you’re waiting on a PR to be reviewed or something to be tested
Competing project priorities i.e. your being pulled in multiple directions
Unclear requirements on the ticket
User stories - best practice
Acceptance Criteria are written in the Given, When, Then format
Link to Zeplin
Test scenarios
Testing notes in the comments
Estimate (ideally no longer than a day)
Pull request best practice.
Pull requests are an opportunity for you to receive feedback on your work. When you are a part of a team they are a good mechanism for ensuring that everyone on the team is aware of changes that are being made to the code.
When you finish the development work on a ticket you should submit a pull request using Bitbucket. Add all of the team members as reviewers and post a link on the project’s internal Slack channel. Drag the ticket to the PR column in Jira but don’t reassign it - getting a review is still your responsibility.
Pull requests are not a sign-off process, you are responsible for the code that you write and it’s up to you how you choose to respond to the advice that you receive.
When you are working on a task as part of a timeboxed project then you should submit a pull request for the work once it is completed. The code should be reviewed by at least one other team member, generally a lead developer, before you merge.
As a reviewer you should try to respond quickly to pull requests once they are submitted, balance the fact that your teammate is blocked until you review with the need to complete your own work and avoid distractions.
When you review a PR look out for:
Inconsistencies in approach,
Sloppiness or code quality issues (e.g. coding standards not met, debug left behind)
Regressions, or fragile code which is likely to regress in the future
Security weaknesses.
Testing.
Developers are responsible for:
Ensuring front end work matches Zeplin (this is where the signed off designs are)
All Acceptance criteria is met
That the functionality works i.e. you’ve tested the functionality described in the acceptance criteria with real test scenarios
You’ve undertaken device/browser testing on the agreed browsers for the client.
You’ve added testing notes to the ticket before passing it over for internal testing. This is very important! These notes should both demonstrate you have completed the task assigned to you and provide the steps required for someone else to replicate the steps to demonstrate it for themselves. This is your own sign off as a professional to say the work is complete to your satisfaction and no further work is needed. A good set of testing notes will include links to the pages to go to to see the finished product on a hosted test environment, a discussion of the options or any considerations that may need to be taken into account and screen shots of the working feature on the hosted test environment.
Tickets should then be passed for usability and design testing by your UX/design leads on the project - this is a final sense check to check it makes sense from a usability point of view and that the acceptance criteria.
Note, we have a company browserstack account that can be used for cross-browser and device testing.
Test criteria example: https://deeson.atlassian.net/browse/HNEC-18
Timebox kick-off agenda
Things to consider before kicking off the first Timebox of a new project:
Does everyone know when the Timebox is finishing and when the demo is?
Does everyone know what’s expected of them in terms of demoing their own work?
Share URL/testing login details and pin on the ext channel when first ticket is ready to be test
Is everyone clear on the workflow?
Is everyone clear on what’s expected of them prior to stand up e.g. updating time remaining, ensuring tickets are in the right column and tickets are assigned to the correct person?
Is everyone is clear on the browsers compatibility list?
Is everyone is clear who is going to undertake internal testing?
Is everyone is clear on process for adding testing notes and what good looks like?
Is the client clear about different outcomes for testing a ticket depending on if it passes or fails and how to add a bug?
Does the team know what the definition of done and definition of ready is for this project?
Things relevant to all Timebox kick off meetings
Does the Timebox goal feel realistic / achievable? A quick sense check with the team e.g. how confident are you of being able to fulfill the commitment? If there’s any ambiguity discuss it.
Are there any dependencies between stories?
Are the stories ordered in the order it makes sense to progress through them?
Is there a clear Timebox objective/goal that all the team feel able to commit to?
Are all the stories ‘Musts’ for the project?
Appendix: Glossary
Timebox: A two-week work cycle focused on delivering functionality that meets a specific goal. In theory these packages of work should be able to be released independently.
Spike: A period of time allocated to explore technically complex work to help us de-risk before we start a task.
Last updated
