Kurt's Blog

March 23, 2014

Frankfurter Entwicklertag 2014

Filed under: conferences — Tags: , , , — Kurt Häusler @ 10:05 am

On the 19th of February I attended the Frankfurter Entwicklertag (Frankfurt Developer Day). It is not the sort of event I have been recently attending as my interests are slowly moving away from software development, and more towards management of the wider value stream. I entered a draw at the christmas meeting of the Agile Rhein-Main user group and was lucky enough to win a free ticket thanks to Andrena Objects.


It was a very well organised and promoted event. I liked the strategy of engaging with the community and giving away free tickets. They managed to sell all the tickets I believe. 

I deliberately tried to stay away from “agile” related topics, as I think I have been well exposed to those sorts of things and I wanted to leave my (current) comfort zone and take the opportunity to hear some technical topics that I have been focussing on less lately (which is my old comfort zone). My favourite talk was the one about Event Sourcing, as actually practiced by Vaamo Finanz. This was great as event sourcing together with CQRS was all the hype in the DDD community around 2009/2010. I could see the potential in the idea, and played around with it myself, but unfortunately didn’t get to experience it for real in my work. I remember talking about it, and even leading open space sessions on the topic at various conferences, where we focussed a lot on the theory but people were hungering for actual practical experience reports. Then it seems like either the topic died down a bit, or perhaps my interest drifted away a bit. Then all of a sudden 4 years later I see an actual experience report, and all the potential issues we were discussing in theory back then were reported as actual findings, and it was great to hear about how Vaamo actually dealt with the issues. It felt weird that something should at the same time be leading edge, yet still feel like a nostalgic trip down memory lane. The talk was superb. Full of interesting technical content, and very well presented. It was engaging, relatable, and entertaining.

Overall, I don’t think I would have paid the asking price for the ticket. I would have preferred to see it as a community event with more costs covered by sponsorship with perhaps a maximum ticket price around the €30 mark. Specifically because it was so wide and general. I think it is a good conference to send developers to to get up to speed on a fairly random selection of interesting topics, and they can deep dive into anything potentially interesting at a more specialist conference after. If I was a developer, i would have probably already had an idea about what specific technologies would be relevant to solving my specific problems and I would have attended a more specialised conference where I can go into more detail on one thing, rather than get a fairly superficial overview of a bunch of random topics, many of which are not likely to be relevant for me at any given time.

I didn’t see a huge connection with the stated list of focus areas: Agility, Quality and Innovation, but that doesn’t matter too much I guess.

Another concern was the level of female participation. There were female attendees, but worryingly few. Only one female was involved as a presenter, and there were no women in the program committee. This may not yet be as much of a concern in the German speaking countries as much as it is in the English speaking ones (where conferences have had to be canceled after a backlash against all-male program committees for example!), but I think it is something even in Germany we need to be much more concerned about.

A big thanks to Andrena for organising, and of course for my free ticket!


February 10, 2014

Conference Catchup

Filed under: conferences — Tags: , , , , , — Kurt Häusler @ 11:06 am

So normally I try and write up a bit about the conferences I attend, but I have been a bit slack lately. Since my last post about the play4agile event and the agile coach camp, I have attended 4 interesting events that I would like to share about. I am going to keep it short, partially deliberately, and also because the first two events took place a while ago, and the other two I forgot to take notes for.

In June the exclusive, invitation-only, Kanban Leadership Retreat in Mayrhofen, Austria took place.  This was my first one, and it was amazing to catch up with the world’s leaders in developing and applying the Kanban Method. One of the first sessions was also one of the best. Sigi Kaltenecker and Klaus Leopold talked about their still-in-development ideas about looking not just at Kanban practices but at change and leadership practices in the organisation. For me it was essential to see a list of concrete practices under this topic because concepts like Change or Leadership can tend to be a bit abstract. 

It was also interesting to hear from Dimitar Bakardzhiev about what has been happening in the Theory of Constraints community. He mentioned that they seem to be a lot less scared to talk about money than e.g. the Kanban (and Agile) community. I definitely think we should talk about the financial aspects of knowledge work and product development a lot more.

I saw a case study presentation from Nina Schwab at Tupalo in Austria. They had an innovative approach with a horizontal lane at the bottom for cards to leave the system and travel right to left and reenter the system, which to me could be used to implement the feedback loop required in The Kanban Method. Things learnt could be placed in this lane and flow back into the input queue.

I missed Troy’s session, which might have been a mistake as I heard it was really good.

Some miscellaneous points I noted down include things like:

  • Change should not be a separate initiative, it should be part of the actual day to day work.
  • We can start with the practices, and then move on to more abstract things like values and goals.
  • If were to pay enough direct attention to change and leadership practices Kanban itself may become almost of secondary importance.
  • Kanban is for building learning organisations.
  • The principles and practices are “kickoff” focussed, and less relevant for running systems.
  • I still need to look more into the Toyota and/or Improvement Katas.

I would like to thank my former employer ETECTURE GmbH for funding my participation at the Kanban Leadership Retreat.


In August I attended and even spoke at the Agile Lean Europe Unconference in Bucharest. I actually combined it with a family holiday, as the ALE unconferences have an awesome family and spouse program. I attended the one in Berlin in 2011, but missed the one in Barcelona in 2012. It was great to catch up with the agile lean community again.


I won’t go into too much detail about the sessions I attended as everything is available online. Videos and slides. The highlights for me were the keynotes from Jurgen Appelo  and Joe Justice from Wikispeed, and Vasco Duarte’s #NoEstimates session.

I chose not to take part in the evening social activities as I was enjoying exploring Bucharest with my family. 

I think my talk about Offers and Pricing went well, and inspired quite a bit of subsequent discussion. You can see the slides here:

Offers & Pricing from Kurt Häusler


My family and I actually stayed in Romania an extra week where we went to the beach on the Black Sea for a relaxing holiday.

Although I funded my own participation, I think it is important to thank the sponsors for their support.


The third conference I need to mention is the Lean Kanban Central Europe that took place in Hamburg in 2013.


This was a really well organised (by it-agile) event. Location, food, wi-fi, extra activities were all first rate. It was interesting to see so many people outside the core Kanban community in Germany interested in attending. In previous years I had been to the Benelux / Netherlands versions of the lean kanban conference and they were quite a bit smaller. It was actually kind of weird, but also kind of nice, to see so many people I did not know attending a lean Kanban conference. Could the Kanban Method be crossing the chasm? I hope so, because I really believe in the approach, and hope to work intensively with it in the future.

