Kanban is something that features in both Lean Six Sigma and Agile software development. It descended from the Lean improvements of the Toyota Production System, and is a proven approach to optimise effectiveness of a production line system. How then can it be useful for a project manager, if it’s about production lines for motor vehicles I hear you ask? Well, for software development projects at least, the software development life cycle of individual software “features” is very much like a production line. Ok, so you aren’t creating the exact replica of a specific part over and over again - they will vary. But if features are segmented such that they are all of a similar size and complexity, the production line approach can work.

What’s the value of this production line approach? Simply, it’s the speed of throughput - or Lean Cycle Time. Ever had a of scope item/task/work package just drag on forever, with the percentage complete painfully increasing by just a couple of imprecise percentage points per day? Ever just want to get stuff moving and feel like work is reaching a completed state? Kanban may be for you. It links to Agile because Agile development is all about delivering early value to the customer and incrementally improving it with further deliveries - incremental delivery. The Kanban production-line system focuses on getting throughput in the software development lifecycle, so stuff gets “done” (remember: we need to define that in agile!)

So, what are it’s jet features and how does it work? I’d highlight two critical components:

(1) Visual Kanban Board - Kanban uses a visual board to bring attention to the startus of each item that is Work In Progress (WIP), and uses columns to delineate the progress with each column representing a phase of production. An item is recorded in a “card” that starts in the left hand column and progressively moves through each column, representing each stage in the process until it reaches the right hand side and is “done”. In the software development lifecycle these will be things like: backlog, selected for development, in development, testing, user testing, implementation, done. The precise columns can be more extensive, and some organisations would use two columns m for each phase: “Waiting” or “In Progress”, meaning that waiting time (which in Lean is Waste) can be more clearly identified. M I’d recommend you document in your project approach/tailoring the precise standards around each phase: Input & Output Criteria and Evidence Required at each stage (test scripts, approvals etc)

(2) Limiting Work In Progress (WIP) - While the Kanban board is a visually arresting part of the approach, the real key lies beneath the surface in how it limits production in the system. Kanban knows that there will be natural bottlenecks in certain stages of the process, so pushing more work to in progress that can pass the constrained part of the process is pointless - it won’t speed up delivery, is just wasting resources, diverting attention and adding complexity by having more plates spinning. Kanban lImits WIP by only allowing so many items in production in any one time, achieved by limiting the total number of work cards on the board, or by only allowing so many work items in each column of the Kanban board at any one time. The focus is then on expediting the few items that are WIP before looking at new scope; this is achieved by reviewing the Kanban board in a right-to-left manner and the potentially using approaches such as swarming - having many people focus on a single item. When reviewing the board, ask: what do we need to do to get the items neatly done across the finish line? Then as we move leftwards through the columns what do we need to do to get each item moving to the next column along? Only at the end of this process do you reach the left hand end of the board and then consider bringing in new scope into WIP. In this way Kanban is regarded as a “pull” system rather than a “push” system.

What are your thoughts on Kanban and have you had much success in implementing it on your projects? Let us know your thoughts below!

Stay Healthy - Project Health Check - projecthealthcheck.org

Agile is an approach which is extremely prevelent in the IT industry, to the point where unfortunately the word “agile” tends to be thrown around everywhere, often out of context. Agile is strictly speaking a mind-set, with four foundational values and twelve supporting principles from the Agile Manifesto. There are many specific methods which fall under the banner of Agile, but Scrum is probably the best known and the idea of a daily Scrum to manage work is common to almost all agile developments. My initial experience of Scrum started a number of years back, where I found myself as both Project Manager and sometimes Scrum Master for a major Agile Project. I had a bit of a theoretical agile background, but no practical experience, so I soon found myself in at the deep end.

It was a really useful experience, and I learned a lot about Agile and Scrum along the way; I thought I should share some of those Scrum experiences and Lessons Learned:

1. When: The Scrum should be at a set time every day without fail, early enough in the morning to set the tone for the day but late enough to ensure everyone is consistently in the office in time - I suggest around 9:30 - 10:00 is ideal. The key is to make sure everyone attends on time, and the meeting starts precisely when it is planned. If you feel brave, a top tip is to physically lock the door once the start time is reached and lock-out late attenders. They will be bemused and frustrated, but it will soon get the message across and they won’t be late again. I suggest the Scrum should be 15 minutes in duration, short and sharp - any longer and you are just waffling. Get a high quality and visible wall clock, set it right and make sure everyone knows that is the master time clock - then there are no excuses! The basic discipline of everyone being in the right place at the right time will help set the tone for the Project, and combat the view held by some that agile = sloppy.
2. Burndown: The Sprint Burndown is essentially your real-time status report on the Sprint, it tells you as Project Manager as well as senior managers who take an interest, how the Sprint is progressing. Have the Sprint Burndown on a screen for all to see when they assemble during the buffer time; this will help foster the mind-set that it is a team effort and the entire team is responsible for that progress, and it is literally a sprint to get the scope delivered in time
3. Stand Up: I'll be honest and say we used to sit down when I used to attend scrums, but I regret it. We always got nice and comfortable, then the meeting dragged on for half an hour. By physically standing up it encourages brevity from participants. I walked through an office recently and saw a bunch of people in what must have been a scrum. They were sitting…
4. Agenda - Each scrum team member provides an update on 3 things during the Scrum:
   1. What they did yesterday
   2. What they will be doing today
   3. What is blocking their progress. As PM you should be particularly interested in listening to these, catch the team members off-line after the Scrum to see if you can help remove those obstacles – your priority is to be a servant leader and to help make their job easier.
5. No Discussions – Be aware of the risk of discussions starting up from these three update points; have an egg timer on hand and as soon as someone asks a question then the scrum master should visibly tip it over in the middle of the table – when it runs out then discussion stops and it gets taken offline after the Sprint. This stops the meeting dragging on, losing focus and wasting a lot of attendees’ time.
6. No External Input - Only the project team can contribute, that is those completing Story Points and contributing towards Spring Velocity. As PM this may mean that you don't contribute and are not allowed to talk! It depends how you translate the traditional PM role into Agile, but definitely no senior managers or external stakeholder interrogating the team or asking questions - shut them up and kick them out! If that means you as PM needs to take heat to protect the team then so be it, as a servant leader you need to protect them from distractions.

What experiences do you have of Scrums, and how effective were they? Let us know!

​Stay Healthy! Project Health Check - projecthealthcheck.org