Kanban is a methodology that allows an improvement in the workflow of the team by separating a production process into several phases that are perfectly delimited. Kanban means visual cards in Japanese, which are the key elements of this methodology along with the board.
The Kanban Method also allows organizations to start with their existing workflow and drive evolutionary change. It can be done by visualizing their workflow, limiting work in progress (WIP) and stop starting and start finishing. Kanban can be used in any work environment and is particularly applicable in situations where work arrives unpredictably and/or when you want to implement work as soon as it is ready, rather than waiting for other work items.
To implement Kanban, the STATIK (Systems Thinking Approach to Introducing Kanban) process is mentioned, which means “Systems Thinking Approach to Introducing Kanban”.
STATIK is a process based on systems theory to successfully implement Kanban in an organization.
Systemic thinking is a way of understanding how a system behaves as a whole rather than analyzing the component parts in isolation. It is the key in the process of introducing Kanban into an organization.
The order of the steps in STATIK may vary and it is normal to constantly review the steps in order to look for new improvements. This test serves to evaluate the state in which the organizations find themselves when integrating the Kanban methodology.
The steps in this process are not necessarily sequential, but iterative, and use one-step learning to inform and influence others:
Step 0: Identify Services. And for each service we must:
Step 1: Understand what makes the service fit the client’s purpose
Step 2: Understand the sources of dissatisfaction with the current system
Step 3: Analyze demand
Step 4: Analyze capacity
Step 5: Model Workflow
Step 6: Discover classes of service
Step 7: Design the Kanban System
Step 8: Socialize the design and negotiate the implementation
The follow-up of the implementation can be done by extracting ideas from the litmus test.
Within the teams KANBAN adopts 2 key roles:
Service request manager: It is responsible for understanding the needs and requirements demanded by customers, as well as simplifying, selecting and prioritizing backlog experts. He or she must decide what is next to pass the engagement point. This engagement point is the time when the work must be done and is where we will start to measure the response time of the team itself. Service delivery manager: This figure is responsible for helping the team work to flow tasks along the board in a sustained manner over time. Its mission is not to coordinate the team or assign tasks, but to play a role of observer and facilitator for the teams to make decisions and the system works. To do this, you will need to facilitate Kanban meetings and delivery meetings.
About the main meetings to establish:
Strategy: the project manager, the client and the request manager will participate in it. it would be the initial meeting, and we would repeat it once a month, to analyze the project strategy, review in each one of them how the project is going and analyze the follow-up of the selected strategy, to see if it is necessary to pivot or modify part of it. operations / risks and delivery planning: the project manager, the request manager, the service delivery manager and the client will participate in this meeting. The objective of this meeting is to propose an initial review to hold this meeting again every two weeks, in order to review bottlenecks in terms of resources and states, to be able to collect risk information and resource recommendations. At the beginning they will be marked with milestones in a timeline, and it would be carried out again every 15 days to prepare the strategy and adapt the changes that we are receiving in the version plan. Feedback: It will involve the project manager and request manager. It will be a weekly meeting to see priorities in the backlog according to blocks, dependencies and customer news. Kanban / daily: all project participants participate in this meeting. It will be daily at the beginning of the day with the dynamic round robin (what was done yesterday, what are we going to do today and impediments). The time of this meeting should be around 15 min and not exceed 30 min. retrospective / service delivery: All project participants except the client: the team meets to see which things have worked, which need to be improved or completely changed for a better dynamic, but also from the point of view of effectiveness.
An example of a board to be used with a single street with definition of states and associated policies:
Backlog: all the ideas and cards that are discussed in the strategy meeting that can be interesting for the new version of the web. Defined: here would be all the cards that have been discussed in the feedback meeting and that the Service Request Manager has come to have an initial description with an initial estimate (high-level) by the team and where the Satisfaction Condition and expectations of the client (the what) are counted. The prioritization is clear and ordered according to the value of the business and dependencies / risks. Ready: here would be all the cards that the Service Request Manager has discussed with the team to refine. It must have associated an accessibility/usability checklist, the Architectural Review and Security checklist defined by the roles involved in the project with particularities that the card must comply with and the associated test. The cards are divided to try to reach a balance of duration of approximately 16 hours / card. These cards are ready to be picked up for development. Implementation: here will be the cards that are in development, for their closing they must fulfill that unit test has been implemented. Test: the tests defined during the refinement of the card are carried out with the cases on usability and additional architecture / security. Devops: the deliverable is checked to align it with the deployment configuration, the results of penetration and performance tests are checked, as well as smoke tests to see that once deployed, the system is able to make a happy path on the application (login, basic functionality). If there are security updates on the servers, patching of vulnerabilities, this step is used to test it with the increase of the card. The step is closed with an Exploratory Test Chapter accepted by the Service Request Manager. The step to "Done" is carried out together with the petitioners of the cards for their Acceptance.
To control WIP, number of people available under that state need to be taken into account, using a factor 2n for every defined state as initial assumption to be monitorized. If there is a senior on team that might be good to be more time dedicated supporting rest of teams 2n-1.