The top 3 highlights for me were:

The last conference I attended in 2013 was the Agile Cologne 2013 Open Space.

Agile Cologne Original Logo v1 1

I first attended 2 Kanban oriented sessions. The first one was quite interesting, the main theme ended up being clearing up misconceptions about what Kanban is itself. It seems most people thought it was a Scrum-like process for maintenance etc. The idea of it being evolutionary improvement tool was foreign for many people. I think this might have been the session where I decided to stop “correcting” people who have this other view about what Kanban is. It is starting to feel a bit like the emperor’s new clothes when the thought leaders are insisting on one view of what Kanban is, yet the actual community of people out there using it are discovering that to them, jt is something quite different? Which group is correct depends on whether we define words according to a descriptive or prescriptive approach. I have now managed to develop a wider model of what Kanban is in my head, and am more accepting of people using it as a flow-based development or maintenance process rather than an evolutionary change tool. I find it increasingly important to distinguish both approaches, i.e. “Kanban” which could mean a lot of things, and “The Kanban Method”, which really does refer to the evolutionary change approach. I still feel like a bit of a dick when people ask me what Kanban is, and I have to weasily answer it like “Well to me it refers to The Kanban Method, which is ….. however most people use the term to refer to their development or maintenance process which features some or more of …..”. Anyway. The second session was comparing Lean, Agile, Scrum and Kanban, We tried to identify where the overlaps were, and which ideas borrow from with other ones etc. It was a much better discussion the the typical Kanban vs Scrum comparison. The small group actually understood the differences better than usual.

The third session was one I attempted to moderate, based on the topic of #NoEstimates. I thought I did a fairly poor job. I found it especially challenging to introduce the topic, do most of the talking, facilitate the discussion, and write things up on the flip chart. In the future I will concentrate on doing just one of these activities. The fourth topic was supposed to be about different ways of pricing software development I think, and I thought I might be able to contribute quite a bit, but the group seemed to be stuck on the aspects of German contract law relevant for services providers engaged in hybrid projects, or projects that are presented to the customer as waterfall projects, but are developed internally with Scrum. This is fair, because this is what most German service providers are concerned with, but I found it boring. If you aren’t prepared to think outside the box, if you aren’t prepared to move beyond hybrid projects, or move beyond fixed price (which can work) or T&M (which is poisonous for knowledge work) projects, or move beyond the old German “Service Contract”s or “Work Contract”s, then of course your options are limited. I know the classic argument is something like “but our customers are only prepared to work in this way”, then I don’t know why you are looking for alternatives. Alternatives exist, but you have already declared your customers won’t accept them so in your case it is easy, you have to work according to how the customer demands! But for those of us lucky enough to have customers that have also had problems with classical approaches in the past and are also looking for working in a better way,  then there are plenty of really effective ways to control and manage risks, and avoid disappointment, misunderstanding and hidden costs. My secret is basically to stop looking for “Agile contracts”, that path only cycles back to where you are now. Look instead for end-to-end agility, radically different pricing models, and THEN write up a suitable contract, or maybe you will discover that contracts are not even always required, or at least they might start to have a different purpose other than declaring what to do when things go wrong. Sounds radical doesn’t it, but the agile community actually used to be radical. 

Anyway, I doubt I will be attending as many conferences in the future as I have in the past, the ROI is starting to seem noticeably less than it used to be. I will be attending the Frankfurter Entwicklertag next week, where Bob Martin will be delivering the keynote. I was lucky enough to win a free ticket to that thanks to Andrena who held a draw at the christmas meet up of the Agile Rhein-Main user group. So big thanks to Andrena for the ticket! I will try and be disciplined enough to write a blog post about the event soon after it.

Apart from that, I don’t plan to attend any conferences this year except when I can speak about something I have actually done that will be interesting for the community. I don’t want to talk about untested theory anymore, and I don’t think the community wants to hear about it either. Hopefully I will be lucky enough to work with some genuinely interesting ideas as part of my job and can report my findings at a conference.

June 25, 2013

Play4Agile & The Agile Coach Camp

Filed under: agile, conferences, kanban — Tags: , , , — Kurt Häusler @ 4:32 pm


In February this year I attended the Play4Agile unconference for the first time, and more recently I attended the German Agile Coach Camp for the second time.


As it was a while ago now, I will just cover a few brief highlights:

  • We made a stop motion movie with Lego Duplo. 
  • Some people had a blindfolded snow-fight. There is a longer video available here.
  • We had a nice walk.
  • We got a little bag of lego. I believe it was one of the bags in the 2000409-1: Window Exploration Bag

I also remember having a nice chat about the ALE network and conference. However I missed out on doing any actual Lego related activities (such as experiencing Lego Serious Play or using it for rapid prototyping), meditating, and helping develop the Kanban pizza game. I think there was just too much going on in the bar. Even at unconferences there is still a lot of learning going on between the organised sessions. Oh well there is always next year.

Here are some other reports:

  • Bruce wrote about it on his blog.
  • Pete wrote about a game he played there related to Kanban metrics.
  • And I am not the only one just getting around to it 4 months later. Sven uploaded some photos a few days ago.


Agilecoachcamp 3 182px

Earlier this month a very similar crowd met at the same location for the Agile Coach Camp DE 2013. The first session I attended was about changing organisational culture, but ended up being a discussion about the Schneider Model, which I am not the biggest fan of. One of the better sessions was the double session about Temenos. It seems like a fascinating tool to try out at work, but I don’t really feel qualified to attempt to do so just yet. I think it has significant power, and could go very wrong if facilitated by an inexperienced facilitator.

Coaching NVC was a refresher about Non-Violent Communication, as well as a way it could be used as  coaching: 


We played an interesting game with avatars, and how we can have a bit more safety when playing the perfection game by using archetypes as placeholders for our actual selves. We had some interesting chats about the Big-A Agenda, and self-organisation. The following day we did a quick scan through the book Liftoff, we organised a coaching exchange network. They created a google plus community, but as I understand it is also intended to create a Xing group. 



December 6, 2012

Lean Kanban Netherlands 2012

