The scale and size matter.
There is a different approach applied when implementing Kanban into a single team, larger department, or performing a fully digital company transformation.
In this guide, you will find best practices used to lay down the foundations that will help you scale and administer your Kanbanize account in large enterprise implementations with thousands of users.
DISCLAIMER: The following are just best practices and recommendations, but by all means, they should NOT be enforced as rules or policies. It is vital for a successful Kanban adoption that each team in the organization has the freedom to design and implement the Kanban method in the most suitable way for them so that it fits the team's existing workflows and then gradually improve from there.
I. Setup Agile/Kanban and Kanbanize.
The Kanbanize product is intuitive enough, and an average user should be able just to log in and start using the product without any additional help. However, this is not always the case for large enterprise companies. The workflows and the complexity there could reach levels beyond the regular user understanding and adoption. To deal with this problem, we suggest setting up a body of knowledge, a community of practice, or a team of power users to provide solutions for complex scenarios. Usually, these are Agile / Kanban coaches with extensive product knowledge of Kanbanize and as well as their company's environment and use case scenarios.
II. Entry for new users - Agile Portal with links and vital information.
There is a specific functionality (Kanbanize Teams) implemented to handle a vast amount of users. This is the ability to associate and group the users by Teams, Areas, or Departments. We have a "Global" team to which each new user is automatically assigned. To outreach those users and provide them with vital agile information about the company and all related topics, we suggest creating one general Dashboard and making it visible/sharing it with the "Global" team.
The dashboard could contain some of the predefined widgets showing the company's top-level goals and targets for the year, product-specific initiatives, or anything that is of common interest for all the users.
Using the RICH TEXT widget, you can create a table or a list of links and visualize the most important information for the end-users. For example, providing the contacts of the Agile Team set up in the previous point.
III. Setup company-wide common components and names
Each company (large or small) has its own language when it comes to common items such as work types, modules, structures, etc. For example, in a product company, problems found in a product could be called: "defects", "bugs", "issues" and so on.
To prevent having all kinds of acronyms, synonyms, and funny names and align the communication between the teams, we recommend that the owner (community) of the account prepares all common Card components and known company custom fields upfront before onboarding the teams.
IV. Workspaces, Boards, and Naming convention.
For some companies, it is very easy, for example, Workspace = Department and Board = Team, and that would be a great setup. This is the default way in Kanbanize to map your company organization, but this is not always the case. In enterprise companies, you could often have cross teams, virtual teams, different geo locations, dual reporting lines, temporary escalation teams, task forces, special client project groups, etc.
- In general, we recommend starting to set up boards and teams (bottom-up), like with the foundations of a house. Meaning, you get those teams that are known, solid, and work together for a long time, and you create a board for each such team and group.
- If you have small groups that could be part of a larger team, you could consider having a few workflows for each group as part of one larger team board. Ideally, each user should work on one board without board/workspace switching.
- Project or Virtual team activities. Instead of creating a new board with virtual members from other teams, you could represent that "virtual" team as a dedicated workflow that holds the initiatives (main activities) of that assembled team and those are linked/related to tasks inside the board of each "solid" team.
- Use a naming convention for the team boards. The system allows duplicates for other purposes and scenarios. Still, in enterprises, we suggest that the name of each important board should be unique and easily recognizable in the whole company. When you have many boards, using the filters, dropdown menus, etc., you need an easy and visual way to find out what you are looking for. You could use the search and easily filter by abbreviation or a name, but this brings many issues later on if there are similar boards.
Example: The Dev Ops team in Europe / Spain calls themselves "The Ninjas", would be something like this: EMEA: DevOps (The Ninjas) - Similar to above, when setting up Business Rules and you need to search and fix a few, later on, you will find it difficult if you leave the default names the system put. Like 10 rules named "Card is moved"! We suggest using something like an abbreviation for your scenarios or the team/department where the business rule is executed as it might be applied for several boards. Something like: [EMEA: Dev Ops](Support Email Scenario) - Card is moved as Ticket Auto Complete in 7days.
V. Color Schema - Lanes and Columns Colors, Expedites, and Types
The most powerful visual element of the card is the color. Color codes are very simple, easy to use, and well-known in many places. Traffic lights and signs, color stripes on the elements in the electronics industry, flags in sports, and so on. The color codes are especially good to bring information fast at a larger scale (like in the enterprise company). The "Dabbawalas" - Indian logistics food delivery system, is one of the many examples where five thousand employees with a simple set of indexes and a color schema can bring lunch boxes to over 200K customers per day and return the empty boxes back to their family owners, without any errors.
- If your company doesn't already have a color schema, we advise you to set up one. It could be something simple and basic like this:
- Red - Escalated / Expedited - ad-hoc requests that require immediate attention.
- Orange - Activities Related to Customer Requests
- Green - Internal Activities
- Blue - Recurring Tasks / Regular Day to Day Operations.
- ...
Example: Received cards/dependencies from other teams.
Note: Knowing the code, it comes naturally to figure out that we just got a task from another team related to a customer request, and we should pay the right attention to it.
- Have a dedicated Expedite swimlane and color the lanes to match the cards inside.
Note: Just looking at the board, one can see that there is one Ad-Hoc created very urgent item and one Recurring (Regular Task) that has been escalated, waiting to start work on. - Sub-columns and coloring.
Kanbanize already has 5 predefined colors that cannot be changed. Those are the "Section" or areas for:
- Backlog - Gray
- Requested - Blue
- In Progress - Orange
- Done - Green
- Archive - Purple
Those colors are fixed, and they are used on parent-child relations, for example, on the different portfolio levels to show status and execution progress in depth.
This way, you can see which card is complete, which one is currently being worked on, and what is in the queue! - Large companies have bigger teams and more complex boards, so we suggest using colors for "long" boards that have multiple stations (Queues and Working On columns) within the same workflow to match the color pattern above.
This way, you can see that in the Expedite, for example, the columns are merged. There are no queues, for example, for the really "hot" items that have full attention and no waiting time between stations. For the rest of the sub-columns, although they are inside the In-Progress area, they have natural start-end column marks as per each station.
VI. Enterprise Security.
Last, but by all means, not least is an important topic: to take the necessary measure to secure your Enterprise Kanbanize Account. Large Companies have IT Departments with specific Regulations and Policies when it comes to handling data, having strict password rules, security roles, and so on:
- The first thing we strongly recommend is to enable the SSO / SAML 2.0 integration to your Company IdP (Identity Provider). This way, IT can force the password and access security policies of all users. Those users don't need to remember yet another password, and they will be happy to have a single click login and open their board.
Note: You might consider setting up a Kanbanize Shortcut Link inside your Company Portal. - We have a special Security Control Panel that is mostly useful for large companies' special data management requirements.
- We would at least recommend disabling attachments and use links instead. Those could be added inside the card description, comments, or special custom fields to your company-wide file storage solution in place.
- After boards and workspaces are created, don't allow internal company Workspaces to be made available externally. This feature is mostly used for Consultants and Coaches to transfer Workspace Templates between their own accounts and the company they consult but could be used the other way as well.
- Depending on your organization, you might consider keeping only the Account Owners to be able to copy workspaces and boards to limit uncontrolled creations of boards and workspaces for all kinds of private, virtual, or temporary needs.
- The default behavior of the Kanbanize Account is based on Trials and Demos. Meaning default settings are for allowing features to be tried and to be easily used. In Enterprises, mostly because of the scale and the security policies in place, the default behavior is towards restrictions and having features disabled by default.
The same goes for API capabilities that are accessible by default, so we suggest the following:- Change the "default" role that most users have and un-check the API access permission.
- Setup another role dedicated for "API Access" users.
- Setup dedicated "API" users that you have internally mapped with responsible persons and use-case scenarios where those are used. This way, you know when a change is made by a real user or by an automation/integration API user.
- We have a special API method to automatically re-generate the API key. Use this in your integration and automatically re-generate and store your new key, like every week or month.
INPUT: POST https://<my_account>.kanbanize.com/api/v2/my/apiKey/generate?apikey
(HEADER: apikey: <your current api key>)OUTPUT: { "data": { "api_key": "<your new API key>"} }
If you have any troubles or need assistance with the setting and the steps above, you can always contact our support team.
