AgileSparks-Agile Consulting/Training With a Spark
AgileSparks is providing Agile/Scrum/Kanban solutions including training, coaching, assessment, All things Agile/Lean,focused on Agile Transformations, Scaling, Organizational Agility, Agile Marketing, DevOps, Kanban, Lean Startup.Follow this blog to know more about Agile.
More and more Marketing organizations are realizing today that they need to be faster, more flexible/responsive and more collaborative, in order to have a real impact on the business they’re supporting. More and more CMOs are looking at Agile Marketing as the way to modernize their organization.
Inspired by Agile Development, Agile Marketing describes a mindset of continuous learning and validation, customer-focused collaboration across functional silos, adaptive and iterative campaigns and more responsive/continuous planning. Similar to development organizations, Agile Marketing teams use techniques such as Scrum to work in an iterative cadence, and such as Kanban to visualize and improve the flow of work.
While Agile values, principles, and practices map pretty well to the world of Marketers, some modifications to the language and choice of practices are needed.
Agile Marketing has been growing in popularity in recent years, attracting larger and larger organizations to apply its principles and to look for a scalable approach to their marketing processes.
This guidance article aims to help marketing leaders and change agents in these medium/large marketing groups by exploring what it means to use SAFe – the Scaled Agile Framework, for implementing Agile Marketing at scale.
We will identify the right context for using SAFe for Agile Marketing, how to go about implementing it, look at key challenges and some emerging solutions, and close with a wider perspective of how Agile Marketing fits into real enterprise agility at scale.
Defining Agile Marketing
Agile Marketing is a philosophy/mindset/approach that is based on the same thinking and mindset behind Agile Development and therefore benefits from applying at least some of the practices/frameworks used in Agile Development – sometimes as is and sometimes with important modifications.
Agile Marketing is helping Marketers deal with some key challenges they’re facing:
The need to be more flexible and responsive with a much faster time to market.
Moving beyond conventions and opinions towards more data-driven decisions
How to streamline marketing activities that span organizational boundaries within/beyond the Marketing department.
Effectively choosing, deploying and integrating more and more marketing technology – Many CMOs technology budget exceeds that of their CIO believe it or not. And marketing technology stacks have become complex IT systems.
Working at the pace of the Technology organization that moved to Agile and more frequent releases or even continuous deployment.
If you look at these challenges closely you will see that many of them arise from a significant growth in uncertainty that these organizations face. around both WHAT marketing would work as well as HOW to build it in an effective way.
Agile Marketing – Anticipating Complexity/Uncertainty and Dealing with it using Iteration/Adaptation
Agile Marketing is about anticipating this complexity/uncertainty and dealing with it in a disciplined pragmatic sustainable manner. We plan to work in an iterative manner. We plan based on some hypothesis. We build in small increments, validating both the technology/implementation as well as the experience as often as possible by demonstrating it and testing it both internally as well as in the real world.
We also realize that when faced with this level of uncertainty and complexity it is hard to carve out marketing work into small self-contained pieces that can be planned and built in isolation. It is much better to create customer-focused teams where everyone working to optimize a certain marketing aspect is on the same team and can collaborate effectively.
Validated Learning, Customer Discovery With Many Small Experiments, Leading to Adaptive and Iterative Campaigns
The Agile Marketing Manifesto introduces concepts such as validated learning (which is brought over from the Lean Startup approach).
Instead of decisions made based on opinions and conventions, agile marketers look at each marketing play, identify risks/assumptions, run a Build-Measure-Learn experimentation cycle for the riskiest assumptions.
This is well aligned with SAFe 4.5’s Continuous Exploration approach. One can consider Marketing’s search for marketing-market-fit a complementary step to finding product-market-fit. Once a product/service achieves “must have” status it is time to figure out how to grow its market faster and faster. This often requires experimentation and iteration, sometimes across a set of teams. For example, a growth team might be at the forefront of identifying options to explore and designing experiments. Ideally, they should be able to run those experiments and learn from them within their autonomous agile team. But in real life in many cases this team would depend on other teams in and beyond the marketing group – For example the product team, the website team, the mobile app team.
In this case, try creating an Agile Marketing Train where these teams align and collaborate – e.g. in events such as PI Planning and using artifacts such as the Program Kanban Board and the Program Dependency Board.
Customer Focused Collaboration
Agile Marketing brings together marketers and other players to collaborate on improving customer experiences. If you were ever a sole marketer for a company or part of a marketing team for a small startup/company you know how this looks like.
You can move much faster when everybody you need to deliver the overall marketing impact is on your team (or in your head). Most marketing organizations lose this advantage when they grow beyond the single team and specialize.
So, like in Product Development – try to create Feature teams rather than Component teams if possible. And if you have a larger group of marketers working in the same value stream consider them an “Agile Team of Teams” and use an Agile Marketing Train with SAFe’s program level constructs to help coordinate/synchronize across teams.
Customer-focus teams can take many shapes
Those customer-focused teams own aspects such as:
the whole customer journey for a certain brand/product/market (e.g. SMB)
Content Creation, Publication, Measurement
A key marketing challenge/opportunity such as a stuck Middle of the Funnel (MOFU), ineffective Sales Enablement.
Account Based Everything (ABX)
Planning and delivering the company’s Customer event or presence at a key industry event
Exploration of a new marketing approach such as “Social Selling”, “Video”
A key marketing KPI that is not performing well or is identified as a key objective for growth.
While we call it Agile Marketing, in many cases these teams include and involve participants from other adjacent functions such as Inside Sales (SDRs), Product Management, Field Sales, Customer Success.
From tasks to Customer-focused stories and marketing backlogs
Once the marketing organization work structure is oriented towards a customer-focus – Agile Marketers start managing their work in a customer-focused way as well.
They use work items that reflect marketing value such as “User Stories” or “Job Stories” rather than “to do lists” or “tasks”. Thinking of work in this way and including the goal/impact expected of each work item as part of the “Story” helps marketers maintain a laser-focus on the customer impact they’re aiming for day in and day out.
This also makes it easier to communicate with business stakeholders about what marketing is focusing on and get their early feedback and guidance – which helps avoid the common situation where marketers talk in language that business/sales don’t care about and after delivering something there are still major gaps between what the business/sales expected and the marketing that was delivered.
Agile Marketers also use more disciplined and more customer-focused prioritization mechanisms that take into account considerations such as Cost of Delay, Time Criticality, Opportunities as well as Risks addressed to consider what to focus on next and whether to interrupt ongoing work for an emerging opportunity.
SAFe’s WSJF-based economic prioritization works well in this context. The Program Backlog’s “Features” don’t translate too well to a marketing context. Terms like “Marketing Play” seems to resonate better. Describing it with Benefits, success criteria/metrics and acceptance criteria still works well.
While some marketers understand agile marketing to mean “no planning” this is not the intent. The Agile Marketing Manifesto talks about “Responding To Change” over “Following The Plan”. Another way to look at it as “Flexible” or “Continuous” Planning vs “Rigid Static Planning”.
Planning in Agile Marketing happens at two levels.
One is planning what to work on and what we can commit to delivering for a certain timebox – be it a day, week, quarter or year. Let’s call this cadence-driven planning.
The other is focused on a certain marketing campaign/play – planning the strategy, vision, tactics, rollout plan for that campaign/play. Let’s call this content-focused planning.
Sometimes most content-focused planning happens during cadence-driven planning but that’s not a must. It might make more sense to do the content-focused planning just in time as we start a campaign/play rather than at the beginning of the quarter.
Sprint Planning – light-weight look-ahead planning with a focus on the short-term Goal and initial Sprint Backlog
Daily Scrum to inspect and adapt on a tactical continuous basis
Sprint/Iteration Review/Demo where the Scrum team reviews their Done Increment, collects feedback from stakeholders, considers the next options in their Marketing Backlog and then the “Marketing Owner” can adjust the Marketing Backlog to reflect the new learnings/ decisions
Retrospective – Inspecting and adapting the process
Kanban’s flow is used to:
Visualize the flow of marketing value throughout the marketing development value stream
Limit the flow to help focus on top priorities, minimize multi-tasking, and surface bottlenecks/constraints so that they can be addressed.
Pro-actively manage the flow of work – e.g. by highlighting and dealing with items that are aging and are at risk of exceeding the team’s typical service level expectations.
Below, in an example from an Agile Marketing Train in CA Technologies, you can see how the various layers of events and artifacts work together.
Agile Marketing requires Lean/Agile Leadership
Agile Marketing tries to bring back this effectiveness, speed, fun and focus of the small startup regardless of your organization size. We create autonomous agile marketing teams that are empowered to make local decisions aligned with achieving their goals while doing what’s right for the overall brand. This only works if we:
build the right competence by hiring the right people and encouraging them to master their domain and giving them the space to learn and improve
create high clarity by sharing the business context, our vision, constraints.
This autonomy and new structure don’t mean there’s no need for marketing managers/directors of course. It does mean changes in their focus e.g. on things like hiring and nurturing great marketers and providing clear and meaningful mission/purpose.
Do you really need to SCALE Agile Marketing?
If you believe you have good reasons to transform your Marketing organization towards Agile, AND you believe you have a trigger event that can enable a real transformation, your next step is to figure out whether you need some Scaled Agile Marketing approach.
Scaling isn’t automatically a function of the number of people in the marketing organization. It’s more about how many marketers need to work together as part of one customer journey/experience.
Let’s look at an example. In the diagram below you can see a typical marketing organization that would possibly require a scaling approach. They have Agile teams that cross-cut the different marketing functions – focusing on delivering marketing value/impact for a specific product/customer journey, rather than focusing on a specific marketing function/task.
Map it to your organization. If your teams are truly autonomous and work on separate backlogs and activities, with minimal dependencies, then you might not need a full-fledged scaling approach.
If, on the other hand, they ARE working on one bigger customer journey, have dependencies across teams and some floating specialists that need to be involved in multiple teams, or are considering synergies and adjacency campaigns (e.g., if you’re using an Agile ALM tool you can probably benefit from Continuous Integration or Portfolio-level tools), a scaling approach would benefit you.
In this context, SAFe’s Agile Marketing Train (Agile Release Train’s adjusted name for the Marketing context), with its Program Increment Planning, single Program Backlog, System Demos and more, provide useful guidance.
Working with Agencies
In many cases, marketing organizations work with external marketing/advertising agencies to deliver campaigns or materials for campaigns. In most cases, the way these relationships work don’t map well to “everybody working on one Agile team” and a scaling solution is required.
A rising trend is the “Internal Agency” model (see https://hbr.org/2015/07/6-reasons-marketing-is-moving-in-house) in which an internal agency is created as a shared service that supports the various lines of business in the organization. While getting rid of the dependency on an external vendor, this “shared service” presents its own scaling challenges. Creating real “Agile Teams” that can deliver marketing impact without relying on teams/people in an “Internal Agency” is a better more scalable approach. This isn’t always possible – a common problem is having too few people to assign them to agile teams so preferring to run them as one consolidated team and load balance the demand.
If you cannot bring all the teams you need into your Agile Marketing Train – whether they are internal teams that cannot board the train or external teams that either cannot or don’t want to board it.
SAFe provides a couple of options for how to deal with internal/external “suppliers” – for example, they can become a separate “Supplier” Agile Marketing Train on a bigger Solution Train, or a “Supplier” team that is a “component”/”specialized” team inside an Agile Marketing Train. In any case, SAFe provides guidance for how to involve them in a planning and execution cadence and how to create realistic plans considering their capabilities and availability without forcing them to be members of Agile teams (although that is certainly an option and will be recommended in some cases).
Longer-term activities such as events and strategic campaigns
Most Agile Marketing organizations run a mix of high-tempo testing that is a great fit for Agile iterations/flow with frequent planning, but also some longer-horizon activities such as conferences, webinars, big product launches, that require more predictability and visibility beyond the “next 2 weeks” that team-level Agile provides.
SAFe’s combination of high-tempo team-level agility with the Program level (with its Program Increment Planning, Roadmap, and visibility to Features), helps deal with this mix of demands from the marketing organization.
What does Scaled Agile Marketing mean?
So, assuming you’re thinking Agile Marketing can help you with some of your marketing challenges, and that there’s a good opportunity to do something about it right now, and that there are some reasons you think you need to consider some scaling aspects, let’s try to see what Scaled Agile Marketing looks like.
The first thing about Scaled Agile Marketing is that it isn’t just about Agile. It’s also about Lean.
Lean is focused on value, which is similar to “Customer Focus” in the Agile Marketing Manifesto. It adds pillars like “Respect People and Culture”, “Flow”, “Innovation” and “Relentless Improvement” that are somewhat missing from the Agile Marketing Manifesto, although you can find some hints for them in the principles behind the manifesto.
The most important addition is “Leadership”. Achieving a transformative move to Agile requires more than just practices at the team level. It requires both application of scaled practices, and even more importantly, a different style of leadership that focuses on creating clarity around purpose, decentralizing control, enabling and developing people and creating a safe-to-learn environment.
If you “Respect (and understand) People and Culture”, you understand that culture is hard to change. It’s actually the last thing to change in a transformation as changing leadership culture is a huge challenge.
In order to tackle it, we put a lot of focus on training and coaching, throughout a real Agile Marketing transformation, on leaders and help them think and act differently in ways that support/enable Agile Marketing behavior rather than detract from it.
Strong understanding of Lean/Agile Scaling Principles
Beyond a high-level Lean/Agile mindset, there are some additional principles we need to take to heart in order to succeed at scaling Agile Marketing.
Why do we need principles? Why not jump to practices? Because we’re dealing with snowflakes. What does snow have to do with anything? Each snowflake is different. Each organization is different. So despite the fact that we have some good practices that may be able to help us scale, we want to understand the principles underlying them so we can know what to do to inspect and adjust our Agile Marketing approach, to find the best fit for our purpose and context.
Start by reviewing Scaled Agile Framework (SAFe)’s Lean/Agile Principles Some of my personal favorites are principles like “Decentralize Decision Making”, “Reduce Batch Sizes”, “Systems Thinking – Or Optimize the Whole”, “Apply Cadence, Synchronize with cross-domain planning”, “Assume variability, preserve options”.
The Role Of Agile Scaling Frameworks
Some of you would be able to solve most of your scaling challenges by combining team-level Agile Marketing practices and a good understanding and application of these principles.
Most of you though will be looking for some example/guidance for how to apply these principles. This is where scaling frameworks such as SAFe come in. SAFe provides a “Full Kit” to support an organization trying to achieve Agile at scale – providing guidance, training, certification, and a supporting ecosystem of experts as well as “social proof” in the form of testimonials and case studies.
This is less important to innovators and early adopters, but crucial for the majority of organizations that follow.
Nothing beats an Agile Marketing team – but what if a team isn’t enough?
The Scrum Guide provides the most popular guidance on how to structure Agile teams. “Small enough to remain nimble and large enough to complete significant work <…>. Fewer than three Development Team members decrease interaction and results in smaller productivity gains …. Having more than nine members requires too much coordination … too much complexity”.
So, what if in order to encompass a large customer experience/journey, one such team of up to 5-9 people, isn’t enough? This can certainly happen if we’re talking about large businesses or products with dozens of marketers that focus just on one line of business or experience. Especially when we’re a very specialized marketing organization where in order to deliver the full experience we need more than a handful of people.
Do we grow the team so that everybody that needs to work on the experience is on it? There’s a limit to the size of a team before communication and collaboration get unwieldy, and before team members start to lose themselves inside the team and don’t have the same sense of accountability, ownership, and purpose anymore.
Do we require more full-stack/t-shaped marketers that can each cover several specialties and therefore be able to deliver the entire breadth of the experience with fewer people on the team? ideally yes, but that is typically very hard to achieve, both from a mindset perspective as well as the skills/experience aspects. Most organizations cannot assume this when starting their Agile Marketing journey.
The Agile Marketing team of teams
When it is impossible to actually deliver the whole value with one team, the pattern most often used is to create an Agile “Team of Teams” – in SAFe this is the Agile Release Train..
One of the new concepts we introduce in the Kanban Guide for Scrum Teams is the Service Level Expectation, defined as:
An SLE forecasts how long it should take a given item to flow from start to finish within your workflow. The SLE itself has two parts: a period of elapsed days and a probability associated with that period (e.g., “85% of work items will be finished in 8 days or less” which can also be stated as “8 days with 85% confidence/probability”).
The term expectation is key here. We’re not talking about commitments or promises. While it seems like an SLE is mainly serving the team’s stakeholders its primary purpose is actually internally focused. The Development Team is using that expectation as a flow transparency, inspection, and adaptation mechanism. The team can start to actually compare active in-flight work to their SLE and look for items that are at risk of missing the SLE.
As work ages without completing, it becomes more and more likely this work item would not meet the team’s SLE. For example, once a work item reaches a point where it’s age is now at the point where half of the team’s work items have already completed, it’s a clear indication that there’s more risk for this item than the typical item. We basically learn about the increased risk to specific items the more time passes without them completing. Common sense, no? The idea is that by visualizing these items and that growing risk we can focus the team’s tactical inspection and adaptation during the Daily Scrum on tackling these risky items.
Let’s look at an example. Let’s assume that indeed we have a Development Team that learns from their cycle time scatterplot that 85% of their work items finish in 8 days or less and 50% of the items actually finish within 4 days. They have an item A that has been active for 5 days already and an item B that has been active for 3 days. Which of these items should the team feel more confident they can finish within their 8 days or less SLE? Without further information about where each of the items is in their workflow, they should feel more confident about item B that aged less. Item A has already been active more than it takes for 50% of the cards to finish, so it’s quite a strong signal that there’s a flow risk to it. Basically, with each day that passes in which a work item doesn’t finish, the probability that a work item will not meet its SLE increases”.
Beyond its usefulness for in-Sprint flow focus, SLEs are also useful during Sprint Retrospectives. The “surprise” or “anomaly” of missing your SLE can drive an improvement discussion. I previously wrote about the Sprint Forecast as an expectation and the learning/improvement value of having an expectation that you miss vs having no expectations.
This “no expectations” problem is actually a common concern for Scrum practitioners when they look at Kanban. The Sprint Forecast/Commitment provides that expectation. Kanban without SLEs indeed is missing something. Having WIP limits as expectations improves flow but doesn’t help with specific items that aren’t flowing well.
How should a Scrum Team come up with their SLE? First of all – The SLE relates to the Development Team. They should figure out what their SLE should be. If possible based on historical cycle times. If there isn’t enough data, make a best guess and replace it with empirical data-based information as soon as possible. If it isn’t based on historical cycle times, you cannot really expect to make any educated confidence-level determinations (like the one above) based on your SLE.
Also, SLE’s aren’t SLA (Service Level Agreements). SLA is a loaded term that means different things in different contexts but generally is an external commitment about the service levels a team will provide. As mentioned an SLE is mainly internally focused.
Bottom line – SLEs are used by Scrum Teams to set flow expectations to themselves. SLEs are ideally created based on actual historical cycle time data. They are then used by teams to focus their flow inspection and adaptation effort – during the Sprint in the Daily Scrum and following the sprint in the Sprint Retrospective. They can also used in the Sprint Review when the team is working with stakeholders that care about the team’s cycle time.
Co-Creating and teaching the new Scrum.org Professional Scrum with Kanban class has given me an opportunity to get back to geeking out on WIP limits, flow metrics and all things Kanban. And it’s been fun!
One of the key Kanban practices is Limiting Work in Progress. If you want to be pedantic, actually what this practice aims for is Reducing and stabilizing Work in Progress. This improves flow, provides predictability, and is actually even more important for creating a pull-based Kanban system than visualizing your workflow using a Kanban board. I worked with several clients that limited their WIP but didn’t use Kanban boards. One could argue that maybe this practice deserves to be first in the list of Kanban practices, ahead of Visualization.
Anyhow, when a Scrum Team implements Kanban they should definitely figure out how to limit and reduce their Work in Progress. This is a key part of their definition of “Workflow”. Now, a question comes up: Who should define the WIP Limit? Let’s assume the team is using Kanban to improve the Sprint flow by visualizing and managing flow in the Sprint Backlog. Sprint Backlog is owned by the Development Team so it would make sense for them to own their workflow and specifically the WIP limits in this case.
What if the team is using Kanban from a more holistic perspective, starting from the Product Backlog and including refinement work as well? In this case, it would be the Scrum Team that would own the workflow and therefore would need to discuss WIP limits.
Now, what if the Dev Team actually wants to involve the Product Owner in their Sprint flow – e.g. to review and accept a story during the Sprint before it goes through testing. Who decides whether to do this? Who owns the Sprint Backlog in this case? I think it is the Scrum Team.
Ok, so we understand who defines workflow and therefore WIP limits. Now let’s assume a team is mid-Sprint and there’s an important valuable item the Product Owner wants to add to the Sprint Backlog. It is aligned with the Sprint Goal. The team is currently at their WIP Limit. Could they add this item? Should they? What needs to happen to the WIP limit?
My take on this is that first of all a decision needs to be made whether to pull this item into the Sprint Backlog. This discussion isn’t related to Kanban at all. It is a core Scrum question and the answer is that it is up to the team to agree to pull a new item into the Sprint Backlog. The Sprint Goal can be used to assess how aligned this item is with the current focus.
In case the item is pulled into the Sprint Backlog, then the Dev Team needs to figure out whether they can actually start it right away. This depends on the WIP limits and the current WIP. If the team is at their WIP they shouldn’t pull in that new item until some room frees up. If their backlog items are pretty small, an empty WIP slot will free up pretty quickly. If items are big, it can take a while.
The longer it might take to get a normal pull slot ready, the more pressure there might be to actually expedite this card. What is expediting? going beyond the current WIP limits and pushing this item along on top of the existing flow. The typical way to do this is NOT to change the WIP limit definition but to go above WIP and note a WIP exception. These exceptions can then be a topic for inspection and adaptation come time to retrospect.
In general, I don’t recommend changing WIP limits on a whim just because there seems to be a need during the Sprint. I’d rather see an exception and discussion rather than hide the problem under a policy change. Most of the time, Scrum Teams should adjust WIP limits during the Sprint Retrospective out of an attempt to create a better flow strategy, not a way to manage at the tactical level. This is similar to the definition of Done. We don’t change the definition of Done during a sprint just because we have a problem creating a Done Increment. We note the exception, maybe even fail to create a really Done Increment, and we discuss the definition during our Retrospective.
One last thing to note about limiting WIP is that while we typically talk about limiting WIP as per-lane constraints on your workflow, this is actually just one specific way to do it. You could limit the amount of work in progress per person, per the entire team throughout their workflow, or actually you could limit WIP by time. E.g. “we won’t work on more than 10 items this week”. Hey – that sounds familiar! #SprintForecast.
The number of work items started but not finished (according to the Scrum Team’s definition of “Workflow”).
Note the difference between WIP and the WIP Limit. The WIP Limit is a policy which the Scrum Team uses as a “constraint” to help them shape the flow of work. The goal of the WIP Limit is to reduce the amount of actual work in process (WIP). The team can use the WIP metric to provide transparency into their progress towards reducing their WIP and improving their flow.
While teams can directly visualize the WIP levels over time (which I recommend), most people use the Cumulative Flow Diagram to visualize the WIP.
The amount of elapsed time between when a work item “starts” and when a work item “finishes.”
This metric is a lagging indicator of flow. It is available only after an item is actually finished from the workflow perspective (e.g. reached a Done lane on the Kanban board). It is typically used to drive improvement work as well as to be able to establish internal/external expectations as to the team’s turnaround time on specific items. The main chart/report used to visualize and analyze Cycle Times is the Cycle Time Scatterplot where teams can understand their Cycle Time trends, distributions, look at anomalies.
The number of work items “finished” per unit of time.
Note the measurement of throughput is the exact count of work items, without any compensation for item size – which is a major difference between throughput and story-points based velocity. Throughput is measured at a certain step in the workflow, typically at the finish line of the workflow. Throughput can be visualized via a separate run chart or by looking at the angle of curves on a Cumulative Flow Diagram.
Work Item Age
The amount of elapsed time between when a work item “started” and the current time.
WIP and Cycle Time are classic metrics every Kanban practitioner is probably familiar with and throughput is somewhat similar to Velocity.
Work Item Age is the new guy on the block. Work Item Age complements Cycle Time. If Cycle Time is a lagging indicator only relevant for finished items, Work Item Age is a leading indicator only relevant for non-finished items. The basic idea is to provide transparency to which items are flowing well and which are sort of “stuck” even if not formally blocked.
I’ve been using some variant of this metric with most Kanban teams I’ve worked with. I also worked with several Kanban tool vendors to introduce some way to visualize card/item age.
Age on its own is interesting but not enough. We also want some indication of flow health. One common thing to visualize is the age in the current step in the workflow also known as “cards that didn’t move recently”.
Another way to look at it would be to look at the overall age but combine it with where the work currently is in the workflow as well as what the team expects their cycle time to be (We call that expectation Service Level Expectation (SLE) in the Kanban guide for Scrum teams and the PSK class). Combining all this information can help the team focus on the items that are at the most risk of missing the team’s expectations/SLE. For example, let’s say a team has an SLE of 16 days with 85% confidence. If one of the cards on their board has an age of 10 days, is that ok? is it a problem? The answer is that it depends. If that card is very close to the end of the workflow it is probably not a problem. If it is very close to the start of the workflow it is probably an indication of a problem that requires attention. The “Aging Work in Progress” chart below provides this perspective of both where active items are in the workflow, what the typical cycle times for this team are, and based on that which items are indications of flow risks (obviously orange-red means very low probability of finishing within the team’s flow expectations).
To sum up – Work Item Age is the best metric to look at if you want to determine when an item that has already started is going to finish. This is in contrast to an item that hasn’t started – where your best bet is your historical Cycle Times. The Service Level Expectation is just an expectation set by the team to themselves answering the question “What Cycle Time do we expect to see for an item of this type, and what is our confidence level for this?”.
Note: The charts above were created using the demo version of ActionableAgile Analytics – a tool created by my co-steward of the Professional Scrum with Kanban class – Daniel Vacanti. You can access the demo yourself and play with these metrics and think about how they would help your Scrum team.
Using the Flow metrics in the Scrum events
So how can these flow metrics be used to improve the Scrum events? This is one of the key learning objectives in the Professional Scrum with Kanban class. In a follow up discussion with some of the Professional Scrum Trainers who attended last week’s class, we came up with a matrix mapping the metrics to the events. (credit Maarten Kossen)
I’ll explain –
Sprint Planning mainly leverages Throughput in order to create a realistic forecast for the Sprint Backlog. Work Item Age might be relevant when you have some items left over from the previous Sprint and you want to decide what to do about them.
The focus of Daily Scrum is the ongoing flow within the Sprint so naturally what we care about is what’s currently going on. Therefore, Current WIP and Work Item Age are the most important metrics in the Daily Scrum.
Sprint Review includes a review with stakeholders of both the Increment as well as overall flow behavior of the team – trends in Cycle Times and Throughput are interesting. Throughput can also be used as part of release planning/road-mapping discussions, especially when combined with Monte-Carlo simulations provide some better visibility/confidence into “What can be done by when”. NOTE: It is always important to emphasize that these are projections/forecasts, not commitments.
Sprint Retrospective is all about inspecting and adapting the process and the workflow. Therefore it is the place to look at WIP, Cycle Times, Throughput from a perspective of looking for areas to improve.
As part of our belief that Agile should span more than just the product development/IT department and can actually benefit other areas of the organization, we spend our time practicing and evangelizing Agile in other areas in the organization. Marketing is one of these areas. I recently gave a talk at the Midwest Digital Marketing conference introducing Agile Marketing and telling the story of how we helped introduce it at CA Technologies.
Here’s the video from that talk –
Agile Marketing at Scale - Yuval Yeret at MDMC18 - YouTube
Sometimes you stumble upon amusement park methods.
Remember the feeling when first going through the gates of a big amusement park? When you get a first glimpse of how vast it is? you see some rides close by and at the distance you see the tall roller coasters. That’s the feeling I’m talking about.
You start scrolling through the method. Just to understand what’s before you, you want to see how long it gets. You scroll and scroll and it goes on and on, and you start to go faster but it never ends. As Louis and Clark tried to find a path through the Rockies to get to the Pacific, you are making your way through this monstrous method, this fantastic creation.
As you progress you discover gems, places you would like to have the time to appreciate. You see static methods, more and more of them, this one reaching the database, this one getting some configuration data, that one directly contacts some external interface.
After clearing some dense string manipulation statements you see a variable that looks familiar. It is called “Type”. You decide to go back and indeed it is referred throughout the method. You immediately think of polymorphism.
You continue. Something new appears at the bottom of the screen but you’re still not sure. Could it be? You scroll down some more and it is revealed in its full magnificence. A colossal If-Else statement, something that shadows everything you ever knew. It goes on and one. Endless identations with complex conditions. It must be the creation of generations upon generations of developers. Like stalactites, this is a magical creation of nature.
You need to make a small change. You find the exact place. What will you do? Will you just make it and run the entire flow? That might work.
It might work but it wouldn’t do.
You are a professional.
Would you miss all those great rides?
You decide to tame the beast. It is just you and the machine.
You want to handle it all together but you know it is too risky. The stakes are high. At any moment someone might come up with something more urgent to do and you will get stuck with nothing.
So you extract a small part of the method, the area where you need to make the change, to a different method. Sometimes it will be to a different class. You replace all the static calls with objects that will make the static calls in production but in the test will return whatever it is you tell them to.
You write one test to run the new method. To make it pass you compose the fake data. It passes. Once you have the basic infrastructure more and more tests are flowing through your fingers. You cleared the area for work. You have the method under a harness.
Now you write the tests for the change you need to do and indeed it fails.
You make the required change and the test passes.
Feeling satisfied you look at all the good the method has yet to offer. You wink at it with a promise for another visit. You mount your horse, tip your hat and ride into the horizon.
When I talk to marketing teams, Content is one of the areas with the most desire for achieving agility without losing your sanity. Here is a guest post by Alex Novkov from Kanbanize about how they kept Content Marketing Agile.
Content is King! This famous quote of Bill Gates remains true over two decades after its inception. Therefore, it is no surprise that marketing teams invest a significant portion of their efforts in creating and promoting content.
However, the typical content marketing process is anything but agile.
It is a common practice to plan the content that needs to be created for months ahead. Similarly to the Waterfall method in software development, this makes it hard to react to sudden changes, which are not that uncommon in marketing.
Get Rid of the Content Calendar
Implementing some sort of a scheduling system is necessary to ensure steady content delivery. On the other hand, planning in detail specific content months ahead of time is anything but agile and can easily turn into pure waste.
The major culprit for this is the fact that marketing is very dynamic by nature and today’s plans might not be relevant for the day after tomorrow.
The problem with most content planning systems is that they were not created with the idea of agility. If we look up in Google for a template of this sort, the results show mostly excel tables going in far too much detail about when the content should be published.
This is totally unnecessary when you’ve got a marketing Kanban board in place.
How We Did it at Kanbanize
Back in the days, at startup level, with very limited capacity, we didn’t need a content management system. However, as we grew and more people joined our team, we had to plan what we want to publish in the near future so that we can optimize our capacity.
While I was still not adept enough with Agile, I insisted on implementing a content calendar and I spent a considerable amount of time brainstorming for topic ideas and outlining content plans.
Even though I didn’t want to turn our process into a waterfall and carefully considered how far ahead it is acceptable to plan, we lost a significant part of our agility because the team was so focused on complying with the schedule I’ve made that they often overlooked activities like link building and social media promotion.
After a month or so of struggling to adapt, we decided to forget the content calendar and turn the requested section of our Kanban board into a content scheduling system of a sort.
We broke down the requested section of our board in two columns:
Near future became our backlog of ideas. Every content idea was listed as a card in that column. In order to distinguish between the different formats like video, infographics, etc., we agreed to use specific tags for each card.
Priority turned into our weekly calendar. We started pulling cards from Near Future to Priority every week. Our goal was to stay flexible and focus on the content that we need now, not 3 months in the future.
How Did We Ensure a Regular Delivery?
We agreed to publish new content on a specific day of the week. In order to have time to do some finishing touches, we decided that a new piece of content must be finished no less than 4 days ahead of the publishing day.
In order to be able to react to sudden changes, we decided to keep one piece of content per section in reserve. This way even if we failed to meet our internal SLA, there was no danger of missing the publishing window.
If such thing was to occur, we just had to invest a bit more capacity in creating an additional piece of content the following week so we can get back on track.
So basically we started pulling new content cards every week from Priority and published them with one week delay (unless there was an emergency). This provided us with the opportunity to do timely promotion and start creating new content when we’ve got capacity without reducing the promotion cycle.
Content Marketing Board
As our process evolved, we did a few board layout updates. Currently, our content creation steps are as follows:
After a new piece of content is ready to be started, a team member pulls it in the first In progress phase of our process – Conceptualization. It consists of 3 steps visualized as board columns:
Working on – here we prepare detailed content plans, clarify the buyer’s persona and list the main pain points that we are going to address.
Ready for review – this serves as a waiting column containing cards until we’ve got the capacity to evaluate a concept
Concept review – a team member does a review and suggests improvements
Afterward, the card moves on to the working phase where the author prepares a draft version of the content.
When the first draft is finished, it moves on to a thorough review stage that consists of 4 columns:
Ready for content review – waiting for an editor to become available
Content review – review of the draft for facts, style, grammar, etc.
Ready for SEO review – waiting for an SEO specialist to become available
SEO review – thorough SEO review
When there are corrections that need to be made, the card goes to a follow-up column.
Once the card is ready, it moves forward to a step where it waits for final touches (graphics, layout, etc) before being published.
As soon as a piece of content is published, the card is placed to Done and another one is created for the promotion cycle.
Forsaking the content calendar and creating new content only for the near future improved the agility of our team drastically. It allowed us to optimize our capacity and improve the way we react to sudden changes.
We learned the hard way that a properly-structured Kanban board and good internal collaboration can be more valuable to our productivity than any complex scheduling system.
Alex Novkov is the content lead of Kanbanize, a company developing Lean Kanban software. Seasoned Kanban practitioner, Alex has dedicated his time to educating the world how to be more efficient.
It’s been so exciting to hear so much positive feedback and interest in the new Scrum.org Kanban for Scrum Teams guide and the accompanying Professional Scrum with Kanban class. Creating the class and guide together with Daniel (Vacanti) & Steve (Porter) and then working on getting it to market in a professional way (how else? ) with the Scrum.org staff has been a great experience and a major focus area for me in the last couple of months.
As you might imagine, together with the interest come some questions about some choices we made in the design of the guide and the class. Several are emerging as the frequently asked ones. I wanted to tackle a couple of those in this post.
Where are some of the core Kanban practices?
The major one we’re getting comes from people who are experienced Kanban practitioners who notice that how we describe Kanban in the Kanban Guide for Scrum Teams is different than the definition they’re familiar with. (Including my Kanban Primer for Scrum Teams blog post for example…) This isn’t an oversight. It’s by design. When we set out to create the Kanban Guide for Scrum Teams/approach we had a specific context in mind. That context is teams using Scrum according to the Scrum guide, ideally professionally.
In the Kanban Guide for Scrum Teams, we focus on helping in this context. These teams already have a collaborative inspect and adapt experimentation process together with a set of explicit feedback loops they’re using. So, we set out to define the minimal simplest set of Kanban practices that these Scrum teams would need to add in order to achieve steadier, healthier, more sustainable flow (I like to say it is like moving from a sprint that looks like a swamp to one that looks like a river).
After some discussion we decided that these practices actually complement what a professional Scrum team is already doing :
· Visualization of the workflow
· Limiting WIP
· Active management of work items in progress
· Inspecting and adapting their definition of “Workflow”
While we agree with the importance of “Improve Collaboratively (Using models and the scientific method” and “Implement feedback loops” we think they are redundant in a professional Scrum context.
Where are some advanced Kanban concepts like Classes of Service, Cost of Delay, Flow Efficiency?
They’re not part of the guide because we don’t consider them part of the “Minimally viable set of practices” a Scrum team should focus on when trying to improve their flow. Having said that, our guide and especially the PSK class provides people with some pointers towards advanced complementary Kanban/flow practices/metrics that at least some can use to continue their learning and improvement journey.
Beyond that – Some of them might be useful in some Scrum contexts, some less so.
Is this an application of the Kanban Method or not?
In my personal view, it is pretty close, as long as you assume professional scrum is your starting point. (see a blog post I wrote back in 2012 about this context). You are starting with the way the team uses Scrum and with respecting their current Scrum process & roles. You are obviously interested in pursuing an incremental evolutionary change to improve your performance and satisfaction with your process beyond what you’re currently achieving with Scrum. There is that argument that limiting your work in process is far from being an evolutionary change but rather a disruptive revolution. My personal take on it is that yes, limiting your work in process and moving to a disciplined pull mode is far from being easy, but it’s still evolutionary compared to changing team structures, roles, process flows. And in any case, this is an argument about the Kanban Method outside of a Scrum context as well. A professional Scrum team should actually have an easier time limiting WIP than most.
Is this ScrumBan?
Depends who you ask. Some people’s definition of ScrumBan is “A way to help teams transition from Scrum to Kanban”. This isn’t what we’re talking about here.
Another definition (that I subscribe to) is to see ScrumBan as a way to introduce Lean/Kanban flow into a Scrum context – while keeping the core Scrum process intact. This is pretty similar to our take on the process Scrum teams will typically take to get to an effective combination of Scrum and Kanban.
Finally, a variant on this definition is to see ScrumBan as simply the Scrum+Kanban combination itself, without worrying about your starting point and journey. This, in my view, is indeed what the Kanban Guide for Scrum Teams describes.
Why/When should you add Kanban to Scrum?
The last question I want to tackle is one of the first you might want to think about. Essentially the question is “Why bother? Isn’t Scrum great as is?”
Most of the teams I’ve worked with since 2010 or so find Scrum+Kanban to be the ideal mix. I’ve helped Scrum teams achieve an even healthier smoother flow by adding Kanban to their process. I’ve helped Kanban teams accelerate their pace of improvement by adding cadence/rhythm and clarity. I’ve helped teams look beyond their Sprint at the end to end flow all the way from idea to outcomes using a Kanban system. I’ve helped organizations manage the flow across several Scrum teams using a Kanban system.
When a Scrum team wants my opinion on whether adding Kanban would be a good idea I typically ask them to think about how hard it is for them to Sprint and whether they feel like they have good flow during the Sprint. (And like I mentioned above – do they feel like their process is a swamp or a river). It’s as simple as that. I find most Scrum teams struggle to achieve good sustainable healthy flow and Kanban tends to help them with that.
When is Kanban with Scrum a bad idea?
Some Professional Scrum Trainers asked “When would it be a bad idea to introduce Kanban to your Scrum? What are some indicators that you should stop using Kanban as part of your Scrum?” I can’t think of any team where I thought they should stop using Kanban. If they understand Kanban and do it well, there’s really little that can go wrong. The problems start when they don’t understand Kanban or use it as an escape from the challenges of Scrum. Yes, Kanban can help you make your Scrum more sustainable and healthy, but please don’t add Kanban if you’re looking for an escape from the difficulties. Kanban done well adds discipline to your Scrum. Another bad time to introduce Kanban is when the team isn’t looking to improve. If things are working well or more importantly if the team perceives things as working well, they won’t have the energy needed to successfully add Kanban to their process. So make sure you agree on pains/motivations before you move forward to implementing something like Kanban.
Kanban – A way back to Scrum!
To finish with scenarios where introducing Kanban IS a great idea – It pains me every time I see a team/company using Scrum as a new variant of “project management command and control” focusing more on tasks, story points, velocity and burndown than on empiricism leveraging Done Increments of potentially releasable product.
What I’ve noticed is that introducing Kanban ideas helps these teams/companies finally understand what Scrum really is about and shed a lot of the unnecessary and even harmful baggage and instead refocus on the transparency, inspection, and adaptation brought to life by the core Scrum events, roles, and artifacts. Pretty amazing isn’t it?
It’s been sometime that they have been forming, carefully learning each other, sometimes from afar. Each person was doing their own stuff, limiting their interaction to consultations. Every person to their own.
However pressure from the outside made team members understand that this is not good enough, they need to increase their performance. Being on a team means doing things together, which is much more than helping when asked.
However this is not an easy thing to do. It means they need to get closer and remove some barriers. And this creates conflict.
The attempts to work closer together brings with it the storm. When we lower our shields, to be able to better interact, we become vulnerable.
People start to argue, argue because they care. Some arguments become nasty. temporary coalitions are forming. People discover the good and bad of other people. The atmosphere heat up.
When organic matter transforms to compost it heats up. There’s a lot of activity. a lot of energy is released in this process. The storming stage of a team releases a lot of heat also. You need energy to transform. But it is worth it. A team that went through this process functions on a different level altogether.
Alas, an issue with this process, as my friend Michal points out, is that, like compost, sometimes it stinks.
When we build the team’s board for the first time there’s many times the question of how to represent work in progress, how to show what’s going on between “Ready/Committed” (The backlog of the sprint, items ready to be developed) and “Done”.
There are usually two main options.
The first option is to have the below four columns:
Dev – WIP (Work On Progress)
Dev – Done
QA – WIP
QA – Done
For teams moving from waterfall or practicing a variance of Scrum-But (we do scrum but …) this pattern is not too frightening and preserves a respectful barrier between Dev and QA.
The second option is to have just one column between “Committed” and “Done”: “In progress”.
As I’ve written before in another post , if stories are small enough we shouldn’t need to have the four columns. That’s a trick here, though.
The issue is similar to the chicken and egg question: what came first. If we move to just one column prematurely, while dev and QA work is quite separate, we will not see where things stand. Cards will be stuck for a long time on the “in progress” column, waiting for someone to do something.
On the other hand, not moving to one column preserves the separation between QA and Dev.
The solution I found for this is having an open discussion with the team (the entire team), laying out the options and trying to get them to make a decision. My experience shows that in most cases the team will opt for one column. This will usually come near the end of a workshop in which we talk agile, scrum etc. I explain that moving to one column will require a change in the way they work.
As long as the decision is made by the team it usually works. I’ve seen teams go through this change, starting to work closely together. There’s a lot of energy at the beginning and after some days issues start to surface and the team handles them.
If the team opts to stay in Dev, QA separation that’s fine. We can raise the issue again some weeks later, in a retrospective session, openning the issue for another discussion.