Filed under: conferences, kanban, lean — Tags: , , — Kurt Häusler @ 5:59 am

Over a month later, I am finally getting around to blogging about this great conference I not only attended, but spoke at. Apart from open spaces, and leading semi-prepared informal discussions at user groups and stampedes, it was my first time presenting at a conference.

David Anderson‘s keynote was of course very interesting. I found his idea of a second, or multiple, committal points interesting, and the idea that the lead time should stop at the first non-WIP-limited queue or buffer (and presumably start again from the next WIP-limited queue or buffer). I am not convinced on that last point. I think even if a buffer should be non-WIP-limited because it is under the control of an external stakeholder, it could still make sense to include time spent there in the lead time, if you are using it to predict how long things might take. Why not just take both lead times I guess. 

He also mentioned that the cost of delay was perhaps more useful at the portfolio level than the user story level, expressed some interesting opinions about calculating business value, and combining that with strange cost estimates, which is how a lot of product owners etc currently spend a lot of time. An alternative could be to focus on risk. Capacity-constrained people should never work on optional things like estimation as it brings the whole team capacity down, only those with slack capacity should do such things. The bulk of his talk was about liquidity which is something I need to spend a lot more time looking into. He presented some interesting metrics such as “pull transactions” per person, or per unit of money.

Another interesting session on the first day was Ralf Kruse‘s Kanban Pizza Game. It was good to do something a little bit physical after sitting in a chair watching others talk.

Laurens Bonnema gave an interesting talk that appealed to me, because talked a lot about the more subversive aspects of culture hacking. There were a lot of good tips for being an effective change agent, and not the usual types of tips one reads either.

The evening meal was pretty classy. Lots of little courses, very delicious. It was a great location too by the way: De Fabrique

The next morning I realised I drank too much at dinner the night before and was worried I wouldn’t survive my talk. I found Don Reinertsen‘s keynote a little heavy going. Lots of graphs and maths and I had trouble relating it back to the concrete experience of helping a team develop software. Someone else mentioned he should try story-telling. Then I gave my talk. I think it went well, but there was a minor technical hitch. The screen-saver kept kicking in,and the main presentation display kept working but my secondary display with the timer went dark. So I lost track of time and had to really rush through the last bit. I still went a few minutes over time. My hangover wasn’t an issue. Once I was standing up and moving around and talking it kind of went away.

You can see the slides here:

Deep Kanban – a biased and opinionated participant in the path towards synergy from Kurt Häusler

After that Jasper Sonnevelt and Sarah Reeder made us dance. I saw Arne Roock‘s nice looking presentation about creating a Kaizen culture. The last session I attended was probably my favorite. My “classmate” from my MSc program, Steve Tendon, presented a very informative presentation about the Theory of Constraints, with really great looking slides. Steve should really present at conferences more often!

On the last evening a few of us joined up with the local Theory of Constraints community and went out to dinner. We went to the Oudaen where we had the surprise menu, but it was also a very classy dinner with lots of little courses.

Over all I really enjoyed this conference. I am starting to get to know a few people now, and actually look forward to catching up with them as much as the actual content. 2012 was a fairly quiet year for conferences, but I will definitely have to look at not only attending but talking at more conferences in 2013. I already have one unconference on my plan. Play4Agile in February.

May 16, 2012

Scrum, Kanban, The Marshall Model, Rightshifting, The Synergistic Mindset & Stoos

Over 10 years as a software developer has taught me that investing in technical skill can only get you so far. In fact once I got to the “average agile developer” stage, further investment in acquiring advanced technical skills was generally waste. Despite agile leaders emphasizing the importance of technical excellence, despite the software craftsmanship movement desiring to see the bar raised rather than lowered, most companies are still making decisions based on the assumption that it is too hard to hire technical excellence, or that you can get more done with a larger number of lesser developers, with a lowered bar. Essentially they are quite openly and explicitly rejecting the premises of the Agile Manifesto, and Software Craftsmanship, in favor of the old Taylorist split between thinking and doing. Even places partially embracing certain Agile practices! It got to the point where management had no interest allowing the use of idea A, or technology B, or practice C, because “no one else knows how to do it” or “yeah but our tool vendor doesn’t support that”, or “I have never heard of that”, or “its hard enough hiring as it is, without restricting ourselves to applicants who know that as well”.

It has been very clear to me, that the issues impeding effective software development are mostly related to the management culture. Even at the technical level, decisions are made that prevent, or make difficult, the adoption of advanced technical practices.

Scrum goes a long way towards improving this situation. It is based on some ideas that really challenge the, what I call, Command & Control, or Taylorist mindset. To a certain extent at least. The concept of having a ScrumMaster as servant leader, facilitating self-organisation, and encouraging inspect and adapt, can really go a long way towards liberating team members from a demotivating work-life, and permitting them a larger degree of freedom to make at least technical decisions themselves. Unfortunately it is usually restricted to the team. The same wall that Scrum builds to protect the team from external influences, also prevents such radical ideas from escaping into the wider organization. The vision of ScrumMasters as organizational change agents, stepping outside the development departments, waving the Agile Manifesto around, explaining to sales and marketing experts that there is a better way, doesn’t seem to have had much effect. Particularly in organizations where software is not the main product, or only part of the product. Scrum works by making problems visible. However it is a fairly focused magnifying glass, only providing visibility to one little link in the value chain. The solutions too, are usually fairly specific, with limits on who can participate in the improvement process, and the optimizations can only be local. Typically a problem causes a decrease in velocity. Someone might get less of a feature on a certain date, or might get their whole feature a month or so later than expected. In the overall scheme of things, Scrum does a great job of shielding team-level problems from the wider organization, and shielding organizational problems from the team.

Kanban, when applied properly, across an entire value stream, does a better job of making team-level problems and organizational problems the same thing. Scrum is fairly mild when a problem occurs. Velocity goes down a bit, big deal. When a WIP limit is hit in Kanban, all of a sudden you can have an entire team either standing around doing nothing, or knocking on the doors of a completely different department offering to help. When problems occur in a (proper) Kanban system, the effects are much more radical than in Scrum. (Of course it is possible to do Kanban inside a walled garden, in a Scrum-like fashion, and not see such radical effects.) This is a good thing. All of a sudden you have a lot more people interested in the problem, and participating in finding an urgent solution. All of a sudden you have people talking with each other, that might not have previously communicated much. It sends shockwaves up and down the value stream, ideally affecting even the customer. In Scrum, it is too easy to say yes to customers. Write another story, and stick in the backlog for later. With Kanban your capability is staring you in the face. You are forced to negotiate with the customers. You are compelled to insist that they review, accept or deploy finished work (and free up WIP) before they can request any more changes. In the best case, your sales people have to face the exciting opportunity of helping to shorten lead times, by saying a simple “no” to customers! “No, sorry, our system is full, we can’t do that for you, but lets look at what we can do, and when”.

