Agile is a set of operating principles. But because it was a hot buzzword years ago many marketing organizations have implemented a mutated unrecognizable form of "Agile" that nullified the core principles of the agile approach. Some are just thinly disguised waterfall work-back schedules. Let's revisit what Agile really is and set it up correctly so the benefits can be realized.
Agile came to life as a development methodology and has been adapted for other teams like marketing and we need to take care in what we modify or it will lose its effectiveness and principles. When we think of Agile we think of:
high levels of collaboration
flexibility
iterative environment
Philosophy and Principles
Many of the principles happen organically at small companies as everyone is more in tune with what you are working on and with limited resources, there is focus and alignment by necessity around projects and company-wide initiatives. There is also a realization we don't know the outcome and have to be ready to fix things... which causes projects to be smaller and iterative. It seems many of the principles are designed to reconstruct this type of tight-knit team, that has alignment and focus, and adopts an iterative approach to generating work product.
Here is how ScrumAlliance defines Agile principles:
This is how I would summarize Agile principles:
Highest priority is to satisfy the customer (internal/external)
assume requirements are never complete and ever-changing
"quick" and continuous delivery of solutions allows for refinement
don't try to build the perfect solution as when it is ready to deploy the requirements will have changed and it will be imperfect
View requirement changes as a good
this means there is dialogue and updates of changing needs and environment which enables you to build the right solution
flexibility is good but everyone needs to be reminded that changing requirements changes time and effort for delivery of the work product
Deliver solutions (work product) frequently
our understand of a requirements isn't perfect and the landscape can change, breaking down the solution to be delivered in smaller chunks let the business get capabilities earlier and derive benefit from it even as the landscape changes and requirements for the overall deliverables change
Business people and developers must work together daily
increases communication to clarify requirements and correct misunderstandings as well as constant update on progress (no surprises)
Let the team self-organize
shed the limitations of level and role and let a person's skills and ideas guide what task should be lead by whom... avoid the highest-paid person's opinion driving decisions
Use the most efficient and effective method of conveying information
Too often in large enterprises, things are "thrown over the wall"... as if sending an email is the best way to communicate. email is asynchronous and lacks discussion, negotiation and agreement/confirmation. 1:1 face to face or web meetings are the best approaches
"Completed solutions" / "Live solutions" is the primary measure of progress
work that is incomplete and not usable isn't worth much... the difference between 40% done and 80% done has little difference in value to the business. If the tasks/items are sufficiently broken down... you only need to look at their status in a binary way (done/not done)
Agile processes promote a sustainable work environment.
The pace used to measure the complexity of work should be one that can be maintained indefinitely. If your team or staff is working overtime, they will burn out soon; if they are working too little, they will be bored. Find a balance.
Continuous attention to technical excellence and good design
The team should always be helping each other and avoid any silos, help hold each other to high technical excellence and good designs. Our success is shared.
Elegant solutions are simple
Put thought into how to keep things simple. It's far easier to build a convoluted mess that is unusable (or impossible to troubleshoot) than a simple process/interface that meets all requirements
The best solutions emerge from self-organizing teams
This adds to Principle 5, and is about putting faith in the team to come up with the best solution (through iteration) with constant communication and refinement of requirements from the business
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts
this is about one of the Sprint Retrospective... where the team reflect on the last work period and makes adjustments to how it was run to improve the how the team creates excellent work product
Key Roles
Product Owner
speaks for the business (deep understanding of the business and user is required)
translates when necessary into technical requirements (being tech-savvy is important)
develops the vision for the product (must think broadly and into the future for what the user experience and product should be)
writes the User Stories for the Product Backlog
Scrum Master
is a servant-leader for the team, the one protecting the good practice of the method
But beware, this role is NOT a project manager!
communicates status and progress to other teams
champions team's needs and clears roadblocks for the team
Team members
responsible for taking the User Stories and creating the needed work product
together decide the difficulty of stories and how many can be fit into the Sprint
skills, experience, and interest determine who will work on what
responsible for updating progress and alerting the team of roadblocks early and calling coordination meeting as needed
Concepts
Let's review a couple of the key concepts in how Agile organizes the work that needs to be done. The words may seem a bit foreign at first but you get used to it. Perhaps this was on purpose to really separate itself from project management.
Product Backlog
This is the playground of the product owner. Where the vision is materialized in this long list of prioritized User Stories. The top of the list should be prioritized well but pragmatically the lower part of the list may not be the most accurate in terms of priority. Ideally, stories should be written in a well fleshed-out form but pragmatically I have put in stores that are only the initial description and may not have all the technical requirements... and as I update they may turn into multiple stories (ahead of sprint planning). This list typically has months or work and continues to grow... will need some sort of strategy to cull old stories of little value.
Epics
Theses are baskets of relates user stories (grouped by categories or themes). This serves mainly as an organizing construct.
User Stories
These are the backbone of the process and describe the requested feature/capability and how it will benefit the user, internal teams or the business. Stores should only be as large as one Sprint. If the capability is larger then it should be broken up into multiple User Stories and grouped under an Epic. Stories should be written in this format to help those team members not as familiar with the scenario understand the requirement and it's benefit. As a user, I want to be able to <insert feature/capability> so that <insert results / benefit>”
Sprint
This is one working cycle for Agile processes. The team determines what length of time to standardize on and if your team works closely with other teams (i.e. IT), aligning Sprints may be beneficial to ensure product deliver from one team enters the sprint of the other team. Often these are between 2 to 4 weeks as that allows for a fairly complex Story to be completed and not so long that changing priorities can't be adjusted for quickly enough to avoid business impact and/or stakeholder satisfaction
Sprint Backlog
Is a list of the active stories (from the prioritized Product Backlog) the team decided they are able to work on and complete by the end of the Sprint
Tasks
Tasks, and possibly sub-tasks, are the collection of activities that build the solution (work product) to address the User Stories. Ideally, these activities should be the same size (in terms of working complexity)
Story Points
Story points are workload estimation units. These are unique to this team and the team must come up with a logical scale for these. While somewhat related to time they are not units of time but rather a mixture of complexity (risk of more effort needed) and effort to complete the story. It can take different forms: T-shirt size (XS, S, M, L, XL)... Or my preference is Fibonacci Sequence (1, 2, 3, 5, 8, 13, 21...). The reason I like Fibonacci Sequence is it nicely replicates the likely risk of underestimating as the complexity increases. My team defined 21 as the largest story we are able to finish in a sprint by one person that is focused on it. But if it is a new team you may only want 3 levels of granularity (S, M, L) and add more as you get see your estimate becoming more accurate.
Releases
This is another organizing construct, to group together a number of stories together, ideally in some sort of related category or theme. This helps you keep track of groups of features/capabilities you release in the past for easy discussion or create themes to prioritize stories for upcoming sprints
Processes and Meetings
As noted previously, the Scrum Master protects the good practice of the method and thus facilitate all the meetings and takes team notes on agreement points to keep us honest. (Are there other meetings you use in your process? Share in the Comments.)
Product Backlog Refinement
While the product owner should be constantly updating the Product backlog with new stories and re-organizing them as priorities change, we need a meeting for the team to understand new stories and help put some meat (technical details beyond the description as they ask deep dive questions) on the Story. The team should also estimate the Story Points. This is a multi-hour meeting if there are a lot of new stories and is typically held towards the end of a Sprint as a way to prepare for the next Sprint.
Sprint Planning
This is a time-boxed meeting (1 hr on my team) held at the very beginning of the Sprint... if stories are fleshed out this should be much shorter. In the meeting, The Product Owner walks the team through each story and the team votes on the Story Points and decides if they have enough Capacity to bring this storying into the new Sprint and who will work on it. Take care to think through any special skills needed that might not be available when taking on Stories. Setting the story points in this meeting might be a departure from standard Agile but for us it seemed to work better when the team had time to think about the details of the story from the Product Backlog Refinement meeting.
Daily stand-ups
These are quick (~15mins) beginning of each day status updates and a chance to ask for help. Each team member states what when have completed and what they will/continue to work on and ask for help or set up meeting with other team members
Sprint Review
This is a multi-hour (end of Sprint) meeting with a broader audience for the team to show the finished solutions (to the the rest of the team, Product Owner, stakeholders, and partner teams). Sometimes this is also known as a Sprint Demo. If the Product Owner is in tune with the audience there should be few surprises. Feedback is a source of future stories.
Spring Retrospective
This is a team meeting to review (also at the end of Sprint) the team processes (quality improvement, effectiveness, and happiness)... Review Velocity, Burndown chart, new test processes, and propose new processes to try. Each team member is encouraged to share votes for things to
Keep Doing
Stop Doing
Performance
Velocity
This is the number of Story Points completed by the team. Once the team get into a groove you should hit a fairly steady average which help you determine how many stories points your team has Capacity for in each Sprint. Like Story Points, this is unique to the team and is not transferable or comparable to other teams.
Capacity
This represents the "availability" of the team... how much effort they can absorb for each Sprint. Training, vacation, etc will change the overall capacity of the team.
Burndown
This is used to visually show the points we are completing daily during the sprint, giving the team and understanding of progress.
Using Agile in Marketing Ops projects
Armed with this refresher on Agile methodology, make sure your implementation of Agile adheres to the principles so you and you team can enjoy high productivity and job satisfaction. Below are some Tips from learnings my team had as we rolled out Agile.
(Share your tips and stories of your implementation.)
Bonus: Tips
Specialized Skills - This is a slight departure from strict Agile but is also a recognition of reality. Unlike a development team, the skills of team members on a Marketing Ops team can vary greatly and learning a new set of skills take a fair amount of time. We encourage team members to constantly expand their skillset. This needs to be account for in Story Assignment and Capacity during Sprint Planning. You might need to double up resources so one can learn from the other and this will decrease your team's capacity
Rush on QA at end of Sprint - On one of my teams, I found QA seemed to be always rushed as it was one of the last Tasks on every story and tended to bunch up at the end of the Sprint. This hurt quality of the product and quality of life for the QA team members. QA was also light at the beginning of the Sprint. We tried a number of variations to spread out the work and found creating separate stories for QA and Roll-out work best. In one Sprint, the solutions were created and sometimes the QA/fixes might start in the next sprint. Which helped spread out the QA work.
Definition of Done - This will happen organically but should be documented and reiterated so all team members know what is considered Done. In our case, for most items, it meant capability is complete and spot testing passed and is available in our QA instances of systems ready for full QA tests. In our team, full QA is part of a separate story to balance resources better throughout the Sprint.
Capacity and Type of Stories - This can happen organically with the Product Owner but I found it helpful to have a loose guideline to help with ensure we make time for non-urgent but important stories and prioritize stories that are urgent. To do this we created a guideline to try to include in each Sprint 20% Fixes (urgent) and Technical improvements (not urgent but important), 50% Regular, 30% Innovative (class-leading thought leadership)
Ever growing product backlog - With a strong vision, you will likely find you will accumulate more new Stories than completed Stories each Sprint. At some point the Product Backlog will become unwieldy and need to be culled of Stories you will realistically you will never prioritize or focus has changed and those Stories are no longer needed. Start by reviewing stories that have not been updated in over X (i.e 9) months and make an edit if it is still of value and review the priority otherwise cull it from the Product Backlog.
