You are here

November 2015

improuv war ja Sponsor der diesjährigen LKCE 2015 (Lean Kanban Central Europe). Wir hatten einen Stand und für mich war dies meine erste "Kanban"-Konferenz. Ich war gespannt, denn ich gehöre eher zu den Scrum-Vertretern und kann mich noch lebhaft an Zeiten erinnern, als man erbittert darüber gestritten hat, ob Scrum oder Kanban die bessere Methode ist. Von diesem Streit war auf der Konferenz nichts mehr zu spüren. Ich habe den Eindruck, die Methoden werden weniger wichtig, die beiden Lager nähern sich einander an.

Meine ersten Berührungspunkte mit “Scrum und agiler Softwareentwicklung” hatte ich im Herbst 2008. Ich dachte, dies sei eine “neue Modeerscheinung”, die mich aber sehr neugierig gemacht hat. Als ich mich näher mit dem Thema auseinander gesetzt habe, sind mir Schlagworte  wie “Selbstorganisierte Teams “ und “flache Hierarchien” ins Auge gesprungen und ich dachte mir, dass dies ein guter Ansatz sei, sich aber niemals in den Unternehmen etablieren lassen bzw. durchsetzen würde.

Were you ever lucky enough to work with a Product Owner who actually writes acceptance tests? My experience as Agile Coach is that most of the Product Owners don't write acceptance tests. Lucky enough in my last project I was Product Owner. And therefore I decided to establish ATDD within my team.

I often hear "we have to get 80% test coverage!“ or „our coverage is too low“. Does this sound familiar? Many teams or developers strive for high test coverage. But why? In most cases what they want to build a safety net through high test coverage. This safety net allows us to trust our system and enables us to change the system. Yes, uncovered code means there is a blind spot. I totally agree.