But Kanban is still not enough. If you start off with the typical Taylorist, Command & Control, low trust culture, perhaps with a bit of Scrum in the development departments, and simply throw Kanban in the mix,  you will very likely make things worse. You will have a system for evolutionary change all right, but in what direction? Chances are the dysfunctional management culture will use the Kanban change mechanism to extinguish what little spark of agility did exist in the Scrum teams. Kanban, like Scrum, is great at identifying problems, but leaves the solution space fairly open. An unprepared management system, combined with the radical nature of the Kanban change management tool, will result in certain types of decisions being reached that will have far reaching, permanent negative consequences for motivation, lead time, costs, quality, ability to react to urgent situations, relationships with customers, overall level of learning for individuals and the organization as a whole, and relationships within the organization. The Kanban community intended Kanban to be used to make things better, but the typical organization will end up using it as a weapon against itself!

In fact I have observed the following occur:

  • Cards spend much longer in the “development” column than in the “analysis” and “test” columns, so management assumes “development” is too slow, and requires more detailed time tracking, and imposes fixed budgets per item adding pressure to developers to work faster
  • In a retrospective normal workers identify the potential communications benefit from cross functional teams (perhaps oriented on subdomains), asks management (who were too busy to attend) to implement it, management decides to implement teams specializing in technical layers (DB team, GUI team etc)
  • Actual measured lead times look unattractive to customers, so management decides to ignore them and continue to promise delivery dates based on wishful thinking
  • Management felt the transaction costs associated with user stories were too great in almost all aspects of the system (but great in development), so standardized on mini-projects as the main entity “flowing” through the system, lengthening the time it takes for developers to get feedback, and increasing the potential for waste, significantly
  • Defining slack as “preparing for (i.e. starting without pulling) the next item to be worked on”. Stating quite openly “we don’t trust consultants to write tests” and basically laughing at the idea of allowing developers to be involved in customer-facing aspects of the process. “They might say something that conflicts with what is written in the contract, or make it sound cheaper than what we charged!”

and much more… The pattern was clear. Normal employees didn’t trust themselves to help improve aspects of the process that lie partially outside their area. Management didn’t trust normal employees to make decisions, and didn’t accept allowing them to be involved in the implementation of improvements.

Management were just making the same decisions, based on the same mindset that they always did. Kanban forced these decisions to be made quicker, and under the pressure of more urgency. Motivation and relationships deteriorated significantly. Management openly rejected the idea of moving to a high-trust culture, claiming it was never discussed as part of Kanban, or a goal of Kanban. Kanban was supposed to make the software get developed faster and better, reduced lead times right? No one mentioned anything about we managers having to change anything, or anything about culture at all, so we will continue to work how we please, and “you” will use Kanban to get things done quicker.

But this is all fair enough. They were correct. You can’t blame them for thinking like that, as that is how Kanban was “sold” to them. We had 2 initial workshops with well known consultants at the beginning. We discussed our goals. I was the only who mentioned cultural advantages, like:

  • Having our development department and project department working closer together according to the same (ideally agile-like) mindset, rather than having one department working according to a waterfall like process, and another one working (at least to a certain level) according to Agile values
  • Increasing motivation by allowing people too not only see how their work fits into a wider value stream, but allowing them to actually get involved in other aspects of it
  • Enabling and encouraging employees to take on more of the collaborative decision making process, at the level of actual work (e.g. standing together at the board discussing what to pull based on business value etc), and in improving the process itself.

Everyone looked at me like I was from outer space. I think we settled on things like shorter lead times, reduced costs, and better quality as the goals.

I seem to remember going over the first 4 core properties of Kanban, and skipping over the 5th. I also remember being concerned about focussing on the use of Kanban as a static tool, moving cards around the board etc, and I actually asked if we were also going to discuss about what sorts of actual changes we could expect, how they might come about, and whether Kanban can truly stand alone as a useful tool, or would we be better off looking at it as if it were part of some more fundamental effort to improve the management system. I was told the focus would be just on Kanban, and we would not be addressing those points. Even then I had concerns about what this would do to our organization. But you can’t blame the external consultants either. They didn’t know us, they didn’t know what challenges we might face, or how our culture would react with Kanban. They were also under commercial pressure to deliver something that would be accepted by those making the decisions and paying the bills. If they turned up to the boss and said “yeah Kanban is great, it will completely turn the organization upside down. Problems will smack you in the face and force you to confront them and come up with solutions over night. Normal employees will have to be trusted with decision making, management will have to step back and remove impediments, and focus on improving the system according to the ideas of Deming, Ohno, Goldratt and others, forget about detailed project plans, that wont work anymore. Forget about your strongly batch oriented process that you push work into without considering the system capability, Kanban will exert strong pressure to change to a flow based process, and you will have to start saying no to customers to avoid stressing the system, compromising quality and demotivating employees. Oh and you will have to trust the employees more too”. The boss would have said, “I thought Kanban was a cooler type of Scrum, and change was optional and evolutionary. There is no way I want to pay you to deliver that kind of disruption”. Nope. The consultants shrewdly identified what our culture would accept. I think I remember the old “Kanban can be introduced in any culture, and a high-trust culture will simply emerge” line.

What was missing? Kanban can’t be applied to an entire value stream in a low-trust culture on its own. Maybe the consultants didn’t know that, maybe they did. Without paying some attention to issues of culture, and the management system, in addition to applying the mechanical aspects of Kanban, you are severely limiting your chances of success.

