Kurt's Blog

May 11, 2013

The Limited WIP Society Rhein-Main

Filed under: agile, kanban, lean — Tags: , , — Kurt Häusler @ 4:33 pm

I just wanted to write a short note to inform any interested readers that I am in the process of setting up a Limited WIP Society in the Rhein-Main region (the region around Frankfurt). A Limited WIP Society is a user group mostly for those interested in David Anderson’s Kanban method for supporting evolutionary change in your knowledge work and product development processes and systems.

Go Lean Limit WIP

Some of the other topics relevant for a Limited WIP Society include:

  • Flow-based product development
  • The Theory of Constraints
  • Lean Systems
  • Systems and Complexity Thinking
  • Modern management methods in general

I have set up a Xing group that as of writing already has 21 members, and I have planned the first meetup which will be an informal gathering at a restaurant later this month. If you are interested in any of the topics mentioned above then please come along. I hope to see enough interest in organizing a regular meetup. Ideally in a location more suited to other formats like the lean coffee format or talks.

Yes We Kanban

The first meetup will be somewhat casual, focussing on getting to know each other, sharing our experiences and tips, and making plans for future events.

You join the Limited WIP Society Rhein-Main here: Limited WIP Society Rhein-Main Xing group

You can register for the first meetup here: First meetup of the Limited Society Rhein-Main

Vote Ltd WIP

Here are some other interesting links:

Advocate Ltd WIP

Thanks for reading, and I hope to see you at the next meetup!


May 4, 2013

Agile Business Thinking

Filed under: agile, rightshifting, scrum, stoos — Tags: , , — Kurt Häusler @ 7:06 am

So I went along to a new event yesterday. Apparently the Agile community have taken a bold new step and finally written a new manifesto to address agility outside of software development. Essentially this could be the most significant thing to occur in the history of the workplace since Frederick Taylor invented Scientific Management. (One could perhaps consider the original Agile Manifesto if the scope wasn’t restricted to software development). After years of false starts and dead ends from Deming to Stoos, could this finally be the beginning of the end of command & control in the workplace?

The event I attended yesterday was called Darmstadt SPIN, a forum and network for “Vordenker” (which Leo translates as mastermind, mentor or prophet). They meet regularly to discuss various topics. Yesterday was my first time there so I don’t know what the usual topics are or what sort of people attend. There were actually a lot of newbies like me there yesterday.

We started off with an introduction to the new Agile Business Thinking Manifesto. I tried to find an english version but couldn’t, so here is a lazy Google translation of it:

Manifesto for Business in a New Century

We develop better ways organisations to lead by doing it yourself and help others to do the same. Thus we have learned to appreciate the following values:

We value personal responsibility and self-organisation 
more than hierarchical control.

We believe that personal responsibility, self-organisation and agile teamwork enable organisations to deliver higher performance. As a result, employees find more meaning in their work.


We appreciate interdisciplinary and efficient team structures 
more than labor.

We believe that interdisciplinary collaboration and innovation capacity and allows more employees bring their personal strengths.


We appreciate growing organisational knowledge 
More than individual expertise.

We believe that collective learning and action strengthens the organisational success and employee capable of personal development.


We value partnership 
more than formal customer-supplier relationships.

We believe that a partnership creates added value for customers and employees to connect to the customer’s wishes.


We value responsiveness and agility 
more than stability and continuity.

We believe that an agile and responsive organisation better use of opportunities in the market and its employees empowered to change themselves and their businesses.


We are convinced that the above values of a powerful organisation and employee satisfaction are important.


Why a manifesto? The point is to formulate a compelling and emotionally provocative promise that forms the staple of the “followers”. The aim of the manifesto is to bring about a “Yeah, right” reaction in the reader.


Why values in a manifesto? Agile enterprise management is to control and align a set of interconnected values that organise the behaviour and culture of organisations and the individuals in them.

I hope it is ok to post a translation here like this. I didn’t see any copyright or license information, so just let me know if it should be taken down. One bit I didn’t past in was, due to formatting, this note:

All values in this set are important to us. We estimate the values in the first row as more important than those in the second line. 
(This applies to all 5 pairs of values)

They actually indicate that e.g. “hierarchical control” is important.

The only other thing on the page is a link to the Xing group, where we can get a clue as to who is behind this manifesto (two consulting companies) and how old it might be (the Xing group was created in April 2011). 

