Leanpub: Publish Early, Publish Often

Section:19 s145 - §19 Kanban Method – 8s

§19 s145 Hdr Kanban Method 0/8

Kanban is a bigger section than most 8 slides and 5,600 words of narration
- As well as time-boxing we can use flow based team capacity management.
- We can combine the two. The study of workflows is at least as old as the Gilbreth’s consultancy that flourished in the 1900s. In the 1940s at Toyota Taiichi Ohno defined a whole lot more than just work-flow tools to form TPS.
- TPS is often called lean manufacturing. At least Lean is the word made popular by James Womack’s 1990 book that described what he found at Toyota. Lean seeks to eliminate waste from processes by many techniques. More than that TPS is a philosophy of company wide focus on process improvement through values and culture as well as techniques
- Further Mike Rother in his 2009 book Toyota kata tells us real success depends on understanding the invisible force behind TPS which is the kata or perfect pattern for embedding improvement thinking in the workforce and coaching thinking in the management.
- By sticking to P2a we will be mostly omitting the softer and arguably more important side for the more immediately accessible elements.
- One of lean’s techniques is Just in Time working. The just in time approach to processes reduces a business’ capital requirements as represented by money sat idle in incomplete inventory . We minimise unsalable work in progress.
- Just in time production uses an approach where a task’s start is signalled by a latter step being about to need its outputs as an input. Imagine I’m the washer-upper in a restaurant There is a pile of dirty plates next to the sink and a card with an arrow stuck on the wall that says “Shout for someone to get more plates”. It is 6 plates from the bottom of the pile. That’s my Kanban signal card. It calibrates how many plates I can wash with how long it takes waiting staff to go and gather more dirty plates and return them to the kitchen so I don’t become idle waiting for input
- When steps are written out as a work flow in European languages they run left to right and are traditionally scheduled in that order. Pull systems are often described as right to left. This right to left control of flow through process steps, described as pull is often represented on a wall board divided into work-flow steps.
In 2010 David Anderson wrote a book about his attempts to use Goldratt’s Theory of Constraints also called TOC and Drum Buffer Rope flow techniques to improve software development in his agile team at Motorola.
- Andersons book is called “Kanban – Successful Evolutionary Change for your Technology Business” It has influenced many including P2a’s author. Given its full title and contents and the narrow breadth of our use we are only taking a little inspiration from it. Also Andersons thinking has moved on so while P2a tells us of the 4 types of review that help maintain project momentum Anderson now talks of 7 cadences or rhythms that drive enterprise momentum.
- The P2a manual doesn’t mention ToC or Drum Buffer Rope (Also know by its initials DBR) and just touches on Anderson’s or perhaps I should say Taiichi Ohno’s “Continuous Improvement Culture”.
- They are off our path to the axelos P2a practitioner qualification so I won’t add them here and now. They are useful further research avenues for you post exam via Anderson’s book, Wikipedia or our non-exam courses.

Returning to the path

Kanban Method is a work flow method that adapts lean manufacturing where process steps are repetitive and of predictable and fixed cycle times to project contexts where each work step has unique characteristics and varying durations.
In Kanban Method when there is capacity in the last step of a process flow this triggers the last but one step to pass-on work and so triggers the last but 2 to pass on work and successively triggers the first step to start a new piece of work. This is as lean manufacturing. Kanban method adds a number of non-production line ideas such as classes of service, for example to expedite something arising with urgent need. Classes allow different pull speeds depending on the cost of delay and risk from the work. Classes refine WIP limits
Kanban method’s approach to flow still uses the concept that the work we start depends on down-stream capacity to handle it not front end capacity to start it.
A simple way to implement this form of control is illustrated on the slide. First list the process steps, their maximum capacity and all the outstanding work by current process step on the team’s Information Radiator-IR.
P2a tells us that in Japanese a big visible sign board or a signal card is a Kanban and in Chinese Kanban means looking at the board. Between them is explanation of the name.
- Big messages here may need you to finish this chapter to cut through the jargon in which case be attuned to what concepts matter
- Kanban is most applicable from after {{Starting up a Project}} and the Initiation Stage have got things going through development and afterwards during product support
- Limiting wip improves the rate of throughput
- Kanban method has 6 core practices; 1) Visualise, 2) Limit WIP, 3) Manage flow, 4) Make policies explicit, 5) Use feedback, and 6th) Experiment and Improve
The last three big messages are:
- Analyse and forecast with a CFD Cumulative Flow Diagram
- Break work down to small chunks that deliver value
- Where work really is of a different nature then it should perhaps be managed via a different class
End