Rightshifting is one approach that should always be mentioned as the context in which Kanban can be used to improve the effectiveness of an organization. There are other ideas. Some are fairly old ideas, a little abstract, like Deming’s System of Profound Knowledge. Or more detailed and concrete approaches like Beyond Budgeting. I feel like Rightshifting, and the Marshall Model of Organizational Evolution hit that sweet spot as ideal companions to the tool of Kanban. I won’t try and interpret or regurgitate things here, instead I will urge you to go look at the original material on the topic. In fact I am a beginner myself when it comes to understanding and appreciating the power and utility of these ideas. I have heard about them a while ago, and been only loosely following them since. But recently I have come to think about things and realize I need to pay more attention to what is happening in this area. I think I heard once that you can’t change culture, all you can do is change the management system, and the culture will follow. I interpreted this to mean, it doesn’t make sense to pay attention to things like culture directly, and I lumped mindset into this too. Instead we should simply pay attention to the management system, e.g. things like Kanban, and culture will hopefully follow. There was one thing that didn’t occur to me though. You can change the way you think! The mindset is not part of the not-directly-changeable culture, but it is a basic part of the very-much-changeable management system. Seems obvious, but it really freed me up to pay more attention to a wider set of dials that can be adjusted in the organizational context. The other thing was, and I kind of hinted at this above regarding the futility of a ScrumMaster waving around the Agile Manifesto in the sales and marketing department, and I also experienced it when talking to managers about the direction we wanted to let Kanban take us in (I said we wanted to go in an “Agile” direction, but the managers saw that as being a very software development thing of little relevance to them, who were managers involved in creating products in a domain where software was just a part). I desperately needed a way to communicate where I thought Kanban should take an entire organization, independently of software development. I needed something that addressed the mindset that I guess “Agile” is a software specific realization of. The Synergistic Mindset was exactly what I was looking for, and it can be directly addressed as a new way of thinking. From now on I don’t think I can responsibly talk to teams or organizations about Kanban, without first framing it in the larger context of improving effectiveness by addressing necessary changes in the way we think with the help of the Marshal Model. I think it is exactly the type of model they had in mind when formulating the 5th core property of the Kanban method: “Improve Collaboratively (using models & the scientific method)

So. How do we learn more about this, and other similar ideas? By getting involved with the Stoos community and attending Stoos conferences. They won’t just be discussing rightshifting, but also things like Beyond Budgeting, Radical Management, Complexity Thinking, Servant Leadership, Management 3.0, you name it. Pure gold for anyone expecting to actually take on Kanban the way it is intended, and expect significant positive results, particularly in an “unprepared” cultural environment.

The main central point for the Stoos community is the LinkedIn group: http://www.linkedin.com/groups/Stoos-Network-4243114

There is also a main site that explains what it is about reasonably well: http://www.stoosnetwork.org/

There is a small get together here in Germany soon, the StoosXChange (I will not be attending this one though): http://stoosxchange.org/tiki-index.php

I will attend the Stoos Stampede in Amsterdam: http://www.stoosnetwork.org/stoos-stampede-amsterdam/

In fact as a manager one of the main parts of your role in the future, as well as designing systems and removing impediments, will be attending events like these. There won’t be too much in the way of concrete “best practices”, as everything is context dependent. You wont be concerned with detailed project plans, or allocating “resources”, or controlling costs. You will be engaging in a community of like-minded professionals, gathering a toolkit (or more accurately a valuekit, or principlekit) of diverse types of ideas, and learning how to experiment yourself, in collaboration with other participants of the system you work in, and coming up with your own tools.

And the world will be a better place for it.

November 22, 2011

Three Conferences

Filed under: agile, conferences, kanban, lean, Software Craftsmanship — Tags: , , — Kurt Häusler @ 4:21 pm

Earlier this year I went to three conferences and I never got around to blogging about them as I was pretty busy with a lot of things like finding a new job, finding a new flat, preparing to move, preparing for a new baby, finishing my masters and organizing the code retreat.


The first of the three was SoCraTes 2011 from the 1st to the 3rd of September. The name comes from Software Craftsmanship and Testing, which is an interesting combination. I suspect a few people who would have otherwise been interested in the Software Craftsmanship aspects were turned off by the Testing part. SoCraTes was definitely about the union of those two topics rather than the intersection. It was English speaking too, and great to have some visitors from outside Germany. I even did a lightening talk, where I mentioned that I would be giving all my books away. That’s right, I brought a box full of books and let people help themselves to them.

SoCraTes had an interesting way of scheduling the sessions. Each session was either a big one split into a 30 minute introduction and a hour long in-depth section, while other sessions were just hour long sessions. I tended to move between them a lot. For example on the first day I attended the first 30 minute intro to the Craftsmen Coding Contest, then moved to the in-depth part of the Specification by Example session. Unfortunately I didn’t feel like the second part of specification by example, where they wanted to discuss examples, worked very well without being there for the first 30 minute introduction. I remember going outside to enjoy the great weather and joining another spontaneous, unplanned session happening out there.

After that I saw the first part of Soft Skill Essentials, then went to the Scala Test in-depth session. After lunch I went to the Crafting Object-Oriented Code session. This was one of my favorites. In partners we had to develop a small program according to provided requirements, but we also had to follow a rather extreme set of object oriented, clean code type rules. You might not want to be so strict all the time, but it is a great and fun exercise to help show how these clean code guidelines actually work, by doing them on in an extreme way, on a fairly small simple, easy to understand code base, you can really see what effects these rules lead to.

Later in the afternoon I went to another practical, hands-on session, SOLID for Dynamic and Functional Languages. We split into teams that chose a language associated with a non object-oriented paradigm. I ended up in the Clojure team, and I can’t remember what the other languages were. We were asked to look at code sections that broke a solid principle, and we had to refactor it so it obeyed the solid principle. The main idea was to discuss how aspects of dynamic and functional languages might make the solid principles either unimportant, different, or irrelevant.

The following day was Open Space. I think I attended sessions on “Laws of Software Development”, actually looking at a picture of the board, that is the only one I recognize. I do remember sessions on mentoring, developing SC communities in Germany and the others were mostly just general chats out in the sun.

The discussions on further steps to take regarding software craftsmanship in Germany were interesting. I didn’t think anyone needed to start a SC group up in the Cologne/Bonn area as we already have the Bonn Agile Meetup, and other user groups, that discuss the same topics. I was however inspired to bring the Global Day of Coderetreat to the Cologne/Bonn area though.

The date for the SoCraTes 2012 has already been set and it will take place from August the 2nd to the 4th, with an optional code retreat on the 5th!