When i read this manifesto I am reminded of  a critique I once heard of the software craftsmanship manifesto. To me a manifesto should send tingles up one’s spine and make one’s blood curl. They should passionately and almost violently challenge the status quo, and present a serious threat to our fundamental beliefs. My reaction to this manifesto is a little different. To me it reads more like a cautious compromise between the status quo and common sense. Where is the rage? Where is the earnest plea? Where is sense that someone is putting it all on the line for the sake of a better future?  I find it decidedly not emotionally compelling.

And hierarchical control is still important? Cmon! In the age of betacodex, rightshifting and Stoos, this reads exactly like what it is. An advertisement for German consultants that don’t want to appear too radical so they can still peddle their wares to senior management mostly concerned with preserving their place in the analytic machines they think they drive.

Anyway, back to the event. After being introduced to the manifesto we heard a case study that we were then to use as a basis for discussion on how to apply this manifesto to the problems mentioned in the case study. I had expected to hear about an actual case of organisational change or at least an attempt to “agilize” something not related to software development. Unfortunately the case study was about a software development project that used Scrum for a year or so before giving up on it. There was very little about the business or organisational context. As a result, the discussions sounded exactly like every other discussion about agile software development over the last decade. Most people were focussed on the idea that the goal was for this single team to do Scrum properly, all the suggestions were too focussed on the team and anchored in the language of software development and Scrum. To really get a feel for how this manifesto could be relevant for actual business thinking, they should have focussed on a case study that had nothing to do with software development, and focussed more on the business and organisational issues.

I found it frustrating. Also the discussions felt a lot like ineffective meetings at work, where everyone knows they will only get a sentence in before getting interrupted so everyone is rushing, complicated ideas cannot be introduced, and the loudest voices dominate. It would have been a lot more productive in written form on twitter or via mailing list.

I did note that the Darmstadt SPIN will be meeting again in September, and that Agile Business Thinking will be on the agenda again as it has been selected as their topic of the year. I thought the Stoos community really has to get involved as they seem a few steps ahead. Then I noticed that Darmstadt SPIN itself is also organised and sponsored by the same two consulting companies that are as far as I know, behind the manifesto. It would make sesne to me for everyone with goals in this area to work tgether a bit, and see what others are doing, rather than reinventing their own ecosystems to address the issues alone. (A quick glance at some of the names associated with the manifesto indicates mostly people who I have not yet seen engaging with the wider community on the issue).

Anyway, what are your thoughts? Have we finally produced an artefact that can guide us towards a noble future of business agility? Or is this just another attempt, and a weak one at that, for agile software development consultants to add something to their portfolio? Do you have a favourite collection of values or principles that attempt to achieve a similar goal, yet do provoke an emotional response?

February 5, 2013

My Reading Strategy

Filed under: Uncategorized — Tags: , — Kurt Häusler @ 2:02 pm

I enjoy reading but, I find it difficult to make time to read. There is usually some other thing I find to do instead. I have found that reading in bed in the evenings doesn’t really work. I just don’t take things in as I am falling asleep. About the only time I get to read is when I have to spend a bit of time travelling on a train or something.

Last year I choose my books based on the list of required reading for the PMI-ACP certification. It began slow (as I wasn’t spending as much time on trains), but in the last few months I was able to churn through the books, spending a couple of hours on a train each day.

I was planning on allowing Amazon’s recommendations help me decide but since I read so much on the topic last year, I am sick of the “agile-management” related genre of books, so I decided to concentrate on some more technical books.

The problem with technical books though, is that it makes a lot more sense to read them in front of the computer rather than on the train.

So I am making the radical decision of reading 2 books at once. One technical book for at home, and something else for the train.

But what topic though? Well there are a lot of topics that aren’t quite technical, they aren’t quite domain-related, and they aren’t about process. Things that my current employer might find useful for managers like me to know about: business intelligence, social media, innovation, competition, the market, cloud computing, data warehousing etc., but all from a business rather than technical perspective. Who knows, maybe I will find something interesting… I started reading a book on data warehousing but I am finding it pretty dry and they way the author keeps calling people “resources” is distracting.

Got any suggestions?

January 9, 2013

Retrospective 2012

Filed under: Uncategorized — Kurt Häusler @ 10:46 am

So this will just be a short note to let you know what happened last year and how I felt about it.

We started the year off in a new city and with a new job. I had already spent the previous 6 months doing something other than being a software developer, internal Kanban coaching and process improvement, but at the beginning of 2012 I became a consultant at a company claiming “The Agile Organization” as one of its areas of core competency. After a slow month settling in I was sent off as a part of a team to my first client, where my job was to help improve their Scrum process. The Scrum process was already pretty good though. I was able to make a couple of suggestions which were readily accepted, but there wasn’t a lot to do there full time for 4 days per week. I started to notice some other issues at the technical and management level, which were actually connected, but they were either hard for an external consultant to directly fix or outside my mandate.

