Posts tagged ‘Kanban’

Lawless Agile

In march 2012 seven it-agile people (including me) formed the StartupMarch team. We decided to build a product to make online discussions more effective. In the end we had built and
This blog post is about the “process” we used. We just started to build the product – without any discussion of the process to use – Scrum, Kanban, XP? We just didn’t talk about it. This is what emerged:

  • Before the start of the StartupMach we only had decided on the problem to solve (online discussions) and the technology we would use (Rails). So we invested the first day for some conceptual work.
  • At the second day we started the development of the first ideas. We had the first product (Duscuss2Decide) live at day 3 and the second (Discumeter) at day 5. After that we had more than 15 releases per day. The rule was simply: whatever you commit into the master (aka Trunk/Head) will go live immediately.
  • Typically we started the day with an informal wrap up of the product usage (a kind of review if you want). Then we discussed what to do during the day (kind of planning). And then we did it. For both “meetings” together we invested 30 to 90 minutes.
  • During the day we had 2 to 4 sync meetings to check where were and how to proceed (kind of Daily Scrum).
  • We did no Task Breakdown but Story Splitting on a very tiny level. We worked with MMFs (Minimal Marketable Features) that we broke down into User Stories. Most stories were done in less than 2 hours.
  • We managed work in progress by gut feeling. Normally we all would work on the stories of one MMF (single piece flow). That way a MMF normally needed one day to complete.
  • We did Pair Programming in most cases and often switched pairs at the sync meetings.
  • We had two retrospectives. One in the middle of march, one at the end of march.
  • There were no roles. No Product Owner, no ScrumMaster, no Testers etc. Just team members. During our second retrospective we had a discussion about the roles. The conclusion was that we sometimes would have profited from a ScrumMaster for facilitating discussions and forcing us to face uncomfortable facts. And we thought that the absence of a Product Owner person was helpful. The team was not only empowered to decide on how to do the work but also on what to work on.

It was a great time. We had a lot of fun, we learned a lot and it felt very productive. Although we didn’t acquire millions of venture capital for our products, Discuss2Decide seems to have value for users. There are some regular users of the tool and most online discussions at it-agile are done with the tool today.

Will it travel?
Will the “process” travel to other contexts? I don’t know. I think there were two special ingredients that are uncommon and may have been crucial:

  1. With the seven team members we had roughly 45 years of experience with Agile of different flavors in the room: Scrum, XP, Kanban, FDD.
  2. All team members shared a common cultural background (it-agile) that showed up as an extreme openness for other’s ideas, perspectives and needs.

Read more about the Startup March.

May 17, 2012 at 6:58 pm 1 comment

Artikel “Auf der Suche nach dem Qualitäter” erschienen

Mein Bruder Arne und ich haben zusammen einen Artikel mit dem Titel “Auf der Suche nach dem Qualitäter” im “Business Technology“-Magazin veröffentlicht, das in der Ausgabe 1.2012, Heft 8 ganz unter dem Titel “Qualität” erschienen ist.

In dem Artikel beschäftigen wir uns mit der Frage, was überhaupt Qualität ist und stellen die klassische Qualitätsdefinition (“Qualität ist die Übereinstimmung der Realisierung mit den Anforderungen.”) in Frage. Wir stellen die kundenorientierte Qualitätsdefinition (“Der Kunde definiert, was Qualität ist.”) dagegen und bringen diese mit agilen Verfahren wie Scrum und Kanban in Zusammenhang. Nicht zuletzt zeigen wir auf, wie die kundenorientierte Qualitätsdefinition in der Softwareentwicklung besondere Herausforderungen an die interne Qualität des Systems stellt.

Auf der JAX-Konferenz werden wir übrigens zum gleichen Thema zu sehen sein, allerdings in einem etwas ungewöhnlicherem Format (Schauspiel).

March 5, 2012 at 5:55 pm Leave a comment

it-agile: State of Play

We founded it-agile seven years ago. This is a good reason to reflect on what we have achieved regarding management and organization within it-agile. Some of the things listed below were already in place seven years ago, others are just a few days old.
We believe that our employees are it-agile with the implication that the best employees would make the best it-agile. And we do not just aim for satisfied customers, we want to delight our customers. To express these believes we have a defined purpose:

“Create fulfilling jobs for our employees to delight customers.”