The second of the three conferences was the Agile Lean Europe 2011 in Berlin from the 7th to the 9th of September. The whole family came to this one because there was a special spouses and children track with activities and trips organized. Now at this conference all the talks (except keynotes) were 30 minutes long, and they felt for the most part like dragged out lightening talks, or chopped down hour long talks. For me the open spaces were the highlight. I remember some great discussions on things like estimation, and whether we need managers or not. The keynotes were great too. Rachel Davies’ one on the first day was memorable for her comments on enterprise agile, which I seem to agree with. All the keynotes were fantastic. Beyond Budgeting for example is something I am really interested in getting to know more about.

The second day I had to give up a couple of sessions as I was informed I needed to do some last minute improvements to my masters. In the evening a small number of us went on a trip to catch up with the Berlin Lean Startup Group, for one of their meetings and some dinner.

I remember having a lot of thoughts about agile becoming too fluffy, and did a lightening talk about that, and there was some discussion on twitter about my views on coaching that I said I would flesh out in a blog post, but I can’t really remember what it was all about now. The last day was probably the best. I enjoyed all the talks on the Science of Kanban, Relearning Smalltalk, and the Agile Meme. On one of the days we also had a cool open space session “for programmers” with Brian Marick. You could consider it a warning sign if a session at an agile conference was notable for being “for programmers”.

Afterwards my family and I stayed in Berlin for a bit to have a look around.

The next one will be in Barcelona I believe.

Lean & Kanban 2011 Benelux

I enjoyed this one so much in 2010 I decided to go again this year. The whole family came again and we had a look around Antwerp. I won’t go through and comment on every session I attended. The highlights were probably David Anderson’s “When is Kanban not appropriate” talk, Don Reinertsen’s keynote, and the Real Options talk by Chris Matts and Olav Maassen. Would I go again next year? Sure, but there are 3 lean/Kanban conferences all happening around the same time, so maybe next year I could check out the LKCE or the LSSC ones instead.

Not many images on this post, so here is one of my daughter and I in Antwerp.:


July 9, 2011

Agile Coach Camp Germany 2011

Filed under: agile, conferences — Tags: — Kurt Häusler @ 1:20 pm

A few weeks ago I attended the Agile Coach Camp Germany 2011. I had never attended anything like it before, it was well outside my comfort zone which means I was keeping an open mind and expecting a great opportunity to grow and learn. As a software developer who is motivated by agile values and principles I couldn’t help myself slotting into the role of wannabe change agent. As someone who has spent the last few years working for companies who think developing software is mostly about sitting isolated in front of a computer for eight hours a day, my people skills have taken a dive, which naturally affects my ability to lead change, especially without formal authority, in a negative way.


The theme of the event was "the inner fire". For most people that was the passion they already had for coaching. I definitely had an inner fire too, but it had a different nature. Just as fire keeps us warm and cooks food, it also burns houses and kills people. The inner fire that was driving me to attend something like the coach camp was basically frustration. It also burns but in a different way to passion. I was frustrated at myself for letting my "people skills" slip so much, and also frustrated at the outcome, that my efforts at leading change suffered as a result.

I attended a session on balance, which I hoped would directly address one of the frustrations I had in mind the previous evening. I remain confused on many of the following, I guess knobs that can be tweaked:

  • Being a servant leader, getting out of the way and helping others achieve their vision vs asserting my own vision, and placing my own ideas above those of others.
  • Serious, professional and boring vs playful, frivolous and abstract.
  • How to express passion and excitement without coming across as a fanatic or zealot, or appearing to push an agenda, and thus putting one’s credibility into question.

The session turned out to focus on other topics such as work-life balance and that sort of thing. Still interesting but for me if work-life balance is an issue, you probably have the wrong job. I just don’t really want to separate the two that much. It would be like splitting life into boring and fun bits, why not just arrange things so you can make a living having fun instead? Olaf wrote a follow-up post on the topic here: Spotting the Balance. I may at some point write a post or two on the the particular points I mentioned above.

Then we had an interesting discussion on "The four evil root-causes from hell", which turned out to be more like symptoms than root causes. It was I believe based on the ideas mentioned in How to defend against the 10 things that drive your ScrumMaster crazy.

I then attended a session on "nonviolent communication". The first half was focused on the emotional benefits felt by the session leader. I thought it was a great way to start, once I worked out what sort of information he was trying to deliver and in what form, as I think the point of nonviolent communication seems to lie in the emotional space, rather than the more technical details of what it is, but some of the other participants had difficulty putting it into context without first knowing what non-violent communications was all about. This was however cleared up very well in the second half with practical examples supplied by session participants.

In the afternoon I helped the organizers of the upcoming SoCraTes 2011 conference go through some ideas, and formulate the Call for Contributions. Unfortunately I am far too busy wrapping up my Masters to really take part in the organization or even lead a session, but I am looking forward to attending, and it looks like there are far better sessions being planned than I could come up with anyway.

In the evening we had a few beers and attempted the Kata Potter, not very impressively. On Sunday morning I started off by "exploring my own values and mission", which was pretty introspective, almost naval gazing. It seems I value simplicity. After that I had a go at leading a session called "Leading change without authority or natural talent". I basically just collected a list of tips and ideas from the participants ans wrote them now, someone remarked later on twitter how similar it looked to the list of patterns in the "Fearless Change" book.

The last session I attended was book swashing, where we grabbed some books from the book table, and had five minutes to skim through and pick one thing to write about it, and then pass it on around the circle.

All in all a great event. I did come away with the feeling that I as a developer somehow think wrong, when it comes to dealing with people, and the coaches have a superior mindset in this regards, that we developers have to learn from, which is true to some extent, but I wonder if coaches overstate it because of the lens they are used to looking through. I think to a certain extent the coaches have something to learn from technical people as well, exactly what I am still unsure but it is worth considering.

Some other blog articles on the event are here:

November 19, 2010

JAOO (now GOTO) 2010

Filed under: conferences — Tags: — Kurt Häusler @ 9:00 am