I ended up feeling a bit bad about being there counting billable hours that I felt were out of proportion to the amount of value I was providing and convinced my boss I should probably finish up and leave the team to get on with it.

And that was basically it. Month after month I was sitting at home (turning up to the headquarters on Fridays) waiting for another customer, only collecting 70% of my salary.

Now this job had a variable salary. I was guaranteed 70% each month, but the other 30% were based on billable hours. At the beginning it was explained to me that it should be no problem working enough billable hours to make the full 100% and the idea behind the variable salary was that in previous years people had worked so much that they had no time to write articles and attend conferences etc., and that the variable salary means people can choose not to take on a client project and still get a reduced salary. It was not explained to me as a system for allowing the company to save money in case the projects dried up, while still keeping me hanging on so they can assign someone to work in short notice without having to recruit.

Now you have to understand that in Germany you get a generous unemployment insurance of 70% of your last salary anyway, so it became clear to me that variable salary is of no benefit to the employee, and only benefits the employer. Basically you are unemployed, receive the same amount of money as if you were unemployed, but you are not free to start work elsewhere, you have to wait out your notice period.

What I should have done was to set the base level at the 100% and enjoy anything I get from over that from billable hours as a pure bonus. Then it wouldn’t have been so bad.

As it turns out, after taxes I was getting roughly half as much as I was in the previous year and what I expected, and after things like rent and insurance came out I only had around 10% discretionary spending money than I had in the previous year and what I expected.

I had lots of free time though. Not much money but lots of free time.

But I don’t want you to think money was the main issue. I certainly reduced the number of conferences I attended in 2012 because of money, and also because I wanted to be free in case we got a client. The main issue was frustration with not doing anything.

I had developed a lot of interest and knowledge in exactly the area the company wanted to specialize in. I knew there was a lot of demand for expertise in these areas. I knew other consulting companies working in this area had more work than they had people to do it. The fact I was so extremely keen and reasonably well qualified to work in an area where there was so much demand, and it was an area my employer wanted to specialize it, it was just plain frustrating not to be able to work! I think they had problems developing a marketing strategy as there was a lot more meta-conversation about how to find customers than actual discussion about agile organizations and what it means to be one.

There was an attempt for me to write articles and presentations solving potential problems that future customers might have, but I don’t think that works so well in the agile world. I think so much is context dependent, and of course “complex” that any solutions can only come about when an actual problem exists and a mechanism to allow a solution to grow via feedback etc. I came up with a few bits and pieces but never got to try them out, so for me they remain unrefined, unvalidated, and essentially spoiled milk (which is an analogy for any work invested that expires before it gets a chance to realize value).

Anyway I made the decision before my 6 month trial period that I have to do something, so at the same time as waiting for a client via my current employer, I decided to open up a search into finding work through other channels. I noticed there was a lot of interested in me personally either as employee or freelancer, either as developer, coach or consultant, but little interest in having a team of consultants coming in selling a box with “The Agile Organization” written on it.

As it turned out the company and I had fairly different ideas about what the agile organization actually is. For me it was something larger than software development, and involved a significantly different management system and culture than what exists in the typical organization. I had imagined helping organizations realize the vision shared by people in the Rightshifting and Stoos communities. My employer was really focused on just helping companies with the way they develop software mainly by scaling Scrum, and helping with some of the issues that companies face with using agile approaches while still attempting large-scale projects with several interdependent teams without having to change too much at the cultural level, or affect the management system outside of the software development departments too much. Not that there is anything wrong with that. There is certainly demand for it, but it is something I find somewhat less interesting than enabling my vision for the future of the workplace: small teams of motivated individuals having fun delighting customers supported by leaders acting and thinking according to a synergistic or chaordic mindset, rather than merely developing software a bit faster while still being constrained by the same old analytic management culture.

But I was patient, and not under any real pressure. It would have been ideal if a client came, and I could have remained employed as a consultant, but other opportunities simply won the race, and I now have an interesting job at a company that mostly develop and maintain web sites for advertising and marketing, but not exclusively.

They have an interesting structure based on the Scrum team. They have a number of super-teams. Each headed by a Process Master (analog to a Scrum Master) and a Business Owner (analog to a Product Owner). Outside these super teams are minimal roles. Senior management, administration and office. All other functions are contained within the super-teams that enjoy a fairly high amount of autonomy. Within these super teams we have a number of roles like product owners and scrum masters, developers, engineers, information architects and the like. They are divided into cross functional project teamlets, some of which use Scrum some not. Many teams also use Kanban in various ways.

