Hi, I'm Sophie and I started at Meanbee as a Project Manager over 4 years ago. Back then it was 5 developers and myself trying to navigate the path of a small start up. Over the years we have honed our workflow and project management process; which I would like to share today. We started investigating Agile not long after I started and found it was a good fit for our business and the majority of our project work. We try to use the framework of Agile to influence our day to day project management and to organise this we use Atlassian's Jira & Confluence software.
One of our most significant changes to the business was moving all of our clients are on to a monthly retainer which allows us to block book time in to work on their sites. It works well as it gives both us and the client a timeline to work with and allows us both to get organised. It also means that the level of work being done is consistent and we can plan big ticket items well in advance.
Pre-planning
To kick things off my first action is to discuss priorities with our clients and understand the aim of the sprint. Then we either draw from the backlog or create new tickets with as much information as possible. Time allowing, I will then ask the team lead to review new tickets so that we can ask questions to build requirements or add technical recommendations. Our team leads are so important as they provide technical advice and suggestions to streamline our clients' work. They also assist with gleaning requirements for tickets and scope out ways to approach complex issues.
Sprint planning
Whether we are arranging to do a couple of minor fixes or a large upgrade, we always start with a sprint planning. This involves the PM, team lead and developers that are working on the sprint getting together to discuss issues that are to be worked on. We talk through each issue, agree on the ‘definition of done' for that ticket and discuss the implementation method. Recently we have started noting the suggested implementation so that this is not forgotten before the issue has been started. We assign each issue a time estimate that we can review at the end of the sprint. We like to have 'sprint goals' for some projects i.e "To align email designs with brand guidelines and increase conversion rate with recommended products". This helps us focus on the bigger picture of what we want our work to achieve rather than individual tasks that can become detailed orientated and lose the sense of our overarching objective.
At this point, we ensure that the total time estimated for all tickets fits within the client's monthly budget and make them aware if a high priority issue will push them over. We order the tickets in priority order so that the whole team knows how to work through the issues.
We can also use sprint planning to allocate certain issues to specific developers so we can utilise their individual skills and strengths. We also try to book in a deployment date so that everyone has a clear picture of the timeline and what we are aiming for. The deployment date is often susceptible to change due to client schedules or blockers on our side, but we find that it helps motivate developers when there is a clear end in sight whilst also setting the client's expectations and encouraging regular deployments.
Sprints
Work in progress
We use JIRA software to track our workflow.
Our fantastic developers work through the tickets in the sprint and hopefully complete each issue using the method that was discussed in sprint planning. Before sending over to code review our developers write a test plan. These provide steps with which the acceptance criteria for the ticket can be validated.
Code Reviews
We have always believed that code reviews are crucial to our business and the success of our clients' sites. Not only do they ‘sanity check' the developer's method, but they allow others to gain insight into a project they might not have touched for a while. Code reviews often lead to a general group discussion on best practice and alternative implementations. The act of ‘touching base' with a colleague provides confidence to the developer and ensure our high standards of development are met. If the ticket fails code review, then the review gives specific comments and improvements for the developer to work on. The ticket then gets worked on again until we are happy with the code.
Internal Quality Assurance
Our next step is to deploy our code to staging and test. We run through our test plans to ensure we cover all bases. If the test fails then we start the cycle of work again.
External Quality Assurance
At this point we ask our clients to test. Often it can be helpful for them to see or use the test plan that the developer has created. If a client tests the work and changes what we have determined to be the ‘definition of done' then we would create a new ticket to work on. If the ticket does not pass the client's testing then we would fail the ticket and start the cycle of work again. This step is crucial to producing and sending out the high quality work that we strive for.
Deployments
We try to plan in our deployments in advance to fit with our client's schedule. Ideally we deploy work at a the quieter times of day and avoid deploying near the weekend so that if the new code affected anything on the site then it wouldn't disrupt the weekend traffic.
Retrospectives
Our retrospectives are a relatively new addition to our workflow. We book them in once a deployment has gone out. The retrospective serves as a time to air out any issues we had when working on the project. The main points to discuss are "What could we have done better?"" and "What did we do well?". This gives us a chance to come up with actionable items to bring forward into the next sprint, or personal development tasks to work on. It is also a good opportunity to compliment others on their work which is a great morale booster.
What we are still working on
As a small company with a varied client base, one of the main struggles can be strictly adhering to our workflow at all times. Juggling holidays, client workloads and our day to day tasks can mean that sometimes one of our steps can be left behind. We are also currently trying to improve our time estimates as they are not always very accurate. This is the most difficult thing to adjust and we are constantly trying to review and understand why we go over the limit.
One step we introduced was to encourage the developers to estimate investigation time for a bug or unknown task. This is normally around 2 hours. Then at the end of the 2 hours we update the estimate and check in with the client to ensure they are happy with the remaining estimate. We believe this strikes a good balance of efficiency and assisting our clients in sticking to a monthly budget.
Our workflow is an ever changing and evolving process that we plan to continue reviewing. We don't believe we have all the answers just yet but we are happy with the changes that we have made over the past 4+ years. Meanbee's goal will always be to work in a way which fits our business whilst providing the best possible service for our clients.