Before I went, I had two main sessions in mind that I knew I wanted to attend. Mary Poppendieck’s and Don Reinertsen’s. Aside from that I was actually planning on attending mostly technical, programming related sessions, just to restore a bit of balance from all the attention I had been giving management topics lately. I guess some of the craftsmen that I had been conversing on twitter helped encourage me not to forget that none of this would matter without coding. However as it turned out I stayed the whole time in the “orange” track, which consisted of things like agile practices, lean management, and management in agile settings. I had a look at some of the other technical sessions and they seemed to be into two categories, an introduction to some shiny new language or library, or a more advanced look at some technology ideal for people already working with it. A lot of them were very interesting. There was a lot of NoSQL stuff there for example, which is something I have been interested in for a while now, having covered it in a presentation I gave on domain driven design at work a year ago for example. Unfortunately I am coming to realise that conferences don’t really fit into the way I discover and learn new technologies. Up until recently I was bombarded every day from blogs and twitter with introductions to new technologies, and links to tutorials. About a tenth of those I absolutely must follow up, so I used to write them down in a backlog, and a tenth of those I would actually find the time to do. I could see how in the past, and even today for many developers, conferences like JAOO are the main way that people get introduced to new technologies.


The more advanced ones would have been great, but unless there were any sessions on MFC or SQL stored procedures, I just don’t have the day to day experience to really get the most out of it. Don’t get me wrong, we have a real need at work for things like NoSQL, but the people who make the decisions to do that aren’t aware of that, so there isn’t much chance of coming to work and working on the event sourcing part of our app with mongo or couch db (what version of visual studio are they in? I don’t see them in the data explorer). But the management topics I felt, offered tips and insight that I really felt I could use at work, to address our particular pain points which are managerial rather than technical.

It reminded me of the recent debate about the lack of technical topics at Agile 2010. I am pretty convinced that, apart from some important exceptions which I will mention, conferences are not as useful for covering technical topics as they are for more abstract, theoretical, insightful topics. For example Kevlin Henney’s Craftsmanship talk wasn’t exactly a management topic, but it wasn’t exactly technical either. Going to a conference to watch a technical session where someone builds up a small app in an IDE on the big screen seems like a waste of conference session to me. I watch a screencast, or learn more by doing it myself with a tutorial. For me discovering and learning a technology goes something like this:

  1. Discover new technology: Don’t need a conference for that, a quick glance at the twitter or blog reader firehose presents me with far more technologies, tools and tutorials than I need.
  2. Learn the basics: I am probably not the only one that learns better doing it myself than watching someone else do it.
  3. Get good at something: For me this means getting a solid eight hours a day experience with something for a few weeks at least, which implies using it at work. Now it is possible to do this at home, but I am still working on being able to exhibit the focus required to do this effectively. Currently I tend to spread myself far too thin, and end up repeating steps 1 and 2, leading to a broad, but shallow knowledge of many things, none of which I am particularly good at.

Another thing I noticed was that technical conference sessions tend to be about things I have been exposed to in the blogosphere for a few months already, while management sessions tend to be new, and the topic gets blogged about later. I suspect this is due to the fact that highly technical people prefer expressing themselves better in blogs, then the professional conference speakers pick that up and present it at conferences, while the management “gurus” ARE professional authors and speakers, and present their material at conferences first, and their followers pick it up later and blog about it.

However there is one exception. Hands-on conferences. I fully intend to restore some balance in 2011, and focus on “coding” as much as I have focussed on management this year. I will take my laptop, and collaborate with others in developing some sample app, solving a kata, taking part in a dojo. The craftsmanship conferences place a strong emphasis on this, so I really hope to attend the UK craftsmanship conference in 2011. I even heard rumours that there will be one here in Germany so I will hopefully attend that one too.

Anyway, there is not much need for me to give a blow by blow detailed account of everything I saw. Most of the slides are available to download.

The best session for me was Don Reinertsen’s and the second best was Mary Poppendieck’s where I got Mary and Tom to sign my copy of Leading Lean Software Development.

Some key points:

  • The software craftsmanship manifesto is a pretty weak uninspiring piece of fluff.
  • No one really knows what software craftsmanship is.
  • We need a feedback cycle at work that allows the POs to learn to write much better acceptance criteria based on the bugs we fix, and their solutions.
  • Management is becoming a marketing job, they have to sell their vision to recruit followers rather than just directing them.
  • Lean product development is a lot different to lean manufacturing due to non-repetitive tasks, high variability, and non-homogenous flows.
  • Even 80% utilization (like in lean manufacturing) is too much for product development, considering the higher variability.
  • You don’t really have static bottle necks (due to say under-capacity) in product development, the effect is more like a elephant moving through a snake. This implies ideas like Kanban are better then TOC when it comes to product development.
  • Batch size can be optimized by finding the minimum sum of transaction and holding costs.
  • Expediting should not pre-empt (too expensive), it should only give head-of-line privilege.
  • CFDs represent a lot more information than I thought, and I absolutely need to learn more about them. e.g. the slope tells the capacity of the system.
  • Queue size can be a better metric than cycle time, as cycle time is lagging.
  • Eliminating variability is bad – variability is where we can make profits.
  • I have to read more about asymmetric payoffs and option pricing.
  • I need to read more about queuing disciplines.
  • Analysis beats intuition.
  • I should read Managing the Design Factory before I read The Principles of Product Development Flow
  • Queue Size vs. Capacity Utilization graphs sound interesting.
  • WIP limits can have units (such as story points) rather than being a simple count.
  • Teams should only be maximum half a step ahead of management or management starts to slow things down.
  • Technical debt is a business problem rather than a technical problem.
  • Managers have to drive continuous improvement.

One session I wished I attended, because everyone raved about it was the Real Options one. Hopefully I can see it on video at some point.

October 12, 2010

Lean & Kanban 2010 Europe – Day Two

Filed under: conferences, kanban, lean — Tags: — Kurt Häusler @ 7:56 am


Well I am now a whole conference behind in my blogging, so I will try and make this a lot shorter than the previous one.