I applied for a Scrum Master job, and was offered a role as Process Master which is like a Scrum Master of Scrum Masters and has some extra management responsibilities that a Scrum Master would typically not have. I have also been working as the scrum master for one of the projects within my super-team.

So far so good. I am still getting used to many aspects of the role that are new to me.

I did attend a couple of conferences this year. Notably the Stoos Stampede, and Lean Kanban Netherlands where I also gave a talk for the first time.

After a bit of a rough start I am pretty happy with how 2012 ended and I am excited about how 2013 might look.

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.

November 1, 2012

The uncertainty implied by planning poker cards

Filed under: agile, scrum, Software Development, xp — Tags: , — Kurt Häusler @ 5:24 pm

After hearing about some experiments in using planning poker cards to come up with a estimate range rather than a single estimate, it occurred to me that planning poker cards are categories rather than accurate measurements, and so have ranges built in. I was curious about what sort of uncertainty was implied by each card. So here is a table that summarizes my findings:

Card From To Midpoint Uncertainty



















































Some decks are different with different values, but this is what I have here at the moment.

Effectively, when we play a 5, we are saying “I think it is about a 5.25±24%.

Playing a 0 expresses the most uncertainty with the estimation. 0.25±100%

Also the 1 has 50% uncertainty! You would expect the 0 and 1 cards to have the least uncertainty. Or at least you might assume that when expressed as a percentage the uncertainty should be roughly the same over all cards.

Cards 2 to 20 all have uncertainties in the 22-29% range, which seems appropriate. 40% uncertainty for the 40 card makes sense too I guess.

The 100 card is a special case. I am just assuming that 100 is the upper bound here. You could assume ∞ if you wanted, but I don’t know how to calculate the uncertainty in that case.

I guess it means we have a range built in. There is no sense playing two rounds for a separate lower and upper bound. Or perhaps taking the lowest card in each round, and the highest card in each round and adding them up.

If we are estimating a larger project we can use the midpoints and uncertainties to calculate a range if required, using normal rules for calculating uncertainties.

If we have for example 5 stories, a 1, a 2, a 3, a 20 and a 40. That adds up to 66. The lower bounds add up to 51 and the upper bounds add up to 108.

When you add them up though, the 66 is not relevant. The values on the cards were only names for categories. There is no category 66. The estimation total is actually something more like 79.5±36%

You have to be careful with planning poker cards. The number on the front is basically an arbitrary label for a category of values that fall within a range, and that label doesn’t correspond to the midpoint.

If you are adding them you should really be adding the midpoints, not the category labels, and preserving the uncertainties.

September 18, 2012

The Häusler Problem-Solution-Value Distance Model

Filed under: Uncategorized — Kurt Häusler @ 12:17 pm

I remember sketching out this simple idea a few months ago, and I have been thinking about it since then, so I decided I should blog about it. It is essentially a model for looking at the general process for identifying problems, investing work in solving them, and then applying that solution in order to realise some value. Visually it looks like this:


P is the point at which the “problem” is identified or specified. S is the point at which some work is invested in forming a solution to the problem. V is the point at which the solution can be utilised to realise some value.

The other important concept is the “distances” between P and S, and S and V, or indeed the total distance between P and V. Distance here might not just be spatial, it could also be temporal. It could even be more abstract like the distance between two people’s mindsets or value systems. Or it could be a vector quantity, with spatial, temporal and other components.

The central claims I intend to make with the model can be summarised by the following formulae:

  • distance PV ∝ waste
  • distance PV ∝ 1/quality
  • distance PV ∝ 1/motivation

That is, the longer this distance PV is, the more potential for waste, more potential for quality problems, and more potential for demotivation.

It should be interpreted from the S perspective. Some manager or knowledge worker hears some description of some problem. He or she invests some work in developing a solution for it, and hands it on to further on in the system, to be, somewhere, at some time, utilised in generating value. In the most ideal case, the distance would be 0. Point S occurs at exactly the same conceptual point as point P and point V. That is the knowledge work or manager is right there when the problem is first conceived, invests work in a solution at that same point, and the value is immediately realised.

This concept is already understood, and finds expression in many existing principles. For example the lean concepts of “going to the gemba”, and “those who do the work are best placed to solve it”. Also the agile concepts of close collaboration between customer and developer, and developing products with short feedback cycles.