We achieve this purpose by:

  • Transparency and openness: Nearly every information is visible for every employee including the wages, travel expenses and time sheets of every colleague (the CEOs are just colleagues also). On a company level the economic data etc. are accessible for everyone.
  • Peer groups: Employees have self selected peer groups that work with the employee on personal improvements and suggest promotions.
  • Pull principle: We have implemented the pull principle for coaching and development. Customer requests are visible for the whole company and employees pull these. So employees may choose to prefer jobs in their local area and decide on themselves if they are capable of doing the job.
  • Meetings at it-agile are optional. Every employee decides for himself if he attends.
  • As long as the results are achieved everybody can work when and where he wants. (Of course this has to be coordinated with colleagues and customers since most of the results can’t be achieved without colleagues and customers.)
  • Every employee has 30 days of slack were he can do whatever he wants: go to conferences, work on a self selected project, read books, go to trainings, … Of course it is transparent within it-agile what everybody did.
  • Employees don’t apply for holidays. They decide on themselves when they take their 30 days of holiday.
  • Overtime: There is no pressure for working overtimes. Sometimes employees decide themselves to work overtime to achieve important results. The overtime is collected in a work hour account. Employees decide when to withdraw time from that account.
  • Expenses: Employees decide how they travel and what equipment they need for their work. They don’t ask for permission. They just buy what they need.
  • Profit sharing: About 2/3 of the company profits are distributed to the employees (in principle every employee gets the same percentage).
  • Company ownership: About 2/3 of the company is owned by the employees. This implies ultimate empowerment: The employees can change ANYTHING. They could even fire the CEOs or change the purpose of the company completely.

Is it successful?

We have more employees, we have higher revenues and we have higher margins today than we had in the beginning. You never can be sure if the described principles created this growth or if it just was good luck. But I think we were and are successful.

Will it travel?
In general the described concepts shouldn’t be taken as a blueprint for another organization (although there are similarities with other companies like SemCo). I think we wouldn’t have been able to start with out current state even if we had known it. I think that we observed a kind of co-evolution during the last seven years. We made a small modification to the organization of the company. That enabled a small progress of company culture. This progress in company culture then enabled the next small modification of our company structure and rules. And so on…

Will it scale?
We started it-agile with 10 people. Now we are 35. In my point of view the things we did enhanced empowerment and autonomy which are important building blocks for our growth. The changes we made enabled growth. I think for further growth we have to intensify empowerment and autonomy even more.

The Future
Since there is no big boss at it-agile you never know what will happen next. There are some very interesting and challenging discussions in the moment.

BTW 1: We are hiring agile coaches and developers. (Notice; Sometimes people seem to think they wouldn’t match our expectations and therefore don’t apply for a job at it-agile. There is only one way to find out: Let’s talk!)
BTW 2: We offer consulting to managers who want to transform their company/business unit in an agile way towards more empowerment and autonomy.


January 30, 2012 at 1:02 pm 7 comments

Vorträge “Innovation – das wahre Bottleneck?!” auf der OOP 2012

Auf der OOP 2012 habe ich einen regulären Vortrag sowie ein Pecha-Kucha zum Thema “Innovation – das wahre Bottleneck?!” gehalten.

Die Folien für beide Vorträge finden sich inkl. Foliennotizen auf Slideshare:

Inhaltlich geht es darum, dass meiner Meinung nach viele Produkte / Systeme zu wenig Nutzen erbringen und wir dieses Problem nicht dadurch lösen, dass wir Anforderungen schneller umsetzen. Wir müssen es dadurch lösen, dass wir wertvolle Features entwickeln, auch wenn wir dadurch etwas langsamer werden.

January 25, 2012 at 9:08 pm 2 comments

Buchtipp: The Lean Startup

Wie können wir schneller lernen, ob Produktideen erfolgreich sein können oder nicht? Dieser Frage geht Eric Ries in seinem Buch “The Lean Startup” nach. Er fordert sogenanntes “Validated Learning”: Man formuliert seine Annahmen in der sogenannten Customer-Problem-Solution-Hypothese (welche Anwendergruppe hat welches Problem und wie gedenken wir es zu lösen) und definiert ein “Minimal Viable Product” (MVP, Minimal Brauchbares Produkt), mit dem man seine Hypothese überprüft. Das Ziel des MVP besteht darin, Annahmen zu überprüfen und lernen und das möglichst schnell. Man erstellt also ein MVP, dass so rudimentär ist, dass es fast nicht funktionieren kann – fast. Wenn wir (nach vielen Fehlschlägen) dann Hypothesen gefunden haben, die sich bestätigen, baut man das MVP schrittweise in Richtung eines richtigen Produktes aus.

