Vima is based on Scrum and Visual Management. Before deciding to use Vima, ask yourself: am I sure Scrum does not cover my needs? If you are working in a product development or project environment, most likely you should stick to Scrum. Choosing Vima over Scrum when Scrum is a viable option is an anti-pattern.
If you are convinced Scrum is not a good fit due to the nature of the work to be managed, then go ahead with Vima. Assuming you already master Scrum to a certain degree, start your Vima path by focusing on your personal agility and productivity needs.
Implement personal Vima to understand the main concepts such as how to integrate calendars with backlogs and how to manage multiple concurrent value streams and date-constrained tasks. Once you are confident you have mastered this, you can move to implementing Vima at the team level.
To roll out Vima in a pilot team, follow these steps:
(Pre-kickoff) Understand your starting point, your work and your team. Train team members.
(Kickoff) Define catalyst team leader, create initial working agreements, build and populate your initial VIMA boards.
(Run and Stabilize) Start your first sprint. Iterate and improve your Vima process quickly until you reach your comfort zone.
In more detail:
Pre-kickoff - Understanding your starting point
PART A: The Team
Who are you (in an abstract way)? Why are you here?
What is the name/identity of the group/team?
What is the vision or mission that binds you together?
(optional) Where do you fit within your organization?
What does success mean to you? How will it be measured?
What does failure look like?
Who are you (concretely)?
Who is in your group/team? Are you more of a group or of a team? Are there any part-time people or people in weird situations? Describe.
How are you structured from an HR perspective?
What skills/specializations do people have?
What roles/job positions do people have?
What are your SWOTs (strengths, weaknesses, opportunities, threats) as a team?
PART B: The Work
What type of work do you do? Are you more focused on BAU ("Business as Usual" or operational work) or on product development/projects? Or a balanced mix? Describe the different types of work you do and try to put a % of capacity it takes and relative importance or value to the organization.
Recurrent standard operational work (eg: check bank account)
Non recurrent, non urgent standard work (eg: training registration)
Urgent standard work (eg: customer regular phone call)
Urgent, non standard work (eg: training emergency)
Products and Projects
What types of work granularity have you defined? What do you call them? (describe size, business value, type of work, etc) (try to map to TSFE sizing framework)
PART C: The (current) Process
We need to understand how you are currently working in order to baseline our starting point.
How do you currently plan, prioritize and visualize your daily work?
How do you plan real-time? (deciding next task to take)
How do you deal with unplanned, urgent work?
How do you deal with delegated/waiting work? (not forgetting to follow up)
How do you plan and visualize your week or sprint?
How do you visualize deadlines and SLAs and plan for them?
How do you estimate cost and value of your work?
How do you visualize and prioritize planned work among different value streams and work types?
How do you plan your quarter/semester/year? (roadmap)
How do you manage your project/product work?
How do you divide into PBIs?
How do you currently measure delivery? (output, outcome and quality)
PART D: Training
If team members have never been trained in Scrum fundamentals, organize it and deliver it. Any Scrum foundations 1 to 2 day training should suffice.
Kickoff - getting started
Define Catalyst Team leader role.
Facilitate initial Roadmap & Mission Review workshop
Define or reconfirm Team Charter and Mission.
Create initial Team Roadmap
Define initial team working agreements, including DoRs, DoDs and rules about how to prioritize and visualize day to day work.
Define team metrics and KPIs.
Map team work types into Vima Multi-backlog, creating initial multi-backlog board.
Optional: Define policy for reviewing product increments, if any.
Facilitate initial Quarterly Planning in order to populate the multi-backlog board
Conduct tactical refinement on the top portion of work
Conduct initial Vima Weekly (Sprint) Planning and populate initial Weekly Taskboard (Vima Sprint Backlog)
Stabilization
Start your first Vima sprint. Do your daily plannings. Figure out if you need a daily board. Deliver your work. Get feedback. Celebrate your achievements.
Iterate and improve your working agreements and quality standards through continuous retrospection and Kaizen events until the team finds basic stability.
Implement a Vima Maturity Assessment to baseline, improve and monitor your level of agility.
Align with the broader organization and avoid becoming an "agile silo"
Remember: no matter what approach you take to implementing Vima, make sure you understand Vima tradeoffs first and you are sure you cannot solve your team's situation simply with Scrum. A good Vima coach can guide your Vima implementation and give you advice. A poorly chosen Vima implementation will lower your agility ceiling and lock you into a local optima. Avoid choosing Vima because it is an easier solution that requires no difficult changes!
Comments