Ich zweifle nicht daran, dass KANBAN Boards in gewissen Bereichen Sinn machen, ich zweifle nicht daran, dass die Grundideen verdient sind. Aber ich beginne zu glauben, dass wir nun eine Person brauchen, die uns sagt wohin wir gehen müssen, um ein Certified KANBAN Master zu werden.
Offensichtlich besteht Bedarf. Ein neuer Markt öffnet sich. Ich lese immer mehr über die neuen Ideen von KANBAN und wie schlecht Scrum dazu im Vergleich ist. Ich suche nach neuen Best Practises in Scrum und kann sie nicht finden. Wirklich gute neue Ideen, wie ein ScrumMaster mit den Problemen umgehen soll, die ihn betreffen, sind sehr selten.
Diese KANBAN Prediger [1] klingen wie die Scrumalisten wenn wir über CMMI und Waterfall schimpfen.
Also ist mein Vorschlag, eine eigene Certified KANBAN Master Klasse zu bilden. Vielleicht entsteht so ein neuer Hype.
[1] http://ow.ly/16DBDN , http://borisgloger.com/2010/02/22/hotnews-collabnet-kauft-danube-scrumworks-hat-einen-neuen-besitzer/#comments
I’m about to start day #3 of David Anderson’s Kanban Coaching Workshop. This is my first true deep dive into Kanban, after practicing Scrum for the past 3 years. I doubt that there will be a Kanban certification, at least not one produced by David. Kanban is much more flexible than Scrum, so there is no “one true way” to teach. Don’t get me wrong, I do love Scrum, but I feel many consultants have stopped allowing it to be as flexible as it can be.
Same here.
We discovered Kanban to be much more flexible than SCRUM. And you can adjust it to your individual needs. (Nevertheless SCRUM gives you a “more security”, when it comes to forecasts/velocity…)
There is no need for a certificate. You can explain the basics of Kanban within an hour and then go from there as you like…
Nochmal, KANBAN mag flexibler sein, nur was denn daran? Scrum war nie eine Methode, sondern hat immer nur gesagt: Ask the team, delivery every month, and inspect and adapt. Scrum hat Werte, und einige Praktiken. Das wars dann auch schon. Wo ist denn da bitte eine Unflexibilität? KANBAN ist doch nur der logische nächste Schritt für das Taskboard und das Auflösen des Sprint Plannings das sicher für produktionsnahe Environments Sinn macht. Aber — in meiner Definition ist KANBAN Scrum. Hat sich nix geändert. Der Prozess ist ein wenig anders. KANBAN hat aber einen entscheidenen Nachteil. Wieder wird so getan, als wäre Software Entwicklung eine Ingenieurwissenschaft. Was sie nicht ist.
Why not, Boris? Why not certify agile experts instead of Scrum Masters? Because I think any Scrum Master needs to know agile tools / methodologies anyway, why not generalize the whole thing? The only thing that is really different is where you start to analyze / optimize in the different methodologies. The tools are mostly the same.