Slide and base diagrams Copyright ©AXELOS Limited 2015 Reproduced under licence from AXELOS Limited. All rights reserved. From PRINCE2 Agile® section as detailed on slide image. Explanatory text and additional items ©Logicalmodel Ltd 2016

§19 s146 = Kanban and the Kanban Method 1/8

§19 s146 Kanban & kb Method 1/8

Learning Outcome 1, Assessment Criteria 1.1 and 1.3
Anderson’s Kanban Method is an alternative to scrum as a way to control the work carried out by the development team.
- In fact it is compatible with scrum as evidenced by what is called scrumban.
- <Sync. 1 Visual> Most obviously the kanban board is a visual system of control . Somewhere where we need to spend a little time to try-out the mechanics. Our next slide in just a moment.
Kanban as in Ohno’s TPS rests on several principles.
- <Sync. 2 agility> The First) is Start with what you do now. Day by day we evolve better practices by CPI or Kaizen. Some quotable results are decisions are made later when more information is available and so we hope they are better decisions, lead times decrease, feedback increases, transparency or everyone’s awareness increases
- <Sync. 3 Hi-inMp> The flow method is most suited when there is a regular pattern of work to be done, for example when we have a backlog defined.

End

§19 s147 = The 6 general practices of the Kanban Method 2/8

§19 s147 Visualise. The 1st of the 6 general practices 2/8

Learning Outcome 1, Assessment Criteria 1.1 and 1.3
Anderson’s Kanban Method stands on 6 core practices.
- Number one is visualise. Here is a Kanban board.
- <Sync. Card> the columns are process steps and the coloured items are moveable cards that makes the work and its position in the flow from Ready to Deployed clear
- <Sync. BigCard> Each card explains a backlog item, its priority, effort & skill needs,& Its acceptance authority. A card’s position on the board shows its current status. In prince terms the card is the Configuration Item Record-A5. prince requires we update the CIR as we go. The whole board of cards is a permanent and dynamic display of A5’s status updates that are reported in an Product Status Account-A18. Now an a18 is a simple glance at the board.
- The board is updated in real-time as team members start and finish activities, discover impediments etc
<Sync. Lanes>Kanban method uses Class of Service. 4 are common, between 3 and 6 generally suggested;
- 1st is) Standard service. when you can deliver promises via standard service the pressure from the organisation to label everything urgent will decrease. Then truly urgent things can really be expedited. Standard items are normally scheduled through the system as first in first out or fifo – a pipeline architecture. They may or maynot be estimated for duration instead the lead time reported from the cfd may be our duration estimated more in a couple lesson’s time
- 2nd class) are Fixed date deliveries. these are pulled into the workflow based on conservative estimates of duration. Mean estimated duration plus three standards deviations is at least one suggestion,
- 3rd) The Expedite class is for urgent items that arise unexpectedly. Often expedite is limited to a single item at any one time across the whole flow and may exceed other wip limits or interrupt previous work items. An estimate of duration may be created to give visibility of expected delivery
- 4th) is the Intangible class. Intangible refers to its value. It is necessary work that represents effort whose value to the customer is indirect. It includes work such as correcting errors, housekeeping tidy-ups and redesigns.
Across the board all the items are usefully decomposed to give detail, for example for estimating with higher precision. There may be more classes that the classes above in your specific context. Decide on the classes required based on value and risk
- When bringing a backlog item to the definition of ready ensure ready includes assignment of the required service level

End

§19 s148 = The 6 general practices of the Kanban Method 3/8

§19 s148 Limit WIP. 2nd of 6 general practices 3/8

