Kanban in IT design. practices

• Visualize your workflow

• Limiting Work in Progress (WIP)

• Controlling Workflow

• Ensuring Policy Transparency

• Continuous Improvement and Experimentation

Compared to some formative modern methodologies of agile project management, such as Scrum, Kanban is easy to grasp. This is its strength, so the use of Kanban can actually make change within how work is accomplished easier.

Consider how Kanban practices are implemented in the development team:

Visualize your workflow

Kanban in it base on principle that the team should be able to be see its work flow. The project manager focusing on the work flow chart can easily identify the areas of improvement.

It is important to note that all the developer activities are planned, monitored as well as displayed on the Kanban board. Daily and weekly meetings are facilitated to provide for the team focus as well as to work on the most important projects. Preventable events including bug correction work execution can be depicted using a different color to highlight they are faster.

Alternatively, a Kanban board for IT developers can have several workflow steps:

• Backlog: all functions/actions to be performed;

• Analysis: The slack needed to understand and analyze the problem, capture the requirements, define exit or done criteria, and consider different architectural approaches;

• Design: initial design engineering;

• Implementation: implementation of the solution;

• Validation: debugging and verifying the correctness of the implementation and its compliance with the criteria defined in the analysis phase;

• Done: The task/action matches the exit criteria.

It can have another urgent work flow that frees up time for those inevitable items that must perforce be made urgent. Still, this ‘band’ has to be used sparingly; Normally, one should not use the ‘less is more’ equation more than once or twice in any given week.

The fact that the Kanban board is visual promotes discussion within the team on how to manage time wasted within the team’s processes and methods.

Since Kanban visualization gives visibility of the whole process to the entire team, it is the first stage to letting the team improve the process. During the process of the work of the team, there is always time and opportunity for improving the process and adding or removing some steps on the board, the board reflects the process. This way of having the board also generates a discussion about it as it creates a mechanism and an opportunity. This is usually in the form of brief and specific daily meetings in which work progress and blockages are addressed (about shifting tasks through the workflow line).

Limiting Work in Progress (WIP)

Typically, the traditional way for how a team acts in the process of design work is provided by assigning multiple tasks/features that have to be developed simultaneously and by always having constantly coming meetings in which people have to critically think about bugs and define what is a current set of the so-called “quick” tasks that must be done as quickly as possible.

This results in wastage of time since one has to move from one work area to another to accomplish the tasks. The better approach in this case is to make sure every individual just get through the tasks that are assigned to him in the best way he can. It is meant for constraining works-in-progress this practice is used to avoid situations where many projects are ongoing at the same time.

Every project has limits: employees, computers, licenses, time off, for example, all these ought to have measurably defined and marked on the Kanban board. This is done by setting a WIP limit on each column on the Kanban board represents the limit in question. For instance, let there is an attempt to allocate some WIP limit to the phase of implementation. Finally, if we have four developers and assume here that a developer can deal with not more than two tasks at a time, the WIP is 8 (4 developers multiplied by 2 tasks). This determines the maximum number of tasks/activities in this process stage.

It is important to realise that Kanban is a pull system here. If, for instance, the project manager thinks that WIP limits means the number of open positions in each column, then, he, moves the task to the column if there is an opening. For example:

• the team cannot start a new item from the backlog if the analysis phase has reached WIP limits;

• however, as soon as any element in the analysis phase is completed, it can be immediately moved to the design phase if there is one free slot;

• there is no limit for the Done column.

The idea of pull is only can things be pulled from the right not pushed from the left. Besides, the team is required to set up gates to progress to the subsequent stage, meaning that the work has to be 100% complete. To accept something as incomplete will definitely be time consuming and by extension expensive. Receive of inactive works might be the curse of any IT project, let alone if their return to the flow is because of the system overload (failure to conform to WIP workflow limitations).

The important thing about getting to the backlog/analysis step is that it allows for the deciding which task or function has the largest relevance at the current moment. Because priorities shift over the course of a project based on such factors as newly acquired information or emerging technical difficulties, reconsidering on what should be introduced as soon as possible or as late as possible is especially useful when employing a continuous system, which is exemplified by Kanban.

As soon as WIP limits are set it is easy to identify bottlenecks since one or another component develops back pressure on preceding activities. Permitting more work to be in progress at the same time will mean that there is work which is held in the column for too long thus prolonging the task.

It worth to note that the first set of WIP limits that needs to be established for a particular project will not remain fixed and will most probably be subject to modifications over the course of the project. This is again normal and is as a result of such disruptions. Another approach is to look at the level of integration of tasks across the Kanban board and adjust WIP limits UP and DOWN in an attempt to make it absolutely ‘SWIM’.

Controlling Workflow

It is one of the priorities in the work of any organization to utilize the available resources in a project in order to solve all the tasks arising from the implementation of the project. The visual aspect as well as the work in progress limits mentioned in the earlier sections aids in identifying bottlenecks within this process and in the actual design; it assists the team to carry out the process from beginning to end in the most efficient manner.

Ensuring Policy Transparency

As the saying goes, "The best disinfectant is sunlight." This means that only when the policies are explicit can the problem be seen.

The rationale of this core practice lies in formalising the policies that may exist in the work, i.e. practices used in an organisation. Once formulated, they turn into ‘facts’ for the project, eliminating any possibility of subjective assessment and erasing the emotional component of development.

It is vital to have moments in which the process reviews that objective evidence or individual facts had been collected. These opportunities can come up with ideas for improvement that all the people concerned have to congregate on because what they are talking about is actual. Ideally, this feedback should take place as often as there will be sufficient evidence of a problem to warrant its occurrence. So the matter has to be taken through real debate which now and then may consume considerable time – weeks and even months.

The appearance of bottlenecks is also a time for the discussion of ideas. For ideas after discussion, the idea can then be placed on the backlog (or a task) and put in to work when the next time slot comes.

Daily meetings provide an opportunity to discuss issues objectively.

The Kanban board can therefore be considered as a physical element through which, people can discuss about the ‘board’ rather than the ‘person’. This way changing the focus towards the “task” field such as (“Why isn’t task A proceeding?”) would help the manager avoid a general issue like personalization (“Why does it take so long to solve task A?”).

Continuous Improvement and Experimentation

In the context of IT project implementation, Kanban provides critical metrics (such as cumulative CFD flowcharts) that can provide real insight into:

• the current state of the IT project;

• some idea of ​​the projected schedule for the future;

• some critical data is needed for planning.

All of this information fits into the existing logistical management reporting schema and can produce an even more accurate picture of the real status of a project than, for example, a Gantt chart.

Since Kanban is a continuous cycle, it makes sense and is possible to discuss the change of a workflow item at any time. In many cases, this is associated with the fact that the specified phase is continuously in a state of stagnation and, as a result, becomes the critical “bottleneck”. This means that the team has to come up with the solution on how to do away with the bottleneck or enhance the flow. Ideally, such a solution should be supported by the concrete empirical evidence pointing to the fact that bottlenecks are constant in this phase.

Once a decision is made to implement an improvement option it should be planned as any other activity and incorporated into the first phase, in this case the backlog and then done. During the future metrics gathering, the team must evaluate whether the idea is helping or harm the team’s performance.

The theory behind this core Kanban practice is that problems are identified from a long-term perspective, fact-based changes are made, and then the results are recorded to detect problems. Thus, improvement is cyclical and helps to optimize workflow continuously.