Save £12 Million every year > Save £3 Million every quarter   
The Big Agile Toolkit: no Dogma, no Bias, no Accreditation, no Exams & no Fees   
 SCRUM  SCRUM   SCRUM-ban   SCRUM-ban

Introduction   »   Agile Flavours   »   Kanban


This is one of those agile processes, it seems, you are probably going to either love it or you are going to hate it. We would suggest that you do not pass judgement yet as Kanban has some basic agile principles embedded in the approach. However, we must remember than Kanban concepts arose following the trend in the 1970s for improved automotive manufacturing processes pioneered by Japanese management. This was evidently the right process at the right time. It is suitably demonstrated by the number of successful Japanese car manufacturing companies and the very broad investment by Japanese automotive organisations worldwide. Let us look at how these relatively bygone concepts retain such agile self belief and such agile disquiet.

Kanban has fanatical followers and serious, professional doubters. The choice of agile development method is really up to you and if Kanban works for you then so be it.

The governance structure of The Big Agile Toolkit will accommodate and extend the Kanban method regardless of whether it is universally glorified or roundly condemned in your organisation.

Kanban is an incremental, evolutionary change method to deliver solutions using just-in-time (JIT) delivery. Kanban is based on the 5 Core Properties.
  1. Visualize the workflow,

  2. Limit Work In Progress,

  3. Manage Flow,

  4. Make Process Policies Explicit,

  5. Improve Collaboratively (using models & the scientific method).

It proposes three ethos steps:
  1. Start with what you do now.

  2. Kanban actively chooses not to prescribe a specific agile process. Therefore, there is no end to end Kanban Software Development Process or any Project Management guidance. The reality for real world production agile projects is that they need to work inside the overall delivery processes of the target organisation. Realistically, they need guidance on how this fits with an existing governance process, whether this is a waterfall governance or not. Starting an agile project inside a rigorously waterfall governance is setting up for failure. You cannot doubt the integrity of the ethos but we offer that Start with what you want to do from now is the humble and more pragmatic approach.

  3. Agree to pursue incremental, evolutionary change.

  4. The method seeks to stimulate promote and encourage continuous, small incremental and evolutionary changes to your system. This is a generic agile concept and is wholly enshrined in the Commitments section of the Toolkit. Small fast emerging solutions are much more successful and ultimately more suitable in a business scenario than almost any other alternative granular development approach. The embedded business teams you have within your project will bring this ethos around and the manager or coach will make sure it is persistent. However, agile managers and delivery practitioners seek advice and guidance about how this works on real projects. Kanban presents an ideal to pursue that is laudable. It is a basic agile principle yet the method offers no process or mechanism to deliver it. The casual, open ended nature of the offer is therefore an offer that is too open-ended and casual. Furthermore, casual processes tend towards the chaos that agile doubters love to scorn. This Kanban ethos is a generic agile concept and evident in almost all agile approaches.

  5. Respect the current process, roles, responsibilities & titles.

  6. Kanban states that an organization currently has elements that work acceptably and need preserving. This is laudable and courageous. It also suggests that current role titles be maintained. With this idea, we agree wholeheartedly. Naming people Chickens or Ambassadors on agile projects we discuss elsewhere in the Toolkit. The election of an agile process that involves role name change is often faced with opposition. This immediate reaction does not set the scene for good agile relations across a project. The role name changes are done in agile circles to consolidate the agile process, to make it unique, identifiable and distinguishable from the rest. It is counter to an open culture. This Kanban ethos is a brave agile concept as the determined dogmatic denizens of the various agile approaches protect their role names, doggedly. If Kanban says drop the silly role names, we say fine and move on.
Once again many articles and publications exist to further explain the detail and application of the method. Some of these are illustrated on our links page others are available via your preferred search engine.

Buffer



 SCRUM     SCRUM   SCRUM-ban    SCRUM-ban



Glossary:     a  »   b  »   c  »   d  »   e  »   f  »   g  »   h  »   i  »   j  »   k  »   l  »   m  »   n  »   o  »   p  »   q  »   r  »   s  »   t  »   u  »   v  »   w  »   x  »   y  »   z


#personas  »   #artefacts  »   #archetypes  »   #patterns  »   #change  »   #personas  »   #increasingoutput  »   #reducingvariation  »   #improveefficiency  »   #abstraction  »   #predictionandcontrol  »   #management  »   #organisations  »   #socialnetworktheory  »   #failfast  »   #quality  »   #waste  »   #complexity  »   #learning  »   #adapt  »   #inspect  »   #improvement  »   #models  »   #complexadaptivesystems  »   #informationflow  »   #sytemsthinking  »   #butterflyeffect  »   #unpredictability  »   #chaos  »   #emergence  »   #emergentbehaviour  »   #distributedcontrol  »   #continuousimprovement  »   #complexityscience  »   #gametheory  »  
 Agile In 6 Steps    |    Projectivity    |    Instant Agile    |    Risks    |    Auditing Agile Projects 
Big Agile Toolkit Book (Amazon Japan)   |   Big Agile Toolkit Book (Barnes and Noble)
Buy the Big Agile Toolkit Book   |   Buy the Big Agile Toolkit Kindle eBook
Kanban






   


The Big Agile Toolkit

 SPADE: Successful Pragmatic Agile Delivery Everytime™ 
   
Topic: 16  Page: 17/444  Progress: 3.8%
 About    |    Author 
Follow @BigAgileToolkit


This content can be copied to third parties for personal use if you acknowledge the source of the material with website URL (http://www.bigagiletoolkit.com/) and Twitter hashtag (#BigAgileToolkit).
In all other cases, no part of bigagiletoolkit or associated text or website may be copied reproduced or redistributed in any form or by any means without prior permission in writing from the author.
Agile Project Governance for Cost Conscious Companies™

All rights reserved.