Agile is an iterative approach to project management and software development that helps teams deliver value to their customers faster and with fewer headaches.
– Atlassian Agile Coach, https://www.atlassian.com/agile, retrieved June 18, 2021
For those new to the agile methodology or in need of a refresher, I will start with a general overview about what agile is, and then get into a bit of the history. After that, I’m going to tell you how agile methodology works for an agency — our favourite parts, and some issues we’ve come across.
I’m passionate about agile, and this article is a little lengthy. Feel free to skip to the parts of most interest to you:
What is Agile Methodology?
The Agile Methodology / Method is an approach to project management often used in software development. It uses incremental, iterative work sequences that are commonly known as sprints.
Agile was formally launched in 2001, when 17 technologists drafted the Agile Manifesto. They wrote four major principles for agile project management, with the goal of developing better software:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Traditional Agency Framework vs Agile Methodology
A traditional agency project management approach requires less input from the client, usually only interacting at major milestones. A client presents a challenge (or sometimes their proposed solution) to the agency, agency goes and solves (or attempts to solve) the problem, and reports back with a complete solution. They track time, bill by the hour, and count minutes on the phone. This isn’t how we like to work.
At Rock & Bloom (R&B), we like to work closely with all of our clients, and have them deeply involved in the project. Building a killer brand is all about empathy and listening. Our clients are the experts in their field — it’s essential that we use their expertise to strengthen and guide the work. Aside from being essential to good work, maintaining open lines of communication is necessary for the success of the agile process, too. Our most successful projects are the ones where clients are willing to invest time into the project and the process.
Using Agile Methodology Gives a Competitive Edge
The Harvard Business Review co-authored a paper with Atlassian called “Agile Practice: The Competitive Advantage for a Digital Age.” The paper is a few years old, but the principle still stands: agile methodology can see great success when applied to non-traditional industries. Many of us at Rock & Bloom come from a tech background, and adopting an agile framework felt like a no-brainer. While I am a particularly passionate advocate, many of the other folks at R&B had already bought into the methodology.
A few competitive advantages, particularly in regards to using an agile framework within an agency structure include:
- Customer needs are flexible and constantly centered
- Organizations can respond to market changes faster
- Deliver higher quality products and services
- Company and the client / end-user are able to provide valuable feedback at inflection points
- Unnecessary work and redundancy are avoided through communication
- Collaborating parties both feel heard and valued
- The process allows for pivots and work that needs to be done on tight timelines
- Feedback is immediately incorporated into the process and the product
- The exact product predicted and needed is delivered
Main Frameworks
A process for managing a project that involves constant collaboration and working in iterations, agile methodology is most known for two main styles: scrum and kanban. We pull from these frameworks to build a model that works for our agency.
Scrum
Scrum is a process framework used to manage product development and other knowledge work. Scrum […] provides a means for teams to establish a hypothesis of how they think something works, try it out, reflect on the experience, and make the appropriate adjustments (Agile Alliance).
Scrum is the most popular agile framework. It focuses on a set delivery pattern called a sprint. A sprint is a short, time-boxed period when a scrum team works to complete a set amount of work (Atlassian). Sprints typically last one to four weeks.
The Scrum framework has a set of events that include the following:
- Sprint planning — where sprint priorities are identified
- Daily standup meetings — daily discussion and coordination of that day’s work
- Sprint retrospective meetings — a discussion at the end of a sprint about whether it was successful, and to identify improvements that can be incorporated into the next sprint
Using Scrum, increments of software can be delivered periodically, rather than waiting for large final software releases. For this reason, many tech companies have adopted this framework. Users of the software get small, incremental improvements on a regular basis rather than a bunch of new features and bug fixes once or twice a year.
This is how most software as a service, or SaaS companies operate. You’ll see it in most of your app updates, if you ever read them. The Facebook ios app release notes show an example of shipping small updates in periodic increments:
Kanban
Kanban is a popular framework used to implement agile software development. It requires real-time communication of capacity and full transparency of work. Work items are represented visually on a Kanban board, allowing team members to see the state of every piece of work at any time (Atlassian).
Kanban was started by Toyota in the 1940s. Toyota industrial engineer Taiichi Ohno took inspiration from supermarkets to implement a “just-in-time” inventory system, which increased production levels, improved efficiency, and removed waste (Nave).
Agile software development teams today are able to leverage these same just-in-time principles by matching the amount of work in progress to the team’s capacity. This gives teams more flexible planning options, faster output, clearer focus, and transparency throughout the development cycle (Atlassian).
A main difference between Kanban and Scrum is that Kanban is not necessarily iterative. A Kanban process allows the software to be developed in one large development cycle.
Estimations
Within the agile methodology, there is something called estimations. Agile estimation is about evaluating the effort required to complete each work item listed in the prioritized backlog. Estimates are hard — you need to anticipate how much time / effort you are going to need to complete a given task. At Rock & Bloom, the team who will be completing the work will do the estimation. And it is just that — an estimation. Sometimes we’re off, but that’s a-ok. The point of doing estimation is to help our account managers plan out a timeline, allot work fairly, and scope projects.
In traditional agile, points are abstract and arbitrary, as long as everyone agrees. At Rock & Bloom, we loosely associate points with hours / days to have a reference point.
How it works at Rock & Bloom is that we each estimate tasks in our backlog prior to or during our weekly sprint planning meeting. We use this system:
- 1 point – some small amount of time
- 2 points – less than half a day
- 3 points – about half a day
- 5 points – roughly a full day of work
- 8 points – more than a 5
- 13 points – even more than an 8
We try to never have anything larger than a five. Estimating something correctly is hard. And as tasks get more complex, they get more daunting to work on, harder to review, and harder to estimate correctly. If something is bigger than a five, we will break it up into sub tasks and estimate those instead.
Why no four, you ask? No 10? We use the fibonacci sequence — computer scientists ❤️ the fibonacci sequence. Using these numbers prevents any estimations from being too close to one another, which can make estimating harder. Think of it in terms of weight — it is easier to tell the difference between a 5lb weight and a 8lb weight, than 5lb and 6lb weight. Fibonacci numbers also don’t double (with the exception of 1 to 2), which also makes the sequence very well suited to estimating. When numbers double, we tend to think too much about if one task is “twice as hard” as another task, which is not helpful.
During sprint planning, each team agrees on the set of work they will complete during the sprint based on the total of the estimates. The work we choose is pulled from a prioritized backlog of tasks. We use Monday.com to track our points, tasks, and status.
Agile Methodology at Rock & Bloom
All four principles are important, but here at Rock & Bloom, the last two points really resonate with us:
- Customer collaboration over contract negotiation
- We let this principle guide us through all kinds of projects. It means that we work closely with our clients and get feedback from them at multiple points in the process. We are able to assess that information and implement it, instead of being stuck in what was decided on day one.
- Responding to change over following a plan
- Often as a client moves through our processes, they start to more thoroughly understand their own problem and needs, and we are able to respond to that. We don’t stay locked into any early decisions, and we are able to pivot as necessary.
Agile methodologies were built for teams of software developers. Since we are not all developers and we are not working on software, strictly following Scrum doesn’t work for our teams. We have cherry picked the things we like from both Kanban and Scrum, and are using those to run a sort of modified scrumban, which we usually just call Our Process.
Some of Our Favourite Things About Our Process / Agile Methodology
We love the agile framework, and it has allowed us to create amazing work while giving employees freedom and flexibility. Here are a few our favourite things about applying an agile framework to an agency model:
- Self organizing teams
- This is a team that does not depend on, or wait for, a manager to assign work. Instead, these teams find their own work and manage the associated responsibilities and timelines.
- All of our teams are different degrees of self-organizing
- Our account managers set priority for all of the tasks for the week, and then we are able to start work on the next highest priority thing that we have the skill set to complete.
- Work-in-Progress (WIP)
- This term comes from the Kanban framework. It limits work that is currently being done. This means that if the WIP limit is one, each team member can only have one task in progress. Applying these limits forces the team to focus on a limited number of tasks and drive work to completion.
- Note that some team members abide by this rule better than others…
- Ownership of the work
- Once a team member has selected a task to work on, they are the owner of that task, and it is their responsibility to get the task completed!
- Constant communication and collaboration
- We trust everyone to get their work done, in their time. For some people, this means regular work hours, whereas for others (ahem, Nhi), it might mean coding into the wee hours.
- At any time in the sprint account managers and other team members can see the status of a task just by glancing at the task board.
- Daily check-ins give everyone a lot of opportunity to make sure they are going down the right track with their task, and ask for help if needed. While each team member is responsible for their tasks, we are still a team working collectively towards the same goal.
Adapting Scrumban to an Agency Model
Since the start of R&B, we have tried many different ways to implement a strong agile process. This started initially with having a fully physical board with post-it notes or actual paper index cards that we would physically move around on our task board every day. As we grew and added some remote team members, we moved our task board to a digital format. We started with a simple and free option, Trello.com, and as we felt the need for more functionality, we moved to Monday.com.
Monday.com has allowed us to collaborate with many people on the same board, and effectively keep track of what we are working on. It also allows us to easily predict what a team can complete in a week, which can be used for forecasting when something will be finished or how long it will take for us to get started on a new client request based on the amount of work we currently have in the queue. It has a predictive element for account managers, who can see at a glance when new work can be started and completed.
We sprint from week to week, so every week we take a look at our last week’s work and have a sprint retrospective meeting. This is where we look at the positives and negatives, questions, and going forwards from the week. When R&B had only five people, we did this weekly with the whole company, and took a look at things at a more general level. Now that we have grown and have more specialized teams, we have started to do this per department, which allows us to get more technical and specific in the feedback we give our teams. Design and content, development, and strategy teams each have their own retro and sprint planning meetings.
Our Rituals
We still meet as a company once a month in an R&B share session, where we share company news, timeline updates, and demo a project we have in progress. This lets everyone in the company stay connected without adding a lot of extra meetings to our calendars.
Sharing is one of our core values, and as we grow bigger, we’re finding that many projects don’t touch every single person in the company. Our share sessions are a great way to stay up-to-date on the cool things that our coworkers are working on, see new tech in practice, and hang out with our work fam.
When Rock & Bloom started we had only one person in each different department — development, design, accounts, and content. We were one big team working together on every single project. This made it hard to use traditional scrum because not every person working on the project could pick up every single task. For example, a designer could not pick up a coding card, likewise a developer cannot pick up a design card. It was also difficult to estimate how long a task would take, since “designing a homepage” and “developing a homepage” really aren’t very comparable. We have found our agile process works best when we can break down tasks to a very similar “size,” and this was difficult with the cross functional nature of our teams and the make up of our work.
As we grew, we made the choice to adjust the teams to be skillset based, with the developers forming one team, the designers, content writers, and videographers forming another, and strategy a third. This lets our points per team become more consistent and our work capacity for a sprint more predictable.
Adapting the agile methodology to best suit the needs of agency life has been a huge part of our success. We are thankful for the amazing frameworks that Scrum and Kanban give us to build on. We will continue to adjust our process as we grow and change, and we continually revisit the basics to stay true to our values.