Day Two started off with a keynote from David Anderson called “Creating a Limited WIP Society in your Organization”. Much of it was fairly familiar to anyone following the mailing list, and I assume to anyone who has read his latest book, which I unfortunately haven’t yet. For me there were quite a few nuggets of wisdom, and things I wasn’t aware of. Interesting was his observation that approaching lean from an angle of waste reduction is difficult as it tends to point the finger at traditional project management activities as being waste, which naturally leads to resistance from project managers. His preferred motivation for lean is encouraging an evolutionary approach to change and the emergence of lean software development behaviours, and to enable this by utilising a pull system that limits WIP, which will catalyze the other pillars of lean. He listed his seed conditions, of which most were already known to me. The interesting one for me was the use of models (such as variability, Deming’s system of profound knowledge, real options etc) to evaluate improvement opportunities. Having a toolkit of models is something I really have to look into, and something I intend to discuss on the mailing list, once I have read the book at least. It really underscores that Kanban, like Scrum, is not a software development or project management process, but a system, I guess is an acceptable word, for managing change, that relies on other ideas not pat of it. I really do see Kanban and Scrum as occupying the same place in the spectrum of ideas, with the fundamental difference being that Scrum (when done properly at least, even though the scrum guide considers the use of scrum as a fairly static tool for planning tasks within the development phase of a waterfall project as perfectly valid, I don’t even consider it scrum-but) requires radical revolutionary change, and Kanban allowing a slower more gradual change. I hope Kanban manages to avoid some of the same mistakes that the Scrum community have made, falling into the static task planning tool hole, and recent messages on the kanbandev mailing list have shown that this danger has been perceived to exist, and attempts are being made to reinforce the nature of what Kanban is, and avoid such misunderstandings. Another idea that was new to me, that I found interesting is the use of Process Control Charts. It seems like a great tool for discovering the natural, or common-cause, variability in a system, and being able distinguish it from special-cause variability. Probably the most important thing he said was that leadership is the magic ingredient. Seems obvious, but I am sure most of the time when these modern ideas like Scrum and Kanban are implemented, a consultant comes in and sets it up, at least to the extent at which people accept, and then developers focus on developing software, analysts concentrate on talking to the customers about requirements, managers revert to operating the system in a mechanical way but no-one takes a leadership role in the kaizen effort, and only a small fraction of the true potential for improvement is realized. Without a passionate change agent, who reads the books, and the mailing lists, and goes to the conferences, and actively builds up a collection of models for improvement who has some level of acceptance in the organization and some sort of authority, preferably of a “tribal” nature, but in most cases at least a minimum of official authority, then why bother? It is just going to seem like another buzzword, sold to the organization by a consultant, as a way to assist managers in commanding and controlling the workers. Anyway, I should make an effort to digress less. A good first step, according to Anderson is demand analysis, which is like what John Seddon said the previous day. Look at the types of work, their arrival rate, the expectations for delivery, the nature of the variability. After that you can begin to map and visualize the workflow. And of course, limit that WIP!

The second session I attended on day two was “A Kanban Multiverse” by Karl Scotland. It was all about better visualization, and more visual forms of communication, but he also covered some other interesting things. He started off by asking us to imagine how the battle of Britain would have gone if it were managed using a sharepoint site with a wiki and by mailing around change requests. He said visualizations can be used as augmented memory. To be honest though, and this is perhaps because I am not such a visual thinker, I felt a lot of what he showed us reminded me of Gantt charts. I just thought how wasteful is that, why not just all sit together, and talk, and use as little tooling as possible, perhaps a task board, a CFD and a process control chart. I see visualization as being a bit like documentation. Sure, do as much as required, but no more, after that you are being wasteful. But my mind could be changed on that. He talked about boundary objects, and how they represent something that is interpreted by different roles in different ways, that visualizations are one example of boundary objects, but so are acceptance tests, according to Brian Marick. Then he started talking a bit about Dan Pink’s ideas on motivation. He linked the Purpose aspect of motivation to visualization by saying that that is how teams can see where they fit into the value stream. He talked about chart junk, and mentioned a few other things that I made a note of to read more about such as Story Mapping, “Yes with Consequences” and the work of Tom Wujec.

The third session was “Seeing What Matters – Using the right vision to manage transition” by Alan Shalloway. It was a fairly densely packed talk, so I won’t give a point by point rundown here, particularly as it was a few days ago now. He talked about Pareto curves, and finding the right balance between new projects and improving old ones. He went into some nice detail on value stream mapping, and working out the process cycle efficiency etc, most of which wasn’t that new to me. He talked about not just getting better at what we do, but eliminating delays between the things we do. He said the Kanban board should replace the initial VSM as there is no point in maintaining two versions of the same thing. This was interesting, as I always see VSMs with things like “prioritise initial objectives”, “get funding” and “submit quote to client”, yet the Kanban boards I always see are more like “Selected”, “In Development” and “Testing”. I think Kanban (and Scrum for that matter, why not?) boards in general should visualize a much wider scope than they typically do now, particularly they should address the upstream business and customer related activities as being part of the process as the same level as the technical activities. He talked about the relationship between queues and delays, visualizing the feedback cycles, and he discussed some anti-patterns, like component, or layer, teams. He suggested looking at whether the team understands why they do what they do. Can they link the tasks they do back to the business objectives? Can the manager link the business goals to the tasks that the developers do? And lastly he talked about using silver cards to expedite, and making it a business decision, with consequences.

After that we had an “open space” track, it didn’t seem that well organized as an open space thing, or at least the participants didn’t seem to embrace the concept. Most people wanted to play the Get Kanban game, and the Dot Game. The Get Kanban game was fun. My job was to maintain the CFD and process control charts, unfortunately this meant I didn’t perceive what was going on in the actual Kanban bit itself as well as if I had another role like manager, tester or developer. But it was still a great experience to take part in. I didn’t play the Dot Game but I observed. The main point is in observing how a system based on single piece flow, pull, tight feedback, optimizing the whole and swarming is superior to one based on batching, pushing, and local optimization. They do this by building up a card with coloured stickers on it according to a pattern specified by a template. Particularly interesting is how, without being told, people naturally communicated when using the lean approach, but were too busy to communicate when using the traditional approach. And of course, the throughput and error rate were much better when using the lean approach.

The closing keynote, from David Joyce, was an excellent finish to the conference. He really brought it all together and related it to his practical experience at the BBC. He drew heavily on Systems Thinking, and the ideas of Ohno and Deming to present a view of lean different to what I was familiar with, as well as a summary of the ideas presented in other sessions. One new idea that I found interesting was that of Double Loop Learning. It is actually something that I had approached in my own thoughts myself when thinking of how principles and values can be used as a decision making rather than far off goals, so I will definitely be interested in looking further at that.

Anyway, that will do for now. In the meantime I have been to another conference, so I will try to blog about that in the next few days.

Blog at WordPress.com.

%d bloggers like this: