February 22, 2023
•
In e-commerce, change is inevitable. Businesses must be increasingly responsive to their customers’ needs, industry advances and ever-evolving trends to stay on the front foot. But this can only be done if their internal processes allow it. That’s why we use an Agile methodology.
Agile is an approach to project management, software development and web programming which enables us to quickly and effectively deliver value to our clients. Work is broken down into small, prioritized increments which are frequently reviewed so that teams can adapt and be responsive to changes in requirements and plans.
The Agile manifesto was written by a group of web developers to help themselves and others find better ways of working. The manifesto places value on:
As well as improving communication and collaboration both internally and with our clients, the Agile methodology accommodates uncertainties. By allowing us to build and deliver incrementally, any unexpected crop-ups can be tackled in manageable chunks and should only affect the small aspect of programming being worked on at that time. As all departments are working on their set tasks simultaneously, it’s possible for a minimum viable product (MVP) to be released as and when each part has reached a working standard. This MVP can then be properly tested both internally and by customers once it’s live, allowing for early feedback. When compared with the traditional waterfall method (which many agencies still use, especially those within early stages of Agile adoption), Agile development protects against big surprises or deviations at the end of the project, which would make things more difficult and costly to go back and change.
Agile comprises a variety of different ways of working (‘frameworks’) which are needed to outline how tasks should be organized and how teams should work together. We’ll run through three of the most popular Agile frameworks below.
A lot of Agile agencies use Kanban. With this framework, tasks begin their life in a ‘To do’ column and are shifted right to progressive columns such as ‘In Progress’ or ‘Completed’, depending on how far along they are.
Scrum involves a team putting their heads together to address complex problems. It begins with a wishlist of features, which become the product backlog. The team then discusses what needs to be completed and how long it will take, before tackling the tasks in sprints (more on sprints below). Scrum is our chosen framework at We Make Websites — we’ll get on to how we use it in a sec.
Scrumban is a hybrid of the Scrum and Kanban frameworks. It can be used as a stepping stone for businesses wanting to transition from Scrum to Kanban, or is ideal for those who want the structure of Scrum with the flexibility of Kanban’s flow-based method.
When adopting a Scrum framework, meetings or ‘ceremonies’ of various lengths and purposes are held during regular sprints (periods in which a set amount of work is completed). These are attended by the Scrum team: a cross-functional group that includes the Product Owner, Web Developer(s), Website Designer(s), QA, and Scrum Master. Let’s take a look at each ceremony below.
At the beginning of the sprint planning, the PO will inform the team of the sprint goal and any other tickets (running reports of a particular problem and its status) to be included in the sprint. The way our agency works is: planning is done by the developers, testers and designers to account for up to 70% of the team’s capacity, with the remaining 30% kept aside for uncertainties and timeboxed events like deployments. The team’s Scrum Master will keep track of the capacity and velocity (amount of product backlog turned into product increment during a sprint). Meanwhile, the PO will continuously guide the team on the current priority and sprint goal.
The purpose of this is to quickly inform everyone of what’s going on across the team. Each team member will answer the following questions:
*If the work of any team member is being blocked by something, this is conveyed to the rest of the team members through Slack channels rather than waiting for the Daily Scrum. This allows blockers to be tackled as soon as possible, and the Daily Scrum serves as a check-in on progress made to rectify the blocker instead.
At the end of the sprint, the PO will review the sprint report and the development team will demonstrate their work and get feedback from the rest of the Scrum team. Following this, the estimate of each individual ticket will be reviewed and any outstanding tickets that need overflowing to another sprint will be re-estimated if required.
Soon after the review session, the team will analyze what went well and what didn’t, then come up with creative solutions to improve future work. Team members can also raise any concerns and put forward ideas, and a list of action points will be compiled for the next sprint.
This provides an opportunity for the development team to get all the required info for future tasks and user stories (explanation of a software feature written from the perspective of the end-user), and put them in priority order. If the requirements are clear, the development team can provide an estimate. If not, the user story will be time-boxed for investigation.
There are various tools that can be used to aid the running of an Agile methodology. Our agency has adopted the following, which we find to be successful in ensuring everything runs as smoothly and effectively as possible, whilst keeping the whole team on the same page. Our toolset includes (though there are many alternatives):
Jira is a software development tool commonly used by Agile teams. We use it for both project management (it can be used to run all the above frameworks, not just Scrum) and metrics, including burndown, burnup, Sprint reports, velocity and epic charts.
Planning poker is a consensus-based, gamified technique that allows us to estimate the complexity and effort of a software feature, and provide more accurate costs. Anything that brings an added element of fun into doing our jobs is a win in our books!
Metro Retro is where we celebrate successes, discuss any concerns raised and come up with solutions / action points together. There are plenty of handy retrospective templates to choose from, such as ‘Liked, Learned, Lacked and Longed For’, or you can create custom templates.
Trello syncs automatically to the Jira workflow, and provides a Kanban view regarding the status of the work for our clients. Lists and cards make up the building blocks of a Trello board, and each card contains all you need to manage that task, from due dates and attachments to conversations and more.
Those using Agile adopt several ways of working. Here are some recommended best-practices:
This approach means that testing is performed as early in the lifecycle as possible, so any defects in software are found and fixed early in the process. Testers work on test scripts or mind maps right after sprint planning, and designers are at least one week ahead of software developers.
In the simplest of terms, a pull strategy pulls a customer towards a product or service, whereas a push strategy pushes a product or service at a customer. We prefer the former, which helps a customer to create an ongoing strategy with the brand.
These are used to standardise best-practices across a company. The way they work is that a ticket is estimated only when it meets a company’s Definition of Ready (DoR) and only completed when it meets the company’s Definition of Done (DoD).
Definition of Ready
A “ready” backlog item needs to be clear, feasible and testable.
Definition of Done
The Definition of Done is an agreement between the Development Team and the Product Owner on what needs to be completed for each user story. It is often standardised across the company in order to guarantee consistent delivery of quality.
To expand upon the description under the ‘ceremonies’ section above, sprint planning encompasses an effective method of sorting tasks in priority order, determining what should be achieved in each sprint.
A large chunk of work, called an ‘epic’, may be spread across several sprints. An example of an epic might be: “As a customer, I want to be able to create a wishlist so I can come back to buy products later”.
Epics are divided into user stories. For example:
These user stories are then divided into tasks to be completed by the team. An example might be:
This system ensures that work is divided into manageable chunks and that the most important tasks are worked on first.
As we’ve highlighted throughout this article, there are plenty of reasons that we take an Agile approach to working within our agency.
To summarize, it goes hand-in-hand with value-based delivery. The tasks we focus on are based on what will add the most value for clients.
Having a prioritised backlog of tasks empowers the team to work autonomously and have a consistent flow of work rather than waiting to be assigned what’s-next. As a result of both this and the ‘shift left’ approach, turnarounds are quicker. And where the actual time taken is less than estimated, we’re fully transparent with our clients and the requested payments are always accurate, therefore building a relationship of trust.
The ceremonies, thorough retrospectives and action points all help to build a ‘no-blame culture’ and foster togetherness both internally and with our clients. At the end of the day, we all want the same thing (a brilliant product and happy customers!) and this way of working facilitates that.
Do note: not all Shopify Plus agencies adopt an Agile approach. It’s simply down to preference. Many agencies do, however, especially medium-to-large-sized agencies who need to accommodate a scaled-up model plus sizable project requirements. You can find out more about what to expect from a cost perspective when working with such agencies, over in our article: Shopify Plus Pricing and Cost of Ownership.
Of course, if you’d like more information on how we use Agile and what that might look like if we were to partner with you for Shopify Plus design and development work, get in touch.