Eine Besonderheit sind dabei die extrem kurzen Zyklen, die man anstrebt. Wir haben erst vor wenigen Tagen an einem halben Tag eine Customer-Problem-Solution-Hypothese definiert und ein MVP entwickelt.

Offensichtlich ist dieser Ansatz nicht nur dann sinnvoll, wenn man ein Startup gründet. Passend dazu definiert Eric Ries Startup als Produktentwicklung unter großer Unsicherheit. Das Buch adressiert als das Startup in der Garage genauso wie eine Produktneuentwicklung in einem Konzern.

Ich finde, das Buch ist sehr gut geschrieben und es stellt einen wichtigen Meilenstein in der Entwicklung unserer Branche dar. Allerdings fokussiert das Buch darauf, den Leser vom grundsätzlichen Ansatz zu überzeugen. Es bleibt manchmal etwas schwammig, was man konkret machen soll/kann. Außerdem handeln die meisten Beispiele von Internet-Anwendungen. Für andere Produkttypen ist etwas mehr Transferleistung notwendig. Bestimmt kommt demnächst ein Nachfolgebuch “Implementing the Lean Startup” heraus, in dem konkret beschrieben wird, wie man es denn nun macht. Trotzdem ist auch dieses Buch absolut empfehlenswert.

October 25, 2011 at 8:42 pm 3 comments

G Forces, Release Cadence and Feedback Cycles

When I saw the G Forces presentation by Kent Beck at the Lean Kanban Central Europe conference  had an insights that wasn’t that clear to me before.

For those who don’t know the G Forces presentation: it is all about shortening release cycles from months to weeks to days to hours to minutes.

What became clear to me: The release cadence is not the real point. It is all about feedback. You have to be able to incorporate feedback according to your release cadence. Releasing every day doesn’t help too much if you need a month to collect feedback and react on it.

Perhaps we should reflect that with our metrics. What about Feedback Cycle Time and Feedback Coefficient as new metrics for teams?

Feedback Cycle Time would be the time you need from the release of feature A until you are able to release feature B that incorporates the learnings from feature A? For example: You release feature A to production on 1st of february 2012. Then you collect data from the production usage of B for 1 week. You discuss the findings for one week and take another week to redefine some of the features in the backlog. And then you need 3 weeks for implementation, test and release of feature B that incorporates the learning. In this scenario your Feedback Cycle Time would be 6 weeks.

The Feedback Coefficient would be Number of Features for which feedback was collected / Number of Released Features. For the Feedback Coefficient it doesn’t matter if the feedback was positive or not. The only important thing is the learning. When we are honest most teams today achieve a Feedback Coefficient of zero or very near to zero. The optimum would be 1.

I think both metrics would focus on a weak spot in many teams: The teams try to maximize throughput and minimize lead time but don’t really care about feedback from the market.

October 19, 2011 at 9:13 pm 5 comments

Scrum, Kanban and Naked Planning

Some teams start with Scrum, excel with it and then adapt Scrum to go even further. Some of these teams dismiss interations and claim to do Kanban.

Other teams start with Kanban, eliminate columns of their Kanban board, reduce WiP and increase teamwork.

The results are very similar: There is a short backlog of things that create customer value (sometimes called Minimal Marketable Features, MMFs). The team picks the item with the highest priority and splits it into smaller User Storys or Tasks. When an MMF is completed it will be delivered. That’s it. The would result in a 3 column board: ToDo, Doing, Done. This board design is similar to a Scrum taskboard but the “process” is different. Since there are no iterations there is no distinction between a product focused backlog and an iteration focused backlog.

The interesting thing here is that this is mainly what Arlo Belshee named “Naked Planning”. He did that already in 2007 (perhaps even earlier) but only few people recognized it! Nowadays Naked Planning is sometimes reframed to be simplified or small Kanban.

Perhaps both of the above teams should say they are doing Naked Planning (or trying to do) and try to improve even further by having a deeper look at Arlos work (like doing Single Piece Flow for MMFs and limiting the number of MMFs in ToDo zu seven).

As far es I know this video is Arlos first description of Naked Planning (2007):

October 1, 2011 at 2:10 pm 1 comment

Older Posts Newer Posts