Visual Management Framework (VMF) – Part 1

An Agile framework for teams outside of software, IT and product development.

This is the first in a 3-part series of articles describing the Visual Management Framework (VMF), a framework for creating Agile teams outside of software, IT and product development.

Part 1: Introduction and target audience

This article is for you if you are interested in Agile, Scrum and Lean and work in/with a team that has many of the following characteristics:

• Business team with BAU work
  • A large part of your work week consists of what is frequently called “Business as usual” (“BAU”) or operational work – somewhat repetitive, somewhat standardized activities that either constitute or support your core business and are considered value-added to your organization. The daily tasks might seem simple and repetitive to outsiders, but each task is somewhat challenging and has some risk and variation to it, as it involves dealing with people and data. It is not assembly line work.

• Deadlines
  • Work often has time constraints: deadlines, service level agreements, “cannot start before” date, “has to be done exactly at that day/hour”, etc. This means it is not enough to focus purely on priorities.
• Recurring work
  • There are recurring activities that need to be done regularly, otherwise things stop running smoothly and failure demand is created.
• Multiple types of work (multiple value streams)
  • There are different types of activities that have to be dealt with within your team. Often, these value streams are not universally prioritizable (i.e. it is not the case that “work type A” always has precedence over “work type B”)
• Projects
  • Your team is also expected to contribute to or deliver projects of different nature. Some of them are internal improvement projects coming from and benefiting mainly your team. Some are bigger or external projects where you are involved as a stakeholder, part time project team member, subject matter expert, etc. Often you are expected to work on multiple projects in parallel.
• Dependencies
  • Both your BAU and project work often involve interacting with 3^rd parties outside your team, creating dependencies which involve waiting periods and follow-up activities. These dependencies cannot be eliminated (at least not in the short term) due to multiple reasons (e.g. logistical, economic, technical, HR, political, legal/compliance, etc.).
• Emergencies
  • You also need to frequently respond to urgent requests from a variety of sources: customers, management, incidents, etc.

Your typical work week is a big mix of scheduled tasks, high priority work, recurring work, urgent-important stuff, firefighting, working on multiple projects at the same time, multitasking, context switching… This scenario can quickly lead to stress, chaos, and the feeling that you are overwhelmed and the situation is not under control.

Symptoms might include:

• No clear priorities You cannot reliably answer if you are working on the most important, most valuable things right now – there is too much on your plate. It feels everything you get to work on is urgent and important. You do not trust your prioritization process, or you don’t have one, or you have one but you don’t have enough time to apply it to classify and prioritize the work. You are not able to effectively balance long-term and short-term work.
• Forgetting stuff Too often you forget to follow up on something, or to do a task. This creates failure demand.
• Lack of project visibility You do not have good visibility on project progress. You are typically unable to forecast a delivery date for projects or give warning if you are falling behind.
• Lack of trust from leadership This creates a feeling among leadership that projects involving your team never get done, or don’t get done fast enough – and that your team is not reliable.
• Overworked You have the feeling the team is overloaded with work beyond its capacity, but you cannot prove it.
• Not a real team You might also have the feeling you are not a very effective team in general. You see opportunities for improvement regarding communication, collaboration, self-organization, shared purpose feeling, etc. If you have a leadership position within the team, you might feel you are micromanaging and burning out and not getting the results you hope for.

You might have heard of the benefits Agile methods have brought to the world of software development, IT, and product development in general. Maybe you have already dipped your toes in the agile waters, reading a book or taking a foundations training such as the Certified ScrumMaster from the Scrum Alliance. And you might have found that while the general message resonates and motivates you, most of the examples are IT-related and some of the learning objectives and practices are very IT specific – they don’t seem to fully cover or understand the reality of your team. You are looking for an Agile approach that embraces and works with the full scope of your team’s work, instead of fighting or ignoring it. Unfortunately, this approach doesn’t exist (yet)!

In large organizations there are a number of teams or departments that typically meet these criteria. Examples include HR teams, Marketing, Sales, Customer Service, Finance & Accounting, Quality Assurance, senior leadership (ExCo) and often also operational teams doing core business activities.

In small & medium companies the trend is even stronger, as there is a need for more cross-functionality and T-shaping. Admin departments and most operational teams from medium and small service organizations tend to meet the criteria. There are dozens of other examples across all industries, size and type of organizations.

It is actually easier to summarize the type of teams that do not fit these criteria. Teams that do not fit these criteria usually fall into one of these two categories:

• Dedicated product development teams that do primarily innovation work and are focused on one thing (software development teams, dedicated project teams, etc.)
• Teams that do primarily highly standardized, highly repetitive or highly unplannable work (factory teams working the assembly line, call center teams, emergency response teams, etc.).

For all the rest, the Visual Management framework (VMF) is probably of interest.

Part 2 of this article series will describe the core practices and patterns that constitute the framework.

Part 3 will describe some case studies and examples of the framework in practice.