Many models and theories of intrinsic motivation also claim people are more motivated when they can at least see, or better yet be involved in, that right hand part of the model, where the value is realised. This puts the solution in context and provides a sense of purpose to the expended effort.

It also has implications for every day decision making. Once understood, it is harder to claim that developing solutions in isolation, remote from the problem and point of value realisation, is merely a matter of taste, or a valid alternative way of working. It becomes a matter of professional ethics to continually try to reduce this distance PV. It also allows us to help decide in which problem solving activities might be better investments of effort. We should normally prefer to invest effort where the problem was more closely and recently identified, and thus better understood, and can also be realised as value sooner.

I also think there is a fractal aspect to the model. It is possible to zoom out and see this whole PSV chain as being part of an S point in some larger context. It seems possible to zoom in on an S point, and see it containing other smaller PSV chains. There could also be multiple S steps between a P and a V (where perhaps the act of realising one solution as value is the same as defining a problem for the next step).

I was recently discussing on twitter the situation of developers wasting effort on developing software that is not useful, and whether or not they have the power to be involved in deciding what should be developed. In terms of this model, I claimed it was more professional for knowledge workers to see themselves in that whole context, and understand the context that gives rise to the problem and how it should be realised as value, rather than merely solving problems. It certainly seems professional to continually strive to shorten this distance where possible.

July 23, 2012

A story about two conferences

Filed under: Uncategorized — Kurt Häusler @ 2:06 pm

So earlier this month I attended two conferences. It was interesting to compare the vibe at each.

The first was Scrum Day 2012 in St. Leon-Rot.s2dlogo

In fact I actually attended PSM training with Ken Schwaber as a kind of add-on prior to the main event. This was a two day training seminar where we learn all about Scrum from Ken’s perspective in preparation for taking the Scrum.org PSM I test. It was great. Ken is one of the signers of the Agile Manifesto and has a lot of experience in the software development sector so I feel really fortunate to have had the opportunity to attend, and hear about Scrum directly from one of the two inventors. All the anecdotes he told were especially interesting. As far as Scrum content goes, well I am reasonably up to date on Scrum itself, being a regular reader of the two main Scrum mailing lists, and I am fairly familiar with the current version of the Scrum Guide, so as far as content goes there wasn’t that much new there for me.

Now Scrum Day this year had the tagline “Upscaled Agile in Large Enterprises”, so it was perhaps expected that the participants attending the PSM training were faced with issues particular to such environments, and I wonder if Ken tailored some of his material to that type of audience as well. The biggest thing that I noticed was his language reinforcing the divide between “the business” and “development”. Not just recognizing that it exists, and presenting Scrum as something to perhaps bridge this divide, but he seemed to feel as though this divide was at least inevitable, and perhaps even desirable. Now from my participation in the Scrum mailing lists, and other communities, this division is treated as something contemptible. Idealists claim there is no division, and pragmatists/realists claim that it is at least harmful, and something that should be bridged if possible. Ken’s language really made me feel that Scrum is, and even should be, something that just developers, and testers, and perhaps analysts and designers, do. “The Business” and even “Product Management” is something that happens outside the Scrum teams. My feeling is that the community has been trying to bring people involved in these mysterious leviathans in the teams, and get people across the whole value stream sitting and talking together. Ken’s vision for Scrum seems rather less ambitious. Scrum.org’s tagline is “improving the profession of software development”, which these days seems like a fairly narrow focus indeed. After all, Scrum is not specific to software development. Besides, I thought a Scrum team should be cross functional, and has to contain ALL participants involved in creating increments of customer value. So I am not sure if the implication is that “the business” and “product management” are not involved in creating customer value, or by customer value were are merely talking about a bit of software.

One of the reasons he gave for this separation, was that Scrum teams work on things like “stories”, but the business and product management don’t understand what a story is. He suggested that even the PO shouldn’t have to know too much about what a story is, because it is such a technical concept of more relevance to to developers. He suggested the PO should work with the team, and the team members should actually write the stories. I don’t have a huge problem with that, I think in smaller organizations it could work well. But in larger organizations this will lead to the situation where the majority of the process is not covered by Scrum, just the little bit in the middle where software gets developed. That leaves a gap that presumably a more waterfall-like process can cover. The business and product management will end up creating huge requirements documents for the PO to bring to the team for the team to go through and split into PBIs. Then the organization essentially pays the overhead of two processes, plus the costs associated with the cultural conflict  between the two. Surely the larger the organization, the more important it is to move the aspects of agility, like story creation, as close to the customer as possible!

