Kanban in Project Management - Revision history

Tkokotas at 13:10, 18 December 2018

2018-12-18T13:10:09Z

← Older revision		Revision as of 13:10, 18 December 2018
Line 1:		Line 1:
			''Developed by Marit Moberg Vossgård''


	Kanban(看板 signboard from Japanese) aims to improve visibility, product quality, communication, collaboration, workflow and highlight bottlenecks throughout a project, a process or similar.<ref name=Ahmad2016> Ahmad, O. M & Kuvaja P, C. F. (2016). <i> Transition of Software Maintenance Teams from Scrum to Kanban </i>. 2016 49th Hawaii International Conference on System Sciences </ref>. The Kanban system was originally a pull-driven <span class="plainlinks">[https://en.wikipedia.org/wiki/Just-in-time_manufacturing'''JIT (just-in-time)''']</span> inventory control system developed by <span class="plainlinks">[https://en.wikipedia.org/wiki/Taiichi_Ohno '''Taiichi Ohno''']</span>, an industrial engineer at <span class="plainlinks">[https://en.wikipedia.org/wiki/Toyota '''Toyota''']</span><ref name=ETFA2008 >Emerging Technologies and Factory Automation, 2008. <i>e-based inter-enterprise supply chain Kanban for demand and order fulfilment management</i>. </ref>[https://www.atlassian.com/agile/kanban]. The vision was that the system would reduce the waste <span class="plainlinks">[https://en.wikipedia.org/wiki/Muda_(Japanese_term) '''(muda)''']</span> in the production line and improve the manufacturing efficiency. The Kanban system is now, with some alterations, applied as an agile project management tool.		Kanban(看板 signboard from Japanese) aims to improve visibility, product quality, communication, collaboration, workflow and highlight bottlenecks throughout a project, a process or similar.<ref name=Ahmad2016> Ahmad, O. M & Kuvaja P, C. F. (2016). <i> Transition of Software Maintenance Teams from Scrum to Kanban </i>. 2016 49th Hawaii International Conference on System Sciences </ref>. The Kanban system was originally a pull-driven <span class="plainlinks">[https://en.wikipedia.org/wiki/Just-in-time_manufacturing'''JIT (just-in-time)''']</span> inventory control system developed by <span class="plainlinks">[https://en.wikipedia.org/wiki/Taiichi_Ohno '''Taiichi Ohno''']</span>, an industrial engineer at <span class="plainlinks">[https://en.wikipedia.org/wiki/Toyota '''Toyota''']</span><ref name=ETFA2008 >Emerging Technologies and Factory Automation, 2008. <i>e-based inter-enterprise supply chain Kanban for demand and order fulfilment management</i>. </ref>[https://www.atlassian.com/agile/kanban]. The vision was that the system would reduce the waste <span class="plainlinks">[https://en.wikipedia.org/wiki/Muda_(Japanese_term) '''(muda)''']</span> in the production line and improve the manufacturing efficiency. The Kanban system is now, with some alterations, applied as an agile project management tool.

MAVO: /* Annotated Bibliography */

2016-09-22T07:42:23Z

Annotated Bibliography

← Older revision		Revision as of 07:42, 22 September 2016
Line 167:		Line 167:

	<b> Agile Project Management with Kanban, By Eric Brechner.</b>		<b> Agile Project Management with Kanban, By Eric Brechner.</b>
	Eric Brechner is a development manager for the Xbox engineering team at Microsoft. He ~~have~~ previously worked in Bank Leumi, Jet Propulsion Laboratory, Graftek, Silicon Graphics and Boeing. While working in Microsoft Brechner ~~have~~ used numerous project management tools/consepts like <span class="plainlinks">[https://en.wikipedia.org/wiki/Waterfall_model '''Waterfall''']</span> and <span class="plainlinks">[https://en.wikipedia.org/wiki/Scrum_(software_development) '''Scrum''']</span> but now he quote: in the 2010s, I’ve found continuous deployment, Kanban, and a little nirvana.This book is a step-by-step recipe on how to apply the Kanban project management in your IT-group or organisation. Brechner is also the author of a book and blog on software best practices (as I. M. Wright), he holds eight patents and a Ph.D. in applied mathematics.		Eric Brechner is a development manager for the Xbox engineering team at Microsoft. He has previously worked in Bank Leumi, Jet Propulsion Laboratory, Graftek, Silicon Graphics and Boeing. While working in Microsoft Brechner has used numerous project management tools/consepts like <span class="plainlinks">[https://en.wikipedia.org/wiki/Waterfall_model '''Waterfall''']</span> and <span class="plainlinks">[https://en.wikipedia.org/wiki/Scrum_(software_development) '''Scrum''']</span> but now he quote: in the 2010s, ''I’ve found continuous deployment, Kanban, and a little nirvana''.This book is a step-by-step recipe on how to apply the Kanban project management in your IT-group or organisation. Brechner is also the author of a book and blog on software best practices (as I. M. Wright), he holds eight patents and a Ph.D. in applied mathematics.

MAVO: /* Limitations */

2016-09-22T07:41:28Z

Limitations

← Older revision		Revision as of 07:41, 22 September 2016
Line 153:		Line 153:

	==Limitations==		==Limitations==
	#'''Expertise''': If the team consist of highly diverse personnel with no overlapping knowledge fields, Kanban may not be the ideal tool. This is not because it will not work, but because the advantages of Kanban will not come to full use, as all the work items are already assigned to a team ~~members~~. On the outher hand, if you want to make your team more robust, you can use Kanban as a learning tool, where the work item gets one inexperienced owner, and one experienced supporter.		#'''Expertise''': If the team consist of highly diverse personnel with no overlapping knowledge fields, Kanban may not be the ideal tool. This is not because it will not work, but because the advantages of Kanban will not come to full use, as all the work items are already assigned to a team member. On the outher hand, if you want to make your team more robust, you can use Kanban as a learning tool, where the work item gets one inexperienced owner, and one experienced supporter.
	#'''Learning''': The Kanban system is always focusing on ~~‘’right now’’~~ - never the past. This limits the learning, especially double loop, and future risk management. To enable double-loop learning when using Kanban it has to be supplemented with another tool or system~~, this~~ is in opposition to Scrum which has learning and after action review embedded in its structure. However some "Kanban enthusiasts" argue that the visibility in the Kanban system give the team members instant feedback on what is going wrong, thus the "looking back" part is not necessary to learn from the projects <ref name= Brechner2015/>.		#'''Learning''': The Kanban system is always focusing on "right now" - never the past. This limits the learning, especially double loop, and future risk management. To enable double-loop learning when using Kanban it has to be supplemented with another tool or system. This is in opposition to Scrum which has learning and after action review embedded in its structure. However some "Kanban enthusiasts" argue that the visibility in the Kanban system give the team members instant feedback on what is going wrong, thus the "looking back" part is not necessary to learn from the projects <ref name= Brechner2015/>.
	#'''Dependencies''': The dependencies is not directly visualized in the Kanban system. The system is therefore most suitable to project with a relatively small amount of dependencies.		#'''Dependencies''': The dependencies is not directly visualized in the Kanban system. The system is therefore most suitable to project with a relatively small amount of dependencies.
	#'''Focus on End-Date''': With the Kanban system it is easy to visualize the time it will take for your team to finish the work on the board. Nonetheless it is difficult to estimate end dates if your project is large and the work items exceeds the work items visualized on the board. Nor is there an option for marking a fixed deadline or end date set by the customer or another stakeholder. This does not necessarily have to be a problem, but it is something that requires extra attention when using Kanban, and in large projects a supplementing ‘’planning’’ tool should be utilized.		#'''Focus on End-Date''': With the Kanban system it is easy to visualize the time it will take for your team to finish the work on the board. Nonetheless it is difficult to estimate end dates if your project is large and the work items exceeds the work items visualized on the board. Nor is there an option for marking a fixed deadline or end date set by the customer or another stakeholder. This does not necessarily have to be a problem, but it is something that requires extra attention when using Kanban, and in large projects a supplementing ‘’planning’’ tool should be utilized.

MAVO: /* Benefits */

2016-09-22T07:39:17Z

Benefits

← Older revision		Revision as of 07:39, 22 September 2016
Line 150:		Line 150:
	#'''Uncover critical bottleneck''': By limiting the WIP at each step in the process Kanban prevents overproduction and reveals bottlenecks dynamically so that you can address them before they get “out of hand”.[http://kanbanblog.com/explained/]		#'''Uncover critical bottleneck''': By limiting the WIP at each step in the process Kanban prevents overproduction and reveals bottlenecks dynamically so that you can address them before they get “out of hand”.[http://kanbanblog.com/explained/]
	#'''Improve day-to-day openness in the project''': Each team is different, and it is therefore a huge advantage that the Kanban system can be adapted to fit various team cultures. No matter how the system is set up, or how the board is designed, the outcome is always the same as long as everything is tracked and followed accordingly. As each member contributes to the the Kanban system it often emerges a sense of comradery around it, day-to-day conversations and openness. All concludes to a improved team mentality.<ref name=Brechner2015> Brechner. Eric (2015).<i> Agile Project Management with Kanban (Developer Best Practices) </i>. 2016 49th Hawaii International Conference on System Sciences </ref>		#'''Improve day-to-day openness in the project''': Each team is different, and it is therefore a huge advantage that the Kanban system can be adapted to fit various team cultures. No matter how the system is set up, or how the board is designed, the outcome is always the same as long as everything is tracked and followed accordingly. As each member contributes to the the Kanban system it often emerges a sense of comradery around it, day-to-day conversations and openness. All concludes to a improved team mentality.<ref name=Brechner2015> Brechner. Eric (2015).<i> Agile Project Management with Kanban (Developer Best Practices) </i>. 2016 49th Hawaii International Conference on System Sciences </ref>
	#'''Lean and agile at the same time''': By not allocating resources before they are starting work on the task, and by only working on one task at a time so that there is a continuous output, the project can be highly agile. This means that it is easy to change to fit customers continually changing demand. In order to be lean the project have to reduce waste. By using Kanban the waste is reduced by eliminating waiting time, reducing waste of resources, simplifying planning process and identifying problems continuously while the project is running.		#'''Lean and agile at the same time''': By not allocating resources before they are starting to work on the task, and by only working on one task at a time so that there is a continuous output, the project can be highly agile. This means that it is easy to change to fit customers continually changing demand. In order to be lean the project have to reduce waste. By using Kanban the waste is reduced by eliminating waiting time, reducing waste of resources, simplifying planning process and identifying problems continuously while the project is running.

	==Limitations==		==Limitations==

MAVO: /* Developing from Scrum to Kanban */

2016-09-22T07:38:30Z

Developing from Scrum to Kanban

← Older revision		Revision as of 07:38, 22 September 2016
Line 143:		Line 143:

	===Developing from Scrum to Kanban===		===Developing from Scrum to Kanban===
	Implementing Kanban should not be experienced as a revolutionary change for participants of the team. Especially if the team is already working with Scrum, as they already have a board with work items moving through, a definition of "done", daily stand ups etc. The team do not have to rely fully on the new Kanban system from the start, as it can at first be a supplement to the existing project management system. ~~Idealy~~ there should be one or more experienced Kanban user(s) in the team, to prevent insecurities that may cause the team to stop using Kanban and fall back to the old management system. <ref name=Ahmad2014/>. If the team is moving from Scrum to Kanban it is recommended to keep the Scrum master and meetings at first. In time you introduce the new aspects (see table ‘’Differences between Kanban and Scrum’’) of the Kanban system step-by-step <ref name= Brechner2015/>.		Implementing Kanban should not be experienced as a revolutionary change for participants of the team. Especially if the team is already working with Scrum, as they already have a board with work items moving through, a definition of "done", daily stand ups etc. The team do not have to rely fully on the new Kanban system from the start, as it can at first be a supplement to the existing project management system. Ideally there should be one or more experienced Kanban user(s) in the team, to prevent insecurities that may cause the team to stop using Kanban and fall back to the old management system. <ref name=Ahmad2014/>. If the team is moving from Scrum to Kanban it is recommended to keep the Scrum master and meetings at first. In time you introduce the new aspects (see table ‘’Differences between Kanban and Scrum’’) of the Kanban system step-by-step <ref name= Brechner2015/>.

	==Benefits==		==Benefits==

MAVO: /* Kanban vs. Scrum */

2016-09-22T07:38:03Z

Kanban vs. Scrum

← Older revision		Revision as of 07:38, 22 September 2016
Line 98:		Line 98:
	The most prominent difference between the ''stand up meetings'' within the two methods is that in the Scrum meetings every team member states what they did and what you are doing next, but in the Kanban meetings only the issues of today are discussed. Thus the Kanban meetings are severely shorter and less informative, a team member who wants to obtain similar information to what is given in a Scrum meeting can do so from the information on the Kanban board. Because of this difference between the two systems, the Kanban can be used for much larger teams than the Scrum. In Microsoft a Kanban board have been used for teams up to 75 people, the stand-ups then took around 15 minutes, which would not have been feasible for the Scrum <ref name= Brechner2015/>.		The most prominent difference between the ''stand up meetings'' within the two methods is that in the Scrum meetings every team member states what they did and what you are doing next, but in the Kanban meetings only the issues of today are discussed. Thus the Kanban meetings are severely shorter and less informative, a team member who wants to obtain similar information to what is given in a Scrum meeting can do so from the information on the Kanban board. Because of this difference between the two systems, the Kanban can be used for much larger teams than the Scrum. In Microsoft a Kanban board have been used for teams up to 75 people, the stand-ups then took around 15 minutes, which would not have been feasible for the Scrum <ref name= Brechner2015/>.

	Opposite to Kanban, the Scrum method does not visualize continuous flow and delivery, and it is not possible to make managerial changes ~~during a ‘’sprint’’~~. The work items are also released in batches so that there is a WIP-limit for the system, but not for each piece of the system (as in Kanban). The Scrum method also requires the team to define a “Scrum master” and in Kanban there is no predefined roles. To get an overview of the previous mentioned differences, see table below.<ref name=Ahmad2014/><ref name=Ahmad2016/>		Opposite to Kanban, the Scrum method does not visualize continuous flow and delivery, and it is not possible to make managerial changes continuously. These changes can only happen in pre-defined time slots between the ‘’sprints’’. The work items are also released in batches so that there is a WIP-limit for the system, but not for each piece of the system (as in Kanban). The Scrum method also requires the team to define a “Scrum master” and in Kanban there is no predefined roles. To get an overview of the previous mentioned differences, see table below.<ref name=Ahmad2014/><ref name=Ahmad2016/>

MAVO: /* Kanban vs. Scrum */

2016-09-22T07:35:29Z

Kanban vs. Scrum

← Older revision		Revision as of 07:35, 22 September 2016
Line 96:		Line 96:
	Both the Kanban and the Scrum method focus on quick response to changing customer requirements, and full utilisation of resources. The methods can therefore be described as both agile and lean <ref name=Ahmad2016/>. Both methods are also highly adaptive and are based on self-managing teams with a high level of cooperation. The methods depends on a visual representation of future and ongoing work and includes short ''stand up meetings'' with the project teams.		Both the Kanban and the Scrum method focus on quick response to changing customer requirements, and full utilisation of resources. The methods can therefore be described as both agile and lean <ref name=Ahmad2016/>. Both methods are also highly adaptive and are based on self-managing teams with a high level of cooperation. The methods depends on a visual representation of future and ongoing work and includes short ''stand up meetings'' with the project teams.

	The most prominent difference between the ''stand up meetings'' is that in the Scrum meetings every team member states what they did and what you are doing next, but in the Kanban meetings only the issues of today are discussed. Thus the Kanban meetings are severely shorter and less informative, a team member who wants to obtain similar information to what is given in a Scrum meeting can do so from the information on the Kanban board. Because of this difference between the two systems, the Kanban can be used for much larger teams than the Scrum. In Microsoft a Kanban board have been used for teams up to 75 people, the stand-ups then took around 15 minutes, which would not have been feasible for the Scrum <ref name= Brechner2015/>.		The most prominent difference between the ''stand up meetings'' within the two methods is that in the Scrum meetings every team member states what they did and what you are doing next, but in the Kanban meetings only the issues of today are discussed. Thus the Kanban meetings are severely shorter and less informative, a team member who wants to obtain similar information to what is given in a Scrum meeting can do so from the information on the Kanban board. Because of this difference between the two systems, the Kanban can be used for much larger teams than the Scrum. In Microsoft a Kanban board have been used for teams up to 75 people, the stand-ups then took around 15 minutes, which would not have been feasible for the Scrum <ref name= Brechner2015/>.

	Opposite to Kanban, the Scrum method does not visualize continuous flow and delivery, and it is not possible to make managerial changes during a ‘’sprint’’. The work items are also released in batches so that there is a WIP-limit for the system, but not for each piece of the system (as in Kanban). The Scrum method also requires the team to define a “Scrum master” and in Kanban there is no predefined roles. To get an overview of the previous mentioned differences, see table below.<ref name=Ahmad2014/><ref name=Ahmad2016/>		Opposite to Kanban, the Scrum method does not visualize continuous flow and delivery, and it is not possible to make managerial changes during a ‘’sprint’’. The work items are also released in batches so that there is a WIP-limit for the system, but not for each piece of the system (as in Kanban). The Scrum method also requires the team to define a “Scrum master” and in Kanban there is no predefined roles. To get an overview of the previous mentioned differences, see table below.<ref name=Ahmad2014/><ref name=Ahmad2016/>

MAVO: /* When to use Kanban */

2016-09-21T15:55:58Z

When to use Kanban

← Older revision		Revision as of 15:55, 21 September 2016
Line 75:		Line 75:

	==When to use Kanban==		==When to use Kanban==
	As ~~kanban~~ is a relatively new way of managing projects, research on its effects are limited. The author was not able to find any valid research on Kanban in project management outside the field where it originated, software development and maintenance teams. The reason for this can be both that Kanban project management is only beneficial in software teams and will never be used in other fields, or that the development of this project management tool is still ongoing and the research and data on this will be undertaken in time.		As Kanban is a relatively new way of managing projects, research on its effects are limited. The author was not able to find any valid research on Kanban in project management outside the field where it originated, software development and maintenance teams. The reason for this can be both that Kanban project management is only beneficial in software teams and will never be used in other fields, or that the development of this project management tool is still ongoing and the research and data on this will be undertaken in time.

	In order to write on the basis of solid research this next part of the report, focusing on implementation and effects, take the basis of Kanban in ~~Software~~ teams.		In order to write on the basis of solid research, this next part of the report, focusing on implementation and effects, take the basis of Kanban in software teams.

	===Kanban in Software Teams===		===Kanban in Software Teams===
	{{#ev:youtube\|video https://www.youtube.com/watch?v=CKWvmiY7f_g\|500\|right\|''Video 1. Agile Project Management with Kanban in Microsoft: Eric Brechner Presentation''<ref>Agile Project Management with Kanban: Eric Brechner Presentation (2015, 18 jun.). ''Kanban in Microsoft'' [https://www.youtube.com/watch?v=CKWvmiY7f_g]</ref>\|frame}}		{{#ev:youtube\|video https://www.youtube.com/watch?v=CKWvmiY7f_g\|500\|right\|''Video 1. Agile Project Management with Kanban in Microsoft: Eric Brechner Presentation''<ref>Agile Project Management with Kanban: Eric Brechner Presentation (2015, 18 jun.). ''Kanban in Microsoft'' [https://www.youtube.com/watch?v=CKWvmiY7f_g]</ref>\|frame}}

	The proclaimed benefits presented in the literature and a strong support from practitioners is important factors to the growing interest of Kanban in software development. <ref name=Hiranabe2014> K. Hiranabe (2008).<i> Kanban applied to software development.</i> InfoQ. (2008) [https://www.infoq.com/articles/hiranabe-lean-agile-kanban]</ref>		The proclaimed benefits presented in the literature and a strong support from practitioners is important factors to the growing interest for Kanban in software development. <ref name=Hiranabe2014> K. Hiranabe (2008).<i> Kanban applied to software development.</i> InfoQ. (2008) [https://www.infoq.com/articles/hiranabe-lean-agile-kanban]</ref>
	<ref name=Shalloway2009> Shalloway, B.Guy, and R. James Trott (2009).<i>Lean-agile Software Development:Achieving Enterprise Agility.</i> Pearson Education, 2009 </ref>		<ref name=Shalloway2009> Shalloway, B.Guy, and R. James Trott (2009).<i>Lean-agile Software Development:Achieving Enterprise Agility.</i> Pearson Education, 2009 </ref>

	Kanban in software developments originated within the Microsoft organisation in 2004, when David J. Anderson was assisting an IT-development team that was performing poorly. Anderson implemented Kanban so that team members could visualize their work and limit the WIP.		Kanban in software developments originated within the Microsoft organisation in 2004, when David J. Anderson was assisting an IT-development team that was performing poorly. Anderson implemented Kanban so that team members could visualize their work and limit the WIP.

	By implementing Kanban the team was able to identify bottlenecks and the throughput of finished tasks increased. This enabled a ''pull approach'', the team members could now pull new work items (cards) when they had finished a task. ~~Which~~ is in opposition to the traditional software development practices based on puch approaches. The work is pushed through and it is set a finish date, the team members then have to work fast enough to meet the set deadline. To get a introduction on how Microsoft successfully use the Kanban management approach, watch video 1 ''Agile Project Management with Kanban in Microsoft: Eric Brechner Presentation''.		By implementing Kanban the team was able to identify bottlenecks and the throughput of finished tasks increased. This enabled a ''pull approach'', the team members could now pull new work items (cards) when they had finished a task. This is in opposition to the traditional software development practices based on puch approaches. The work is pushed through and it is set a finish date, the team members then have to work fast enough to meet the set deadline. To get a introduction on how Microsoft successfully use the Kanban management approach, watch video 1 ''Agile Project Management with Kanban in Microsoft: Eric Brechner Presentation''.

	A pull approach can be extra beneficial for software teams because of the fast changing customer demand (customer change their mind) and the often incorrect time and cost estimation.		A pull approach can be extra beneficial for software teams because of the fast changing customer demand (customer change their mind) and the often incorrect time and cost estimation.

MAVO: /* Kanban Step-By-Step */

2016-09-21T15:52:25Z

Kanban Step-By-Step

MAVO: /* Kanban in Project Management */

2016-09-21T15:37:55Z

Kanban in Project Management

← Older revision		Revision as of 15:37, 21 September 2016
Line 18:		Line 18:
	==Kanban in Project Management==		==Kanban in Project Management==
	[[File:Project_management.png\|150px\|thumb\|right\|'''Figure 1:''' [https://flic.kr/p/arFTXS Five Stages of Project Management]]]		[[File:Project_management.png\|150px\|thumb\|right\|'''Figure 1:''' [https://flic.kr/p/arFTXS Five Stages of Project Management]]]
	The goal of project management is to improve the total quality of project results. This ~~include~~ on time delivery, stakeholder satisfaction and financial results. In ~~otder~~ to do so one have to ~~poperly~~ execute the five processes of project management, see figure 1		The goal of project management is to improve the total quality of project results. This includes on-time delivery, stakeholder satisfaction and financial results. In order to do so one have to properly execute the five processes of project management, see figure 1
	<ref name=PMIVOPM> Project Management Institute. (2010). The Value of Project Management. [http://www.pmi.org/-/media/pmi/documents/public/pdf/white-papers/value-of-project-management.pdf Available Online Version]</ref>.		<ref name=PMIVOPM> Project Management Institute. (2010). The Value of Project Management. [http://www.pmi.org/-/media/pmi/documents/public/pdf/white-papers/value-of-project-management.pdf Available Online Version]</ref>.

	The Kanban project management tool can help in regards of the '''planning''', '''executing''' and '''monitoring and controlling''' ~~aspect~~ of project management by solving the questions stated below.		The Kanban project management tool can help in regards of the '''planning''', '''executing''' and '''monitoring and controlling''' aspects of project management by solving the questions stated below.
	#How can workflow be visualized in real time?		#How can workflow be visualized in real time?
	#How can team members and stakeholders get a sense of understanding of the whole project?		#How can team members and stakeholders get a sense of understanding of the whole project?

← Older revision		Revision as of 15:52, 21 September 2016
Line 32:		Line 32:
	==Kanban Step-By-Step==		==Kanban Step-By-Step==
	The basis of the Kanban project management system is to have a board with cards attached. The cards represent the different ''work items'' in the project, and move from left to right on the board. Different parts of the board represent different ''stages'' of the development which all work items go through.The board and the cards can be arranged and divided however the user would like. Nonetheless the main concept of Kanban is always the same, and can be summarized by these six points[https://www.atlassian.com/agile/kanban]:		The basis of the Kanban project management system is to have a board with cards attached. The cards represent the different ''work items'' in the project, and move from left to right on the board. Different parts of the board represent different ''stages'' of the development which all work items go through.The board and the cards can be arranged and divided however the user would like. Nonetheless the main concept of Kanban is always the same, and can be summarized by these six points[https://www.atlassian.com/agile/kanban]:
	#'''Limit WIP''' (work in process): The board is divided in parts, the number of work items in each part can not exceed the pre defined limit of work items, the WIP limit. This limit can be different for every part of the board. This is true for all parts except the “backlog” and “done” part, which is always unlimited		#'''Limit WIP''' (work in process): The board is divided in parts, and the number of work items in each part can not exceed the pre-defined limit of work items, the WIP limit. This limit can be different for every part of the board. This is true for all parts except the “backlog” and “done” part, which is always unlimited
	#'''Cards''' : Each work item is represented by a card (sticky note or similar)		#'''Cards''' : Each work item is represented by a card (sticky note or similar)
	#'''Flow''': The work items on the board are moved from left to right between the different parts. The person performing the work, is also the one moving the card		#'''Flow''': The work items on the board are moved from left to right between the different parts. The person performing the work, is also the one moving the card
Line 38:		Line 38:
	#'''Kaizen''' (constant improvement)		#'''Kaizen''' (constant improvement)
	#:* The team get together on a regular basis to analyze the flow, focusing on work items that are stuck on the board		#:* The team get together on a regular basis to analyze the flow, focusing on work items that are stuck on the board
	#:*There is no Kanban police - and if you need to alter the board or break the rules that~~'s ok~~, but inform the rest of your team		#:*There is no Kanban police - and if you need to alter the board or break the rules that is okay, but inform the rest of your team

	To visualize the work of your team with Kanban project management all you need is a board and cards of some kind. This can be either physically, a board and sticky-notes, or virtually, using an online platform. There are numerous variations of ~~booth~~ of this (which a quick google search can show you). After choosing a type of Kanban system it is time to set up the board and make rules for the cards. There is no limitation to the different variations of boards division and card rules, the example in this article is just one way of doing this.		To visualize the work of your team with Kanban project management all you need is a board and cards of some kind. This can be either physically, a board and sticky-notes, or virtually, using an online platform. There are numerous variations of both of this (which a quick google search can show you). After choosing a type of Kanban system it is time to set up the board and make rules for the cards. There is no limitation to the different variations of boards division and card rules, the example in this article is just one way of doing this.

	There are several ways to mark the priority of the work items, one can for example organize them in line, where the top one is the most urgent, see figure 2. This priority of work items are most often carried out in <span class="plainlinks">[https://en.wikipedia.org/wiki/Stand-up_meeting '''stand-up meetings''']</span>. These meetings take place in predefined time slots, ~~last~~ 5-30 minutes, and address all "issues of the day".		There are several ways to mark the priority of the work items, one can for example organize them in line, where the top one is the most urgent, see figure 2. This priority of work items are most often carried out in <span class="plainlinks">[https://en.wikipedia.org/wiki/Stand-up_meeting '''stand-up meetings''']</span>. These meetings take place in predefined time slots, lasts 5-30 minutes, and address all "issues of the day".

	===The Board===		===The Board===
Line 48:		Line 48:
	[[File:Kanban_board.png\|center\|thumb\|850px\|\|'''Figure 2:''' Example of Kanban Board]]		[[File:Kanban_board.png\|center\|thumb\|850px\|\|'''Figure 2:''' Example of Kanban Board]]

	The Kanban boards for project management most often consists of three main parts '''To Do''', '''Doing''' and '''Done'''. Each of these is divided in sub sections. There are many advantages to do it in this way, the main one being the visualization of when work items are ready to go to the next main part of the board. Each section also have a '''<span class="plainlinks">[https://en.wikipedia.org/wiki/Work_in_process'''WIP''']</span>-limit'''~~, this is the maximum number of work items that can be at that part of the board. These will of course be different for the different parts as the workload varies~~. The parts with a higher workload should have a higher WIP. In order for this to not limit the flow, and become a bottleneck, the number of employees assigned to the different parts of the board should be according to the maximum WIP level.		The Kanban boards for project management most often consists of three main parts '''To Do''', '''Doing''' and '''Done'''. Each of these is divided in sub-sections. There are many advantages to do it in this way, the main one being the visualization of when work items are ready to go to the next main part of the board. Each section also have a defined '''<span class="plainlinks">[https://en.wikipedia.org/wiki/Work_in_process'''WIP''']</span>-limit'''. The parts with a higher workload should have a higher WIP-limit. In order for this to not limit the flow, and become a bottleneck, the number of employees assigned to the different parts of the board should be according to the maximum WIP level.

	====To Do====		====To Do====
	'''Backlog''': In this section cards with work items which is to be performed in the future, but have not started on yet, is placed. This part of the board have no ~~rules of an upper~~ limit. The number of cards ~~here~~ is most often limited by ~~your~~ lack of knowledge of the future, as ~~you don't~~ know of all your future work yet. To indicate which of the work items that is most urgent in the backlog they are sorted by urgency on the board. This can be done in the stand-up meetings.		'''Backlog''': In this section cards with work items which is to be performed in the future, but have not started on yet, is placed. This part of the board have no WIP-limit. The number of cards in this section is most often limited by one's lack of knowledge of the future, as one do not know of all your future work yet. To indicate which of the work items that is most urgent in the backlog they are sorted by urgency on the board. This can be done in the stand-up meetings.

	'''Breakdown''': The Breakdown part is managed by a rule limiting the work item ~~size~~. An example of this can be that all work items must be limited to take approximately two working days. If the work item initially is longer/larger than this, it is divided into several smaller work items before moving on to this part of your board. The work items are broken down like this to enhance the flow of work items in the project. If a work item is too big it is both a higher chance it will get stuck at one part of the board, and more difficult to diagnose why the work item is stuck. When a work item is placed in the breakdown part of the board, it is ready for the next main part ''Doing''.		'''Breakdown''': The Breakdown part is managed by a rule limiting the size of the work item. An example of this can be that all work items must be limited to take approximately two working days. If the work item initially is longer/larger than this, it is divided into several smaller work items before moving on to this part of your board. The work items are broken down like this to enhance the flow of work items in the project. If a work item is too big it is both a higher chance it will get stuck at one part of the board, and more difficult to diagnose why the work item is stuck. When a work item is placed in the breakdown part of the board, it is ready for the next main part ''Doing''.

	===Doing===		===Doing===
	All work items that are undergoing some kind of work is located in this part. This part of the board is almost always divided into several smaller parts as it is where the most complex and challenging activities take place. An example of this can be '''Plan''', '''Develop''' and '''Test'''. In each of the subsections of this part of the Kanban board, it should be a limitation of work items. This is to limit the WIP, and secure a agile project work. In some cases a work item is stuck in a section of the ''doing'' part due to interdependencies of outer work items or people, and there is no current work to be done on the work item. In this case you can mark the activity as ''stuck'' and the work item does not count as your WIP.		All work items that are undergoing some kind of work is located in this part. This part of the board is almost always divided into several smaller parts as it is where the most complex and challenging activities take place. An example of this can be '''Plan''', '''Develop''' and '''Test'''. In each of the subsections of this part of the Kanban board, it should be a limitation of work items. This is to limit the WIP, and secure agile project work. In some cases a work item is stuck in a section of the ''doing'' part due to interdependencies of outer work items or people, and there is no current work to be done on the work item. In this case you can mark the activity as ''stuck'', and the work item does not count as your WIP.

	'''Plan''': In this section the work is planned~~, this~~ includes both allocation of resources and finding possible ways to perform the work.		'''Plan''': In this section the work is planned. This includes both allocation of resources and finding possible ways to perform the work.

	'''Develop''': In this section the work item is developed from an idea to a product. This section is often divided in two subsections, '''In Process''' and '''Done'''. The reason for having a '''Done''' part, is to ~~visulize~~ when the work items is ready to be transferred to the next stage, testing.		'''Develop''': In this section the work item is developed from an idea to a product. This section is often divided in two subsections, '''In Process''' and '''Done'''. The reason for having a ''Done'' part, is to visualize when the work items is ready to be transferred to the next stage, testing.

	'''Testing''': After the development, the work item/product is tested or checked, before being marked as finished. This is often done by a different person than the developer. This stage often have some rules set by the team to secure the quality of the end product. When this stage is completed the work item moves to the last and final part, for this Kanban board, '''Done'''.		'''Testing''': After the development, the work item/product is tested or checked, before being marked as finished. This is often done by a different person than the developer. This stage often have some rules set by the team to secure the quality of the end product. When this stage is completed the work item moves to the last and final part, for this Kanban board, '''Done'''.
Line 70:		Line 70:
	[[File:Kanban_card.png\|400px\|thumb\|right\|'''Figure 3:''' [https://flic.kr/p/arFTXS Example of kanban card]]]		[[File:Kanban_card.png\|400px\|thumb\|right\|'''Figure 3:''' [https://flic.kr/p/arFTXS Example of kanban card]]]

	The cards ~~include~~ critical information about the particular work item. This includes a short description of the job, the time estimate, and so on. In the virtual Kanban cards it is possible to add more information, as pictures, technically detailed information and other documents that may be valuable.		The cards includes critical information about the particular work item. This includes a short description of the job, the time estimate, and so on. In the virtual Kanban cards it is possible to add more information, as pictures, technically detailed information and other documents that may be valuable.

	Kanban cards can have three stages ''pending'', ''undergoing work'' or ''finished''. When a team member is finished with his or her work they go to the board and mark their work item as finished. If there is room for the item in the next part of the board, it is moved there and the status is now ''pending''. Now the team member can choose a new work item matching their capability and with the highest priority on the board~~, this~~ should now be marked as ''undergoing ~~wok~~''.		Kanban cards can have three stages ''pending'', ''undergoing work'' or ''finished''. When a team member is finished with his or her work, they go to the board and mark their work item as finished. If there is room for the item in the next part of the board, it is moved there and the status is now ''pending''. Now the team member can choose a new work item matching their capability, and with the highest priority on the board. This should now be marked as ''undergoing work''.

	==When to use Kanban==		==When to use Kanban==