Learning Outcome 1, Assessment Criteria 1.1 and 1.3
Core practice 2 is to avoid Muri or overburden by limiting wip to the capacity of the step
- <Sync. 1 wip> Goldratt’s critical chain in the ToC is so named because he identified that the throughput of a process was limited by any bottleneck steps. Lean’s principle of Muri or avoiding overloads is achieved by feeding into the process at a rate dictated by down-stream work exiting the process.
- <Sync. 2 pull> The pull approach where we start step 1 because step 2 has capacity or more that when the last has capacity the one before can start and so on back to the beginning. It means we don’t schedule tasks in advance but operate reactively. Another of Goldratts observations was that placing milestones and dates in a project destroys the benefits of early achievement in prior steps. Later steps either start when scheduled or late but rarely early. A pull system starts work as soon as capacity is available. Lead times decrease often dramatically
- <Sync. 3 Switch> Goldratt particularly noted the impact of multi tasking and task switching. Imagine you have just assigned me three four day tasks and I focus entirely on one then moving to the next and so on. The customer gets my first result after 4 days, then next after 8 days and the last after 12 days – a nice smooth flow. If I focus equally by switch every day between tasks then task one finishes on day 10, task 2 on day 11 and task 3 on day 12. Not only has the customer waited longer but then everything arrives in a flurry of activity that may be hard to absorb

WIP Limits

The kanban board notes step capacity in its column heading. It shows how many work items can be in the column at once

End

§19 s149 = The 6 general practices of the Kanban Method 4/8

§19 s149 3rd & 4th of 6 4/8

Learning Outcome 1, Assessment Criteria 1.1 and 1.3
<Sync. Flow> Core principles 3 and 6 are Manage the flow and improve collaboratively. Recall Ohno’s 1st principle is start with what you have and improve from there.
- As well as seeking to avoid bottlenecks or overburden or Muri we also seek to make the flow even. Even flow is achieved by the team understanding the process and spotting adaptations that evolve a better process. Uneven flow is Mura. Mura causes stops and starts that add overhead or waste or to use the japanese word Muda.
- Oh opps – I’ve been adding to the materials. You don’t need to remember the words Muda, Muri and Mura or Toc and Goldratt for the exam. Just recall that 1) is visualise, 2) is limit work in progress 3) is manage a smooth flow.
Managing the flow must surely also mean analysing it for speed of throughput, predicting end times and much more. In-fact ideas such as queuing theory have muc to say here.
- Like why is it better to have one queue feeding all 10 checkouts in the supermarket than 10 separate queues?
More on that when we have looked at the 6 general practices.
- <Sync. 2 4> 4) is that Chartering and Manage By Exception that we discussed long ago. When we all know the rules of the game to quote the definitive guide to scrum then decision making is aided, scrutiny has a reference point against which to judge and conclude. Rules or constraints make clear freedoms, empowerment and the space within which the team can self-direct its sharing of roles and tasks. The team builds its own norms or adopted policies over time

End

§19 s150 = The 6 general practices of the Kanban Method 5/8

§19 s150 5th & 6th of 6 5/8

Learning Outcome 1, Assessment Criteria 1.1 and 1.3
Anderson’s points 5 and 6 are feedback and improving collaboratively as mentioned with point 3 manage flow by constant improvement
- P2a tells use the best feedback comes from the person paying the bill, but that is product feedback on the project’s result
- <Sync. 1 FdBk> The real customer has the most insight about the value of the outcome. We also need good feedback from the process side. Also, better feedback is quicker feedback and it is objective feedback and quantitatively assessed feedback but it is only useful when it causes action.
- <Sync. 2 Quant > Great feedback ensures that the most valuable backlog items exit the development work flow earlier rather than later.
- We should talk of improvement rather than feedback. Continuous improvement is called kaizen in Japanese. Sometimes we have a specific problem to solve and now we might enlist a specialist to run a kaizen event. This may be a team during a compressed time period during which we focus on improving some issue. A challenge here is the facilitator is well versed in analysis and change but often the affected workforce is not. The activity of improvement is strange and artificial to them not subconscious, practiced and natural. They don’t have a practiced kata.
- In Japanese the word kata refers to an ideal pattern of doing something, often martial arts attacks and blocks but also making tea and everything in between. Toyota kata is the title of mike Rother’s book about Toyota’s culture for teaching the whole organisation two kata; 1) is improvement kata and the second is coaching kata. Coaching of improvers is not in a problem’s solution but in problem resolutions. It is the equivalent in process improvement to “give a man a fish you feed him today, teach him how to catch fish and you feed him for life”. The workforce are the improvers being taught to fish while the managers need to be better at teaching so must pursue the coaching kata.
- Feedback results from discussion or review. P2a’s reflection of Anderson’s take on Kanban defines four review types. 1) The daily stand-up meeting and 2) the perhaps weekly Service Delivery Review, The Stand-up’s benefit is it makes improvement thinking natural and daily for the team’s local kaizen. Helping to socialise and embed the first kata, improvement kata. The DSM and Service delivery reviews are used to check time-box status versus intention and thus adjust policies or team norms. The Service Delivery Review considers the results from daily stand-ups and also links to strategy review at perhaps a quarterly time frame and risk review at perhaps the monthly level
- 3rd) is the Operations Review which runs the improvement kata inter team as opposed to intra team. Not within but between the project’s agile teams. The OpsRvw may be above project level eg at the program level and 4th) the Risk Review is an anytime but perhaps never less than periodic consideration of the pattern of risks that we are experiencing.
- The coaching kata is the perfect pattern for showing improvers how to make improvements to process. There is a 3rd kata; where the coach’s coach challenges the coach to coach better