I should have written better notes, but I believe he mentioned the organization has 5 core responsibilities. 1 of which belongs to the development team, 2 more belong to the SM and the PO, and the remaining two, Quality and Governance are best left outside the team. I am sure I must have partially misunderstood this, but I think he claimed those responsible for various aspects of quality, like architects, UX designers, and other specialists are best left outside of the Scrum process. If I correctly understood this, I find it a fairly weak approach, and against the idea of the cross functional team.

He also explained how Kanban wasn’t as good as Scrum for a software development team, and that Kanban would be better for simple and complicated activities, but he greatly misunderstands how the Kanban community intends it to be used. Across the wider value stream, which is a huge difference to Ken’s approach of using Scrum merely in that little bit of the value stream where the software gets developed. Sure, if someone is to use Kanban just within a team of software developers then I agree it doesn’t bring much, and might even be worse than Scrum, but that is not how Kanban is supposed to be used. If I could choose between applying Kanban to bring together people involved across the whole value stream, or applying Scrum, as Ken expects, just to the narrow little bit of the process where the software gets developed, I would definitely expect to see more improvement in effectiveness with the wider Kanban approach.

One idea I did like was his idea of a Scrum Studio. The Scrum Studio concept involves setting up a pilot project using Scrum, but as separate to the existing organization as possible. (I assume it means the Scrum team is not embedded in the middle of a monstrous corporate hierarchy, but rather outside of it, with ideally nothing between it and the customer. Then, people who come to accept the agile values, and Scrum way of working, can decide to move over to the Scrum Studio, forming new teams, and taking over more and more of the old business, perhaps until the old business no longer remains. I think that is one of the few decent models I have heard of for addressing the problems that larger organizations face as they move towards a more agile way of working.

Anyway, I passed the PSM I test with 96%.

The evening after the second day of the PSM training was 1 hour open space, followed by an open fishbowl discussion (with Ken, and the guy behind the Scaled Agile Framework, Dean Leffingwell). I couldn’t really take part in the open space as the PSM training went longer than planned, but I butterflew around, and got an idea of the types of topics those presenting found interesting. I also noticed most of the open spaces were like mini-presentations, with the moderator standing at the front as expert and selling some pet-idea and participants asking questions. Half the topics were things like “how can you have a standard company architecture without a framework team?” or “how do you audit an organization’s agility”, and the other half were “Hear about how my cool new XYZ model can solve your problems”.

The open discussion brought out more of what I call the fear and mistrust type of questions, things like “how do you do agile without letting the developers have too much freedom and messing things up”, “how do you control the dependencies between teams”. There wasn’t much talk of my favorite topics like culture, mindset and motivation. Most of the discussion occurred firmly within the analytic mindset.

The following day was the Scrum Day proper with many presentations. I attended the keynote by Ken, then I manned our company stand for the rest of the day. I spent most of the time listening to the 76 year old security guard tell fascinating stories from his life, which was the highlight of the event. Conferences need more story-telling. I had the feeling most people were either sent there by their boss, to see how dangerous this new fangled Scrum thing is, or were there, as I was, to sell something. So it was a commercial conference rather than a community one. That’s cool, but it was rather different to the conferences I usually attend, and to be honest I felt a bit deflated by the vibe.

The following day I got up early and drove to Amsterdam for the Stoos Stampede.


This was an open space style community conference. One difference was the session planning occurred before the event, as an experiment. This had the advantage of people knowing what to expect, so they could decide whether or not to attend. I thought it was ok, because this stoos thing is pretty new, and you just can’t be too sure what will be covered.

I was a bit cautious. I was warned by at least 3 people whose opinions I listen to than it might not be that good. It might just be people pushing their agendas etc. Now I was pleasantly surprised. Sure some sessions were agenda-pushing, but those agendas were usually in line with my values, and were tools or ideas I could possibly use. I knew a few people there, but even when among strangers I felt as if I were among friends. We understood each other, and had similar goals. That was not the same for the Scrum Day.

I arrived late so just stumbled into a session. In fact most sessions I just selected based on the vibe I perceived and whether there was a free chair or not. I wrote down the following notes from the first session:

  • Middle management is not a problem, but a symptom (victim) of the problem.
  • Throw away your organizational charts.

Now I quickly ended up interpreting most things at the stoos stampede in terms of rightshifting and the Marshall Model, it just seems to be the structure my brain has decided to use to hang all the stoosian type content off of. So the assumption I made for the first point, is that the problem being referred to is being stuck in the analytic mindset. That second point I see as perhaps something an organization might be able to do as they rightshift, perhaps once they are partially synergistic, and wish to improve further, or perhaps it is a characteristic of the transition between the synergistic and chaordic mindsets.

I also attended a session on sociocracy, which is a tool I guess for using cybernetic principles for handling interaction between different parts of an organization. Especially for decision making. It was kind of interesting, but there was a lot of language referring to the “top” and “bottom” of the hierarchy. There was mention of those at the top having veto rights over decisions made lower. I noted that doing it the other way around would be more interesting. Imagine if those “below” had veto rights over decisions made by those “above”? It seemed to partially be a replacement for local decision making. I thought it might in fact increase the communication overhead in many situations. Rather than local decision making, I have to delegate it to a circle or something. There was some discussion about the hierarchy, and the host did not believe you can simply remove the hierarchy. He also mentioned it has nothing to do with command and control or autocracy, but that it was merely an abstraction. Hmmm.

There was also mention of a consent principle. I noted that I have to learn more about this in relation to coaching and consulting. I feel that often issues arise because coaches or consultants forgot to get consent from those being coached or consulted. I thought of asking the next team I work with if anyone does not consent to my idea and why. If anyone does not consent, then whatever reason they provide is what I have to address first.

So on the second day, I attended an inspiring (and even emotional) session on story telling. I intended to check out the story-telling cheat-sheet and use it for writing this blog post, but I haven’t done that yet. Story-telling is definitely something exciting that I want to learn more about.

After lunch I sat in on the provocatively labeled session, “does stoos need a manifesto?”. Of course it doesn’t, but that doesn’t mean we didn’t have anything to discuss. Someone discussed his vision of the movement: “Stewardship of the living rather than management of the machine”. It really resonated with me. Now can you imagine that coming out of the Scrum Day? Imagine standing up at Scrum Day and telling all these fear and mistrust managers that the best way to focus on making agile effective in larger organizations is to focus on stewardship of the living rather than management of the machine? They aren’t ready for that, but eventually that is what they will need to hear.

Still, it is almost opposite to the prevailing lean wisdom that managers should focus on managing the work rather than the workers. I dunno, I find the two reconcilable.

Some of the discussion seemed to boil down to two opposing concepts. Is stoos most concretely a statement of values, like agile, that tools can kind of base themselves on, or is it a collection of tools that support some vaguely understood yet not concretely defined value system. I would probably prefer it to be the latter, but lets see how things evolve. The values seem to be fairly well accepted by most agilists I guess, but there is a gap when it comes to concrete thinking tools we can actually apply to do whatever it is we want to do.

I led a session on Rightshifting and the Marshal Model. I was worried nobody would turn up. It took place at the same time as a very attractive playing with Lego session. But 5 or 6 of us were able to have an interesting worthwhile discussion on the topic. I explained what it is all about, drew the classic graph, showing how the ROI from change decreases if you stay in the same mindset, and that to really get improvement you have to change the mindset. I boldly suggested that the Ad Hoc and Analytic mindsets were not stoosian, and the Synergistic and Chaordic ones were. I advertised the LinkedIn group, and Bob’s blog, and I covered what I considered to be the advantages. They being:

  • The Marshall Model provides a language that stoosians can use rather than using more problematic words like Taylorist (Taylor said some good things too), Command & Control (the military uses it differently to how our community uses it), Agile (only applies to software development) etc.
  • For those using Kanban, it is useful when it comes to buy-in, you can explain that deep Kanban is all about cultural change, and is unsustainable if the organization is committed to staying in the analytic mindset, and also as one of the models mentioned by what used to be the 5th core property, and is now known as the 6th practice.
  • As a community.

The final evening was also a lot of fun, and very conducive to story-telling, but unfortunately this is already far too long…

June 22, 2012

Let’s hear your horror stories

Filed under: Uncategorized — Kurt Häusler @ 2:21 pm

I don’t think there are any perfect systems of knowledge work or product development out there. Almost every workplace can be improved somehow. Even ones without concrete tangible problems can still be optimized somehow.


Before we continue I have to come clean. This a marketing post. I am assuming it is at least as painful for you to read as it is for me to write. Who wants to be sold to? I think in general the “pull” principle should apply to all goods and services. If you want it, go and seek a vendor, rather than having vendors push upon you reasons why you should need their wares.


Anyway, I hope this might be a bit more interesting for my target market (I feel dirty just typing that in), because my target market is a little different. I specifically want to address those who are usually overlooked. I am specifically addressing those knowledge workers who don’t have the authority or budget to acquire the services of a consultant!


That’s right, I must be crazy. I am trying something new. Normally consultants tailor their offerings to the ruling minority in organizations, the managers, those with the authority and the budgets. These managers often have some idea about what they think the problem is, often they are right to a certain extent, but it usually involves changing the way the workers do their job (the symptom), rather than changing the way the managers do theirs (the root cause).


Even if consultants know that the best opportunities for success are to be found in directly addressing certain “dysfunctions” in the management system, it is usually too hard to sell, so some trivial, but hopefully valuable changes can be made at the team level that improve things somewhat.


A while ago I tweeted “Devs should have just as much budget for bringing in consultants to fix management, as management has for consultants to fix development.” It was meant as kind of a joke, but I have been thinking about how much sense it makes! I have been talking to other consultants lately and at least a couple of them have recognized the same anti-pattern, and suggested it is usually exactly those who think others need to change who are most in need of “coaching” themselves.


So how can I help?

  • Perhaps as a software developer you want to try some agile technical practices, or have done so with some success but aspects of the management system, or decisions made outside the team make further improvements in that area difficult or impossible. Or perhaps all the hard work you do just seems to get swallowed up in waste or dysfunction elsewhere in the organization? I can help look into these issues and suggest things that you can do and I can work on your behalf to help encourage improved behavior elsewhere in the organization.
  • You as an engaged knowledge worker have a bunch of ideas that you would like to try out, but the company culture (fear and mistrust dominate most organizations) makes sticking your neck out a risky proposition? Perhaps you have seen “trouble makers” already suffer as a reward for their engagement? I can act as an advocate, perhaps seeing what options there may be for opening up some level of trust, and a culture of collaboration in your workplace.
  • Perhaps you have tried Scrum, but you as Scrum Master have trouble with the bit about spreading agility to the rest of the organization? You are not alone. This is difficult, but I can help.
  • Perhaps you use Kanban, perhaps you even had external consultants come in and teach you the basics, and set up the initial system, but now you are alone, a column is full, people are hit with WIP limits and wondering what to do, sales and marketing are “pushing” to meet promised delivery dates, and management are implementing some fairly draconian Kaizen “improvements”? You need my help!
  • Is everyone just sick of change, and want some space to focus on doing their jobs, delighting customers, and wanting to enjoy it as well? I can help find that space.
  • Perhaps you think everything is fine, and couldn’t be further improved? Well I am sure we can find something.

It goes without saying that I will approach any situation with tact, empathy, discretion and understanding of all involved parties. Many IT consultants have focused on fairly concrete products in the past, and it was just a matter of explaining what the product or method was, and implementing it. Softer, more personal issues were simply not relevant. Most of the problems facing organizations today are much closer to the realm of culture, values, and even emotions, yet many consultants approach things like it was simply a new software product to be installed, and people to be trained in, or a new method to be applied. This is why we see a lot of Scrum and Kanban being sold, but little true cultural improvement. I am not afraid to tackle some of the softer aspects that may be standing in the way of true increases in effectiveness.


More about me? I identify more with being a change agent than being a coach. Sure, as an external consultant I know less about your organization than you do, and I realize that you are much more critical to the success of any improvement effort than I am, but I am going to get stuck in. I am not going to sit on the sidelines like a neutral observer, or merely asking questions like a therapist leaving you to come up with solutions yourself. I, like any real human being come with my biases, prejudices, and my own vision about how a modern knowledge workplace should be, and I won’t try and hide that. And I certainly wont compromise it just to make a sale either. I am quite open about the fact that I find the majority of organizations involved in knowledge work to be run according to an unsuitable theory of management, and bring a toolkit inspired by more progressive approaches such as:

I think you can get a good idea of my values by checking out my twitter.


So let’s get some sort of dialog going: How can I help? What struggles are you facing at work? If you did have authority and budget for consulting, what would you like them to do? What sorts of experiences have you had with consultants in the past?


I know when I was a software developer I had a lot of steam to let off, I felt I was a victim of the prevailing mindset without even understanding it in those terms. I generally found value in sharing my troubles on certain mailing lists and online forums. I would like you to feel welcome in sharing your troubles with me.


Feel free to leave a comment below, or contact me via any of the social networking sites on the sidebar, or emailing me at kurt.haeusler@gmail.com.


It probably wont be easy or comfortable, the change may be fairly radical, but you have to start somewhere!

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.

« Newer PostsOlder Posts »

Blog at WordPress.com.

%d bloggers like this: