Vima Framework illustration
Roles and Process
3-level planning
Vima Definition
Vima is an Agile method (or framework) for business teams and personal agility.
Vima is specifically designed to support business teams and personal agility. The key characteristic of Vima and its target audience is that innovation and product development work is NOT the main type of work to be managed.
Vima excels where other frameworks do not: managing the chaotic, unpredictable nature of business environments where you have to juggle multiple types of work streams (products, projects, repetitive tasks) with deadlines, dependencies, recurring activities, interruptions, emergencies, etc.
Vima allows business teams and individuals to reap the key benefits of agility: adaptability to change, ability to focus while embracing uncertainty, clear prioritization, strong teamwork, transparency, continuous improvement, sustainable pace.
Vima was developed by combining Visual Management patterns with many ideas from Scrum to create a scalable framework that can go from a personal approach all the way up to an organizational design exercise.
Vima is short for “Visual Management”.
Vima was previously published as "VMF".
Vima Variants
Vima Personal
Vima can be used by individuals and by teams. In both cases, the personal productivity dimension of Vima is present. Vima guides you in coming up with ways to visualize and manage your personal work in order to maximize value while maintaining sustainable pace. You learn to build and prioritize your personal backlogs, estimate your capacity, manage your flow, focus on what matters, and communicate transparently with other people in your team and organization about what you are working on, what is coming up, and what is blocking you from making progress.
Vima Team
When used as a team and organizational framework, the Vima Team sits at the center. A Vima team is a small number of professionals dedicated to achieving the team's mission, as outlined in the Team Charter. The Vima team is composed of a single Catalyst Team Leader and a number of skilled team members.
Vima Teams are cross-functional, meaning team members have all the skills necessary to deliver the team’s mission and meet the team’s Definitions of Done. Despite having a Team Lead, they are also self-organizing - they internally decide who does what, when, and how. A Vima Team is typically 10 or fewer people.
The Vima Team is responsible for all mission-related activities such as service delivery and operation, direct customer interaction, stakeholder collaboration, quality assurance, research and development, and anything else that might be required to achieve the mission. They are structured and empowered by the organization to manage their own work. The entire Vima Team is accountable for the value and ROI the team delivers.
Vima Roles
Vima Catalyst team leader
The Catalyst team leader serves the Vima team with a catalyst mindset and behavior. This combines product/service visionary leadership with people leadership.
Catalyst team leaders:
-
Coach and mentor team members in becoming better technically and as people, focusing both on hard and soft skills.
-
Are responsible for driving the discussion on how to maximize the business value and ROI the team delivers under the current team mission.
-
Are the point of contact between the team and the rest of the organization when direct interactions are not feasible.
-
Are responsible for facilitating the definition, measurement and maintenance of team KPIs and any other team metric defined by the team or imposed by the organization.
-
Are responsible for facilitating the continuous improvement of team processes and practices, and the continuous evolution of the team's mission and charter.
-
Are responsible for facilitating the team’s stakeholder management activities, including demand management, presenting deliverables and obtaining feedback when applicable.
-
Are a technical and domain expert in whatever product or service the team delivers.
-
Prioritize the work of the team when this is necessary (especially when dealing with unplanned work, or with multiple competing stakeholders and value streams).
-
Are the line manager of team members unless members belong to a CoE with line management.
-
Remove team impediments and unblock the team when necessary.
-
Make tie-braking decisions when necessary.
Vima Team leads must learn to show up as Catalyst Leaders (see Pete Behrens - Agile Leadership Journey and Bill Joiner - Leadership Agility). To achieve this, Vima leaders must be trained and supported appropriately. Catalyst leadership is an advanced phase of leadership development which requires diligence and practice to achieve.
Additional Vima Roles
Expert team members (ideally max 9 people)
Team members operate and deliver the core business of the team. They are technical experts in one or more skills required to fulfill the team mission. They can be specialists or generalists. T-shaping (generalists) is recommended as it will give a team more flexibility. Vima teams are cross-functional and have all necessary skills to deliver the business service that the team owns or operates. Vima teams are self-organizing. Team members are coached to maximize collaboration and encouraged to live the Vima values.
When managing their personal work within the team, expert team members are encouraged to implement Vima Personal. This is especially important if team members belong to multiple teams or if they want to combine managing their personal life with their work life. In post-pandemic life this has become even more relevant.
Stakeholders
Vima stakeholders can be of four types:
-
Leadership
-
Suppliers
-
Compliance
-
Customers
Leadership stakeholders are expected to attend meetings that are relevant to them, particularly review meetings and strategic refinement meetings, in order to stay informed on the Vima team’s work and provide relevant feedback.
Customers are a special type of stakeholders - Vima teams will reach out to them frequently to obtain direct customer feedback and will try to build a relationship of trust and co-creation.
Other stakeholders will receive specific invitations and frequent opportunities to give and receive feedback to and from the team as deemed necessary.
Vima coach
The Vima Coach is the expert in Vima and in Agile who teaches the team and the organization Vima and helps them set up. A Vima coach is mandatory during team bootstrapping but will become optional as team maturity grows and becomes unnecessary once a strong and successful catalyst team lead is developed.
Vima coaches can coach several Vima teams simultaneously. How many depends on their seniority and the speed of Vima adoption. A typical number of teams an experienced coach can handle simultaneously is 3 to 4 teams improving at full speed.
(Optional role) Technical CoE coaches
Technical coaches belong to a CoE (Center of Excellence/Expertise) relevant to the team and will coach the team into advanced technical practices necessary for the team to grow and evolve their seniority, productivity, quality, etc. Usually Tech Coaches are very specialized and continue to pursue a technical career path as opposed to to a catalyst leader that comes from a business background but is shifting to a leadership track.
Vima Events & Activities
-
Vima Roadmap & Mission Review
-
Vima Quarterly Planning
-
Vima Strategic Backlog Refinement
-
Vima Tactical Backlog Refinement
-
Vima Weekly Planning aka Vima Sprint Planning
-
Vima Daily Planning
-
Vima Weekly Team Review & Kaizen Retrospective
-
Vima Product Review
-
Vima Quarterly Team Review
-
Vima Quarterly Kaikaku Retrospective
Vima Roadmap & Mission Review workshop
What:
-
Review and reconfirm or update the Team Charter and Team Mission
-
Update team Roadmap, adding significant milestones or product goals that are either date-constrained or projected for delivery.
When: At least once a year
Who: Vima team + selected stakeholders
Duration: 4 h max
Preparation: prepare updates to roadmap so they do not need to be discussed in detail during the workshop
Vima Quarterly Planning workshop
What: Analyze upcoming 3 months in the multi-backlog in order to forecast and align delivery with roadmap, detect capacity issues, dependencies with external teams, and any other constraint that might affect delivery.
When: every 3 months
Who: Vima team + relevant stakeholders (eg other teams, etc)
Duration: 2 h max
Preparation: Multi-backlog must be up to date, upcoming dependencies and risks identified
Vima Strategic Backlog Refinement
What: Add new PBIs to the multi-backlog, analyze impact on existing backlogs and planning
When: ad-hoc or based on team working agreements
Who: Vima team + stakeholders requesting work
Duration: ad-hoc or based on team working agreements
Preparation: none
Output: communication to impacted stakeholders if necessary (changes in priorities might affect their place in the queue)
Vima Tactical Backlog Refinement
What: Get upcoming PBIs to “Ready” (split, clarify, reprioritize)
When: once a week min
Who: Vima team (if necessary pulling in stakeholders ad-hoc for clarification or splitting)
Duration: 1 h max
Vima Weekly Planning (aka Sprint Planning)
What: Plan the week. Populate Taskboard, assess team capacity, publish delivery targets for the week.
When: At the start of the week
Who: Vima team
Duration: 1 h max
Vima Daily Planning
What: Plan the day, review impediments. Communicate delays to affected stakeholders if relevant.
When: At the same hour every day
Who: Vima team
Duration: 10 min max
Vima Weekly Team Review & Kaizen Retrospective
What:
Review what was done during the week, summarizing data.
Review what was not done, push to next week or cancel.
Communicate delays to affected stakeholders if relevant.
Discuss what went well and what can be improved (tactical/kaizen). Only small improvements or easy to make changes are discussed in this meeting.
Who: Vima team (ad-hoc stakeholders allowed as observers)
When: At least once every two weeks
Duration: 30 min max
Vima Product Review (Optional)
What: Optional meeting only for iterations working on product development
Review product increment deliveries with relevant stakeholders. Get feedback. Similar to Scrum sprint review. One meeting per product.
When: Ad-hoc scheduling when delivery of a sufficient PBIs are Done (guided by Scrum PO)
Who: Vima team, product PO, stakeholders
Duration: ad-hoc
Vima Quarterly Team Review
What: Quarterly meeting to summarize and showcase business value the team has delivered to Stakeholders in the organization. Metrics and KPIs will be shown, product and process improvements presented, etc. Can be integrated into a Quarterly Review.
When: Every 3 months
Who: Vima team, tribe leadership (if relevant), senior management/stakeholders
Feedback collected is input to strategic refinement, quarterly planning and eventually team mission and roadmap.
Duration: max 30 min
Vima Quarterly Kaikaku Retrospective
What: Discover, discuss and agree opportunities for improvement that require larger effort, change or buy-in. Optional: implement improvements in hackathon style.
Who: Vima team + optional stakeholders if necessary for buy-in
When: every 3 months or on demand if improvement backlog dries out
Duration: max 2 hours if only identifying improvements. Max 1 day if implementing improvements.
Vima Artifacts & Agreements
-
Vima Team Charter
-
Vima Team Working Agreements
-
Vima Team Roadmap
-
Vima Multi-Backlog (previously called Vima Team Story Map or TSM)
-
Vima Taskboard aka Vima Weekly Board aka Vima Sprint Backlog
-
Vima Backlogs (backlog types)
-
Product backlog(s)
-
Service or Value Stream queue(s)
-
Team improvement backlog
-
-
Vima Tasks (task types)
-
Vima Definitions of Ready and Done
Vima Team Charter
The Vima Team Charter describes who the team is to the broader organization and its “raison d’etre”. It talks about the value the team contributes and how it is measured. It describes the product or service the team builds and/or operates. It defines the Team Mission.
The Team Charter answers the following questions:
-
What is the name, mission and vision of the team?
-
What value does this team provide to the organization? What is the team business model or business case? What is the “outcome” or “impact” the team seeks to achieve?
-
What is the “product” of the team? What tangible output does this team deliver? (can be multiple products)
-
Who are the customers and key stakeholders of the team?
-
What are the team KPIs? How do you define and measure team performance and team success?
-
What are the key risks and constraints of the team? What is out of scope for the team? What are key dependencies of the team?
Vima Team Charter is created during the team kickoff workshops and updated regularly through inspection and adaptation in the Roadmap & Mission Review workshop, in the Kaikaku Retrospective or in an ad-hoc workshop if decided by the team.
Vima Team Working Agreements
Team agreements can be thought of as the “Team Playbook” or the “Onboarding document” of the team for new team members. They should document anything a person needs to know to become a healthy functioning team member.
Every Vima team maintains an updated, public definition of their Working Agreements. They are first created during the team kickoff workshops and evolved in team retrospectives.
Answers at least the questions:
-
What are the rules that govern daily life within the team?
-
What behaviors do we encourage and which do we frown upon?
-
What happens if you break the rules?
Can answer many other questions if decided necessary by the team itself.
The Vima coach will facilitate workshops during team kickoff resulting in the initial Charter and Working Agreements being created.
Vima Team Roadmap
The Vima team roadmap is a visualization of the mid to long term planning for the team. A typical roadmap could stretch for 6 to 12 months, but some teams like to have longer term roadmaps. As you go further into the future, roadmaps become more high level and subject to change. Roadmaps are intended to document and visualize the timeline/velocity aspirations of the team, and document important dates that are typically imposed on the team by external stakeholders.
Answers the questions:
-
What is the long term goal of the team in terms of delivery?
-
What are important milestones, targets or any other important dates we want to visualize for the team and its customers and stakeholders?
-
If the team has key external dependencies that are date constrained, they can also be visualized in the roadmap.
A Vima team roadmap can be visualized with any template that includes a timeline and the ability to indicate dates and milestones. A Gantt chart is a suitable tool if it is used with minimal features. A Vima roadmap should be easy to read and understand for a team stakeholder.
Vima Multi-Backlog (previously called Team Story Map or TSM)
A Vima Multi-backlog is a two dimensional backlog that features value streams or work types (projects, products, services, other teams) in the columns dimension and dates (weeks, months, iterations) in the rows dimension. Each column of a Vima multi-backlog is a traditional backlog, possibly with spaces in between.
Answers the questions:
-
What are the different value streams or types of work the team supports?
-
What are the backlogs of each of them?
-
What are the relative priorities between them?
-
What do the next 3 months look like? What do we currently think we will be working on?
Multi-backlogs can be rotated 90 degrees, and they can span more than 3 months.
Vima Taskboard (aka Vima Weekly Board or Vima Sprint Backlog)
A Vima Taskboard is a two dimensional planning and visualization tool that is used to plan and manage the work of the team during the week.
Answers the questions:
-
(after sprint planning) What are we planning to work on this week if there are no surprises?
-
(during the week) Who is currently working on what?
-
What fixed tasks do we have during the week?
-
How much slack do we have to take on unplanned items or work on backlog PBIs?
One dimension (column or row) represents each day of the week. It is pre-populated with fixed date tasks during sprint planning.
The other dimension can be free, or it can feature products and value streams similar to the multi-backlog, or even potentially have a row or column for each hour of the day, for example if the team has a lot of fixed-hour tasks.
Vima Backlog types
A Vima team can have one or more of the following backlog types:
-
Product backlog(s): A traditional Scrum Product Backlog, used if the team is building one or more products or to improve the services the team delivers. This backlog will be populated with PBIs and prioritized by the Product Owner of the product. If the product is owned by the Vima team, the Catalyst Team lead is the default PO, or alternatively a team member can be appointed as PO. Can also be used to manage team participation in legacy (non agile) Projects.
-
Service or Value Stream queue(s): A traditional Kanban queue, if the team is operating one or more services. This list will be populated with tickets and prioritized according to service level agreements and business rules. Note that every service operated by the team automatically creates a Product Backlog for the improvement of said service.
-
A team improvement backlog where the team captures improvement ideas that require work, typically as a result from kaizen or kaikaku retrospectives.
Each of these backlogs typically has its own dedicated column in the multi-backlog.
Teams have either business rules or working agreements governing prioritization and time allocation between backlogs (recommended), or it can be managed manually by the Team Leader working together with the team.
A low maturity Vima team should dedicate at least 5% of their capacity to their improvement backlog measured month over month. This includes the time dedicated to retrospectives.
Vima Tasks (task types)
-
Product task: this task is derived from breaking down a PBI and is the same as a Scrum task. It can be completed within one day, has a simple value stream, and delivers no value to customers on its own. These tasks are created when PBIs are decomposed - either during iteration planning or during refinement/DoR check. These are typically the lowest priority task that a Vima team does.
-
Service task: this task is similar to a Kanban ticket. It can be completed in a reasonably short amount of time, has a potentially multi-step value stream, and has a requesting customer or represents a BAU activity of the team. If the task has a multi-step value stream the task can include a checklist, or the task can be broken down into sub-tasks that are visualized and planned accordingly.
-
Date-constrained task: a Service task that has some time-related constraint.
-
Deadline (“Cannot finish after” date)
-
Plannable dependency (“Cannot start before” date)
-
Fixed date (Must be done at a fixed moment in time due to team working agreements or external constraints)
-
-
Delegated tasks and ERFM
A Service task that requires the team to first do some work, then pass it to someone outside of the team, then do some extra work to finish it. These tasks need to be managed when they are in the “waiting” state and have an ERFM attribute. ERFM stands for “Earliest responsible follow-up moment” - the earliest date the task should be followed up if not delivered by the dependency. This helps create fixed date follow up reminder tasks in the multi-backlog.
-
Recurring tasks
A service task that has to be done repeatedly on a regular schedule. When it is done it gets reprogrammed to the next scheduled execution date.
-
Urgent unplanned tasks and incidents
Urgent tasks take precedence over all else, similar to Scrum and Kanban.
Vima Definitions of Ready and Done
For each Product or Value stream backlog, there is a Definition of Ready and Definition of Done that govern when work is ready to be taken up by the team and what it means for work to be done. This is exactly the same as in Scrum, the only difference is that a Vima team has a different DoR and DoD for each work type.
DoRs typically deal with dependencies, clarity and work size.
DoDs typically deal with quality standards, technical debt minimization, completeness and organizational compliance.
About the authors
Xavier Quesada-Allue
Xavier Quesada-Allué is an industry veteran Certified Scrum Trainer, Certified Enterprise Coach, founding partner of Agilar, former president of Agile Spain and author of the "Visual Management Blog".
Joke Vandemaele
Joke Vandemaele is an industry veteran Certified Scrum Trainer, ICF PCC Coach, an experienced Product Owner with an MBA in Marketing Management and an expert in personal productivity.