Experiments

<Sync. 3 Spike CoreP6> Improvement requires understanding of current and future target state and of cause and effect so of experiments or spikes.
When knowledge of cause and effect are missing then spiking or experimenting are needed to discover the links. When cause and effect are well know (when we have transparency) then deciding the actions to be taken is easier. Taking them then needs collaboration.
<Sync. 4 Everyone> Combined with explicit policies and a spirit of “quality is everyone’s duty every day” the steps within the product’s lifecycle become easy to refine. Quotably we create the natural conditions for collaborative improvements”. Kaizen or “everyone takes responsibility for everything they can do to improve quality all the time” is a significant culture shift.
Identifying where change may be beneficial is aided by observation of the system in action, capture of metrics and hypothesis of cause and effect. These thoughts match Six Sigma’s Define, Measure, Analyse, Improve steps. Kanban Method’s author Anderson developed the method while at Motorola the originators of Six Sigma.
<Sync. 5 Failsafe> Within the Improve steps we must consider the implications of experimentation. Experiments should be designed quote in a safe-to fail manner. For example don’t test a new cars breaks by driving at high speed along a limited length road. Much better to put the car on a set of rollers where it doesn’t actually move while the wheels go around. Now poor breaking performance can never run out of road. A failure is still safe.
The 6 σ influence also says be scientific and data based. More to come in our next few lessons

End

Resources

Toyota Kata
Mike Rother presentation on Kata Mike Rother Presentation
DJA’s Kanban - scrum is “good enough, lean perfect & more”
Lean Thinker

End

§19 s151 = Kanban – further guidance 6/8

§19 s151 6/8 Further Guidance

Learning Outcome 1, Assessment Criteria 1.1 and 1.3
If we take the best of both scrum and kanban we can have a powerful approach.
- Anderson points out in his writings outside the book inspiring P2a that scrum and agile have different philosophies. Lean searches for perfection, agile accepts get it wrong and correct later, lean says wrong then correct is waste, the worst crime in the lean lexicon. There are further tensions but they are off the exam path There are also plenty of shared and plenty of complimentary elements
- While the danger is we get the worst of both the target is to get the best of both. Both use empiricism or decisions based on recent experience, both use daily stand-ups and other reviews to identify process improvements, both empower the team and insist on transparency.
Both set time as the fixed element and both compress time or accelerate results
- Kanban can be inserted into scrum as the method to control the work in a sprint. It can as happily and perhaps more powerfully be used at business portfolio level to direct change based work at portfolio and program and project level Jarno Vahaniitty twitter id @drAgileFant isn’t a bad start point. At portfolio level kanban selects the projects to be done based on operations ability to absorb change and the organisations capacity. Capacity to RTO vs Capacity to CTO.
- I’ve a free course here on the RTO/ CTO trade-offs LML’s Free Project Context Course, returning to P2a in both reduced breadth and depth of treatment – P2a sign-posts these topics, it does not explore them so for an exam target we don’t need quiet the detail I’ve been giving you. For future b@w™ use you need to explore further, see our other course offerings.
- So Scrumban is the use of kanban to administer the work of scrum’s sprints by using pull based workflow. A prince project can happily use kanban to run a whole stage and remove the sprinting structure or we retain the sprint structure and manage workflow via kanban techniques of starting work because a later step signals it is about to need the input. The later step requests or signals its predecessor to provide an input. In manufacturing cycle times tend to be uniform and predictable per widget. In projects and company start-ups every work item is apt to be different. Manufacturing kanban needs extra insight or technique
- <Sync. 2 Policy> one way to cope is Kanban Method’s defining of classes of service as we just explored. A class may be represented by a colour code eg standard is yellow sticky notes and urgent are pink notes. An alternative representation is to place swim lanes across the board. In all cases prediction and smooth flow is aided if the magnitude of tasks is about equal in terms of size & risk. With practise teams typically devise policies that divide work into smaller chunks while still delivering value and at the same time identifying and reducing risk
- <Sync. 3 control> Anderson’s Motorola background may account for the suggested approach to developing policy based on experiments. The quotable advise is “be scientific” validate quantitatively on empirical, objective data. 6 steps are described 1) ask a question and 2) do research so that 3) we formulate a hypothesis which we then 4) test with an experiments from which we 5) analyse results and 6) establish conclusions. this sound like dmaic as I explained earlier in this section in new vocabulary to me.
Next I’ll talk through the explanation of how to use kanban to manage workflow The P2a manual gives us more “what is kanban” than “how do you use kanban”.

End

§19 s152 = Cumulative Flow Diagrams (CFDs) 7/8

§19 s152 CFD 7/8

Learning Outcome 1, Assessment Criteria 1.1 and 1.3
An agile team often has a board on the wall that shows work status. The board is actually irrelevant.
- It doesn’t mean we are lean or agile or imbued with kanban ways. What matter is workflow is divided into a very few steps – as a six-sigma SIPOC would define for the P part if you know that tool. Each workflow step has its work capacity limit set by examining the team’s skills, numbers, physical resources, tools, perhaps work-stations and constraints.
- Before the flow we have a reservoir of items that are ready. In a configuration management and product breakdown sense these are a5 whose status is work-not-started. In the illustration each day is a row of the table and column of the graph – perhaps not the most intuitive twist to the layouts.
- Also we would not see the table and graph as illustrated here till the work is all done.
On day 1 all the work is waiting in the backlog so everything but the backlog is blank.
- After the last day all the work is in the deployed state. Actually given that the backlog includes MosCoW’s coulds and the won’t and we cannot yet include the newly discovered this scenario as I’ve just explained it is a little idealised. It’s a good start for a simple description. To be closer to exhaustive we will need to expand it.
- Between the start day and the end day the work flows through the steps so the backlog is depleted but maybe never to zero and the deployed accumulates to all that we intend to do being done.
- We would expect to summarise the information into a graph. A vertical slice through the diagram on any one day shows us what work is where. Since each process step has a limited capacity that ensures good even flow if we stick to the limits.
- A horizontal view across the graph shows how long it takes for a piece of work to flow through all the steps. The horizontal shows the key metric item lead time. Shorter lead times are desirable for quicker and cheaper delivery
Since The graph shows us the table and the table shows us a finished project lets use a time machine and go back a few days
- <Sync. 1 d12HiL> Lets imagine it is day 12. Now things look like this. The data for day 13 doesn’t yet exist!
- <Sync. 2 12 Status> Reading the graph is slice by slice and backwards from results achieved. A general rule of all project statusing is only and always focus on what is achieved. For status look at results not activity, for remedy and exploitation you can look at activity once you know status minus plan which gives variance.
- So the status at today is 8 deployed – dark blue, none ready to deploy that would be red, 4 in test light purple, 3 in build – dark purple and 4 pink are ready to build when capacity allows
- <Sync. 3 d13> When we get day 13s data the table has another row and the graph another column. Deployed is still 8 but ready has increased to 1 because an item has moved on from test. Imagine here the testing person visited the board and moved a sticky-note across a column and in conversation with team mates identified that two items can be pulled into test. We can see this because test was 4, is now 5 and an item moved on from test so test must have gained 2 items from Build. The test team member asked build collegues what can I pull, so build may now visit the board to see what they can pull from the waiting backlog
- You should pause here and internalise the words and picture. Imagine the team’s activity. They promoted an item pulled into ready to deploy so they pulled two items into test from build.
- Since build’s total has only gone down by one not two ready to build must have promoted one item to build which is why Ready changed from 4 to three

<Sync. 4 d14 > For day 14, again reading Right to left

Deployed is still 8, ready to deploy has increased again so 2 items finished test. Test’s wip has only decreased by 1 so the value of 4 shows an item moved on from build to test. Since build’s wip stayed at 2 it must have taken an item from ready. Ready has gone up 4 so 5 new items entered the Ready to build state on day 14. Perhaps a prior column “Not Ready” would be useful? Equally imagine the po\ had conversation with those they represent out in the business that led to addition of emergent newly desired features. In some environments scope creep in agile environments servicing the evolving needs of the business in a dynamic market place.
I’ll scroll the table slowly and you should pause each time and explain to your self what has changed by reading right to left across the table and up the graph. You can draw the table 90-degree rotated so that they both grow across, I guess you could instead also draw the graph rotated. Whatever orientation imagine the team’s conversations that move sticky notes to reflect upstream results achieved pulling downstream ready items onwards a step.

<Sync. >this is day 15.

5 newly deployed items and wip in ►test, ►in build ►and in ready all stayed the same number. That should lead you to realise that 2 new items entered the test state, so 2 new items entered build, so 2new items entered the ready state. If we had item id’s listed instead of counts you’d see that the items in each stage are changing even though the total of wip items per step doesn’t make it obvious. Notice that 2 items progressed into deployed from ready to deploy from test all in one reporting period so you also cant see its intra reporting period status. Perhaps to see them at rest in Ready 2Deploy we would have to snapshot at the hourly level.

<Sync. > Now day 16.

Another new ready state item because one of the two items in build is new because one build item was pulled into test

<Sync. > and 17

A newly deployed item means test pulled an item and so build pulled two as is evident in the decrease in items in ready

<Sync. > And so on,

day 18 the only movement is deployed pulled an item effectively from test, day 19 deployed pulled an item, test pulled 2, build pulled one, day 20 deployed pulled three, test pulled one, and build pulled one, finally on day 21 deployed pulled 3, one effectively all the way from build without intermediate stops being visible at the level at which we are seeing status updated.
What we will examine next is using the CFD for throughput assessment

End

§19 s153 = Cumulative Flow Diagrams (CFDs) 7/8

§19 s153 7/8 CFD

Learning Outcome 1, Assessment Criteria 1.1 and 1.3
<Sync. HiLight> We can’t tell from this analysis how long an individual item takes or when any particular item entering build is actually delivered but we can track the flow of work in aggregate through the system.
- <Sync. > and the average time in the system
- <Sync. Chart Lines> The vertical slices of the graph show wip and the horizontal view shows the average time between entering and leaving the kanban steps. Work entering on day 8 has, on average exited by day 14, five and a half days by the look of it.
- <Sync. 2nd lines> While work entering on day 15 is on average exiting by day 20, through put has speeded up
- Even without the full table of data we can tell by the deployed count rising from 0 on day 8 to 3 on day 9 that the initial delay in the system was 9 days
- Lead time is used as a basis for predicting the duration of remaining work and thus when work will be complete

End

§19 s154 = Kanban hints 8/8

§19 s154 Kanban hints 8/8

Learning Outcome 1, Assessment Criteria 1.1 and 1.3
Flow based approaches can be added to time-boxes at any level. One can flow a two week sprint or a three month stage. Quotable the flow system is within the project but you can and you should also run Portfolio management with kanban but this is a step off the exam path . Lets return
- Kanban is a suitable technique for P2a stage workflow management if the stage planning establishes the whole stage backlog.
- <Sync. 1 HiL>Otherwise we need the sprint planning meetings to select sprint backlog items from the product backlog. In either case the work content of a time box at sprint or stage level can be managed with a kanban approach
- Kanban, as part of lean is focussed on avoiding waste – muda – TPS identifies 7 forms of waste but that is beyond P2a. in P2a we know that delay affects time to benefits
- <Sync. HiL & Graph> With reduced delay we get reduced time to benefits and more efficient capital use. A double bonus. The quotable phrase is reduced cost of delay
- A lot of P2a focuses on deliver early, avoid delay. In timeboxing and scrum’s favour is the regular heartbeat of time to take stock that Sprint Planning Meeting (spm) and Sprint Review (srw) and Sprint Retrospective (srpv) provides. Against it prince already gives us the Work Package-A26 and stage as reviewed episodes in the project
<Sync. Little>There are other useful analyse such as queue length, and in-process time. In queuing theory; analysis of throughput includes Little’s Law.
- LL says if you know arrival rates and cycle time you know the number of items in the system, on average.
- Buying a train ticket or queuing at the supermarket checkout are classic examples. A single queue serving multiple tills reduces average wait time because a blockage at one till doesn’t block anyone in the queue attending other service points. Separate queues always creates potential for the highest total wait time while a single queue and multiple service points always has the best throughput.
- Kanban says we can use empiricism to tell us the recent performance and we know our backlog so we can determine our system’s capability and so forecast when we will have completed everything
- <Sync. Evolve> Interestingly the Chief Examiner also gives us here a reminder that TPS says start with existing process and then we improve gradually over time
- Exam question analysis next then b@w™ skill builder case study. Of course you could do them in the opposite order – your choice

End

§19 s155 = Paper_1 Qn_36

P_1 Qn36. Web&Go are working on the payment timebox.

The timebox includes the following requirements:
- Secure payment - Must Have;
- Allow payment by credit card/debit card - Must Have;
- Allow payment by PayPal - Should Have.

How should Web&Go start delivering the Team Plan where the Work in Progress (WIP) limit on the build column of the Kanban Board is 2?

a) By identifying at the beginning of the timebox that requirement 3 is unlikely to be delivered.
b) By measuring the number of customer requests for secure payments that are successful.
c) By pulling requirements 1 and 2 onto the Kanban board first, ready to start work on them.
d) By starting work on all three requirements at the same time to ensure that at least 2 are delivered within the timebox.

§19 EqA155 Eqn P_1 Qn_36

Standard approach
- Pause? Read stem and candidate answers
Welcome back?

See the Answers Section for Simon’s question analysis

See the Answers Section for the Chief Examiner’s analysis

Analysis © Logical Model Ltd, Exam Question Copyright © AXELOS Limited 2015. All rights reserved. No part of this publication may be reproduced in any form or by any means without permission in writing from AXELOS Limited. This information is part of the official PRINCE2 Agile® sample examination paper

§19 s156 = Back@Work_Skill-Builder™ Exercise-15: Kanban

§19 b@w™156 Back@Work_Skill-Builder™ Kanban

Practical use requires fluency and confidence with the techniques.
- Pause to read the slide’s guidance.
Creating CFD’s from raw data requires a little practice and I have a great simulation for you here.
- Reality requires a discussion of progress achieved that is then mapped to the kanban board to move progress markers. Here the raw data is in a table. You’ll have to apply the numbers to the kanban board you draw (or the templates I provide in the separate download for this Back@Work)
I’ve provided three things I hope help!
- First a worked example from the same start point as the exercise but with some differing progress assumptions. Following it through takes effort to understand. Understanding this topic definitely takes effort if you are to internalise the topic.
- The worked example progresses the kanban board and the CFD day-by-day against some assumptions. The solution I’ve given illustrates the process but my solution is very inefficient. One challenge you can take on is ‘Can you vary the order of work assignments in search of greater resource efficiency’? 0 Clearly you can! :-)
- Second and third are two blank templates. To emulate how I processed the data you can use one or both. One template is for pencil and paper –print it out to give yourself a work-space. The other is an empty .xlsx for you to populate – If you discover a bug in its formulas please let me know – It works ok for me!
- Have fun and as ever just shout in any of the available forums to let me know when you need support.
- The downloads are in this section of the eLearning Course and freely accessible §19 wkbk156 Worked Example (create a login if you don’t have one, access to these downloads is free)

End

Copyright © AXELOS Limited 2015. All rights reserved. No part of this publication may be reproduced in any form or by any means without permission in writing from AXELOS Limited. This information is part of the official PRINCE2 Agile® sample examination paper

VnCtl:14/08/2016 18:26:54 This file is part of Logical Model Ltd’s p2a training course

Up next

Section:34 s226 - §34 The Exam