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.

FrankfurterEntwicklertag

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

#NoEstimates Interview with Fabian Schiller

Filed under: Uncategorized — Tags: — Kurt Häusler @ 11:30 am

#NoEstimates – an Interview


I met up with Fabian Schiller (Twitter, Blog) recently at the Agile Rhein-Main User Group in Wiesbaden, we started having a brief chat about #NoEstimates, and decided to continue our discussion via email so it could be blogged later. All numbers are fake yet realistic. Fabian also blogged the interview on his blog.


Fabian:  “Hi Kurt, you tell me that it is a good thing to stop estimating? I’m sorry, but I cannot imagine how that could work out. How will I be able to calculate the costs for an upcoming project? As a business person, I must – at least – have a rough estimate, how expensive my project will be to know if it will pay off. How can you do this without estimation?”


Kurt: “Yes I think in general it is a good thing to stop estimating, there will always be situations where it makes sense, and of course it also depends on what we mean by estimating. For calculating costs estimation is especially bad. In fact the agile community had never even discussed estimation for this purpose. Estimation was generally safe as a tool for teams to use in planning how much work to take on each iteration and for providing rough forecasts about which features might be available in which release. For calculating costs there are a variety of approaches. Asking a team to sit down and guess how many developer hours each feature will require to type in and adding this up and multiplying these hours by various hourly rates is the poorest approach I have seen whether we are preparing an estimate for a T&M project or determining an actual price for a fixed price project.


My first comment would be that pricing an entire project at once is un-agile. It is at best hybrid, but that might be ok. Exactly how I would price the project depends on a lot of factors. How well does the customer understand about what he wants? Has the team done something similar before? Does the customer have a budget? How flexible is the customer and is he open to working in new ways or does he have certain constraints?


One simple approach (that might work in some cases but not others) would be to identify the most important feature than can be developed in one sprint. We know our team costs for a sprint so we can base the price for this “Version 0.1” or “Minimal Viable Product” on our costs. Then the customers question might be “how do I know in advance how many sprints I will need?” Then it gets interesting. I would perhaps then ask him something like “what are the minimal features we need to go live and start earning money?”. Perhaps something like the Incremental Funding Method could be an option.”


Fabian: “OK. That explains a lot. I see many valuable approaches in what you say. The idea of delivering MVPs and approaching a project in small steps is nice. But as a customer I do not want to risk building one increment after another to determine that my money will not suffice to get the minimal marketable product ready when the money is already spent. So, I essentially want to know if there is a realistic chance to get my product built within my budget. How might that work with an MVP approach? Or am I and my project just not eligible for working agile? Is that what you are saying?”


Kurt: “The assumption I made, was that there was at least enough money available for a minimal viable product (One thing we like to offer customer’s is a special price for an MVP that can be completed in 1 sprint), and some extra available for further work in case it is not ready to go live (if the software development is only part of the product for example, we probably can’t go live until the rest of the product is ready anyway). It sounds like you already have a fairly detailed understanding about exactly what it is you want as well as a budget. In other words, fixed scope, with a fixed upper bound on budget. This is probably the easiest case. Without needing to get too detailed, we can compare our delivery rate of features with our pricing and see whether the budget easily covers it or not. We can probably do this with an MVP approach but it sounds like the difficult part is already done. You already know exactly what you want. (MVPs are usually used when the customer doesn’t know exactly what he wants, and wants to first test the market with an MVP and use the feedback to drive the vision of the product) In this case we can simply build it, one feature after another, and provide regular feedback about how much of the budget we will be using. This is a fairly typical approach, and definitely qualifies as agile software development. Radical people like me would consider it a hybrid situation, as the financial decisions and requirements gathering has already taken place for the whole project, and only the development itself will be carried out iteratively. So the whole “project” doesn’t sound agile, but the software development phase can certainly be carried out according to agile software development.”


Fabian: “OK, I think I got that. You would just take all my stories, divide them by your average

sprint capacity and then – since you have a fixed size team – know how the costs would be. Correct?

But how do you know, that the stories, I will deliver are about the same size as the stories, you worked on in the past? If you simply take the number of stories, size should matter. Doesn’t it?”


Kurt: “That is roughly right, yes. However I won’t pretend to be able to “know the costs”. The first step is to see if we are anywhere in the same ballpark. I would take your stories, and split them, which is a fairly mechanical process looking for certain keywords, steps in a workflow, or variations etc, and count those. The numbers I base my costs on are actually based on a larger group of 20 people that is usually split into 2-4 teams and works on 2-4 different things at once. So not quite sprint capacity, but close. I know over the last 12 months this group has cost roughly 130,000 Euro per month on average, and has delivered over the last 12 months roughly 180 items per month. So that means my costs are roughly 730 per item. We only need a small margin say 5% as everything else, like rent, hardware, training, maternity leave etc is already included in the 130,000 costs. That brings it up to about 760, which I would round up to 800 to provide a nice round number and cover the risk on my size if I have to commit to a price up front, say if you will only accept a fixed price offer. Oh and you don’t really need a fixed size team, you just need to know how much the typical team changes over a year affect costs. It is definitly better to have a fairly stable team though.


So we can take that 800 and multiply it by the number of stories, you have and compare it to your budget. I would recommend proceeding only if the price is significantly lower than the budget. If it is more, or comes close then the project might not be such a business success. Even if the expected price is slightly lower than the budget, I would still suggest looking for a better project, knowledge work should result in significant rather than scant returns.”


I fully expect that in any backlog the stories will vary in size. This size is not as important as many people think, once you consider the whole value stream, rather just just the development itself. I expect that the distribution of the true lead times of items I attempt in the next 12 months, and my throughput will be similar to the distribution of sizes of items I delivered and my throughput over the last 12 months. Plus every new project gives me new statistics that I can use to base the next months prices on (and one month of year old statistics drops out of the moving average). If your project turns out to result in longer lead times or a drop in throughput (whether that has anything to do with item size or some other factor), then my cost per item will go up slightly, and I will raise the prices for the next project. Possibly however another customer’s project has factors (maybe item size, maybe something else) that result in shorter lead times and an increase in throughput and they will cancel each other out.”


Fabian: “OK, I see, there is a lot more thoughts in #NoEstimates than just denying to estimate ;-)

Your explanations sound reasonable. But they open up two further questions for me:


1.) If your first step is to break down stories at the beginning of a project to relatively small ones – will you not be very detailed before starting to implement? This sounds kind of like a classical project specification for me…


2.) Using your mechanics, you would implicitly reward customers, that formulate larger and larger stories over time which sounds not good for neither your understanding of the project nor the next customer, who will have to pay that bill? After all, the distribution of story sizes is not a random variable, but highly determined by your customer!”


Kurt: “With regards to question 1, my preferred approach is in fact NOT to break down all stories in a project to relatively small ones. My preferred approach is to simply pick the single most important feature, break that down if necessary, deliver it, and repeat. Even if we might know what the next most valuable features are I would ignore them for now and concentrate on the single most valuable feature. This is not too radical for agile software development or lean startup. This particular case is a bit different for these reasons: you already know exactly what you want, and have already completed the initial phases of the project in a waterfall manner, at least the requirements gathering seems to be complete. The other reason why we do this initial quick splitting is because you wanted a forecast upfront about how the expected costs of the whole project might compare with your budget. This is definitely a hybrid project but that is ok, most are.


You are right that a customer who is paying per feature might try and make them bigger to get more for his money, that is why we always split before committing together to beginning development of an item. But it could still be the case, that even after splitting one customer’s project’s items turn out to have shorter lead times or less impact on system throughput than another customer’s items. This doesn’t necessarily mean one customer is being rewarded over another. It means that customers are paying for the value they get rather than the effort we put in. Why should a customer pay more for a feature just because we have to do a bit more research than usual? Such extra investments don’t just benefit him but help the team in general, so this method spreads the costs. Why should a customer pay more for a feature just because an employee has gone on maternity leave and we had to hire another. Costs will go up, throughput will go down. This will change our cost per item, but no specific customer should be rewarded or penalised for this.”


Fabian: “I think, I understand: Either I know exactly what I want to have (and am willing to invest heavily in analysis), then you would just break down stories to relatively small ones. Otherwise, you would suggest to proceed incrementally via MVPs (where you break down stories for the next increment only).


The activities in both cases seem relatively similar to what I would do when I would estimate a project (or a part of a project):

* Specify what will be delivered with the next milestone

* Break it down (to a certain degree), to see what has to be done

* Assign every item some specific effort

You just leave out the last item, which is putting a number on it, ain’t you?


The amount of work for assigning efforts seems relatively low for me, if you already broke down the work. This brings me to my next question: What are the concrete advantages of not estimating? What problems are solved by not estimating?”


Kurt: “The first bit is roughly right, although I don’t think anyone should ever need to invest heavily in analysis. If you know what you want in advance then the analysis has been done. If you don’t then we can start to think in a lean startup way, and conduct experiments to test our market assumptions and generate new knowledge. I guess initial story splitting is a kind of analysis, but it is more like a simple mechanical process, looking for keywords etc.


And of course as usual, both extremes are rare, more typical is something in the middle, where the customer knows something about what he wants, but not all the details.


I like your list of three points. I would leave out the third point, but I would replace it with something like “assign a risk category”, or “assign a class of service” or “calculate the cost of delay”. Actually these things don’t need to be, and shouldn’t be, done all at once in the beginning. That is waterfall, or hybrid not agile. I think it is better to do such things as late as possible, just before the actual development.


You are right that the problem with estimates is not just that it takes time. It is unprofessional. It is like fortune-telling. It is simply guessing, and in several decades of software development we have learned that it doesn’t work. The numbers that is produces cannot be reliably used for anything, except perhaps sprint and release planning. Now we are starting to understand why it doesn’t work. You cannot reliably predict the effort involved in completing work in the complex or chaotic domain. Even if you could predict it, this number will not have any meaningful relationship to anything important. Now the agile community has talked a bit about estimating, and done a reasonable job with it so that it is useful in certain circumstances, done in a certain way. Using relative units like story points has helped scrum teams perform sprint and release planning, particularly when the variability of PBIs is not well understood. It is important that everyone understands the limitation of this approach. That these estimates are not to be understood by a customer to be a promise, they are not applicable when considering the wider value stream, they should not be used to base prices on etc.


No one in the agile community ever said that effort estimates are the correct approach to use for calculating costs in an offer or invoice. No one ever said that effort estimates be used to determine project delivery dates. Doing this has resulted in losing huge amounts of trust and money (either the customer’s or supplier’s).


So there are several problems solved by not estimating: Project failure in general, mistrust and disappointed customers, teams that feel disappointed when the actual lead time and delivery rate doesn’t match their guesses, and huge loss of money.


Imagine these slight exaggerated scenarios. Imagine a Scrum team developing software according to a backlog, and they need to know what they might achieve in a week. In this case the units of work (PBIs) are relatively large and few in number compared to the container (the sprint). It is like packing large stones in a small jar. If the stones have a variety of sizes then guessing at their rough relative sizes can help determine if we can pack in 5, 10, 15 or 20 stones in the jar. This is all the agile community has ever used estimation for, and in this specific context, it solves a specific problem.


If we consider the whole value stream, not just the development, and look at the departmental or business unit level, or even if we consider whole projects rather than individual sprints, then we aren’t packing large stones into small jars. The size of the units of work is relatively smaller compared to the container. It is more like filling larger jars with grains of sand. Not only filling the jars, but collecting them from the beach, cleaning the jars, filling them, packing them into a box and taking them to a post office. In this scenario would you bother trying to estimate the size of each grain of sand? No. You would use concrete measurements of how many boxes could be delivered to the post office over the last lear, and use that information to base future business decisions on.”


Fabian: “Thanks Kurt! I think we covered many topics. And cleared up several misunderstandings about #NoEstimates. I really appreciated this dialog as I learned a lot!”


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.

ALE

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.

Lkce

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.

January 6, 2014

2013 in review

Filed under: Uncategorized — Kurt Häusler @ 9:23 am

The WordPress.com stats helper monkeys prepared a 2013 annual report for this blog.

Here’s an excerpt:

A San Francisco cable car holds 60 people. This blog was viewed about 3,600 times in 2013. If it were a cable car, it would take about 60 trips to carry that many people.

Click here to see the complete report.

November 19, 2013

Book Review: The Principles of Product Development Flow

Filed under: Book Review — Tags: , , — Kurt Häusler @ 11:26 am

This will probably be a short review, as it has been some months since I have read the book. This book is really dense with information. Many people find it very difficult and suggest reading his previous book first. In fact at the Kanban Leadership Retreat we had a session called “Dumbing Down Don”. I had read his previous bookreviewed it here and heard the author Don Reinertsen speak probably 3 or 4 times at conferences before I read the book. Also his ideas were already well known to anyone in the “Kanban community”, so I felt well prepared and didn’t find the material particularly challenging. Actually challenging is the wrong word. I didn’t find the book particularly difficult to understand. It does however challenge much mainstream thinking in the area of the economics of product development management, so in that sense it is indeed challenging.

Flow

This is probably the best book I have read so far this year. It was an easy 5 stars on Amazon and Goodreads. I continually recommend it as the most important book for anyone using Kanban to read. Assuming one gets training or manages to understand the basics through experience or other sources, I might even consider it more important for Kanban practitioners than David’s book. The third Kanban core practice, Manage Flow, is one of the hardest to grasp, and this book is essentially the guide to this practice.

The biggest takeaway for me was the material on understanding the true costs of product development. Too many places I have worked at think cost is a simple matter of counting the hours a developer spends pushing buttons on a keyboard. This book helps highlight the importance of paying attention to other types of costs, particularly the costs associated with queues and the cost of delay. I also really like the way he brings things back to real numbers, as in financial numbers. That is something many in the agile community for example seem to avoid or at least overlook. In a lot of ways Don Reinertsen reminds me a lot of Tom Gilb. Another concept in the book that has occupied my thoughts lately is the asymmetry of payoff functions. This is the idea that we cannot expect every product to meet our desired expectations, and in fact often only a minority of products can be or should be fully leveraged in order to fund the less successful ones. Basically we should recognise and accept that most of our products will not be hits and kill them as soon as we have invested enough to realise that they will not be hits. The minority of hits should be successful enough to fund the investment in the non-hits. This is standard practice in the pharmaceutical industry for example. The question that haunts me, is how can software development service providers leverage what we know about the asymmetry of payoff functions. Service providers earn the same regardless of the level of success of the product. Could this be changed? Should we price software development services according to the level of success the product reaches in the market? It is a dysfunction splitting the organisation developing the product from the organisation that realises the value of it? One thing I am convinced of is that most software development service providers spend way too much time, effort and money on products that will not meet their market expectations. It still seems unintuitive for a software development service provider to kill a “project” that is not meeting its financial expectations, and this needs to change. Too much development capacity is wasted on such low-value work.

This book is definitely a must-read not just for Kanban practitioners, but anyone involved in developing products, especially at a management level.

Oh that reminds me, another thing that I really liked is that he uses the phrase “Product Developer” in places where we might expect to read “Manager”. He does this all through the book when discussing decisions that need to be made. Now in the real world the old “Taylorist” split between manager-thinkers, and worker-doers still exists. Even in software development. The idea that a e.g. Software Developer will be involved in an investment decision based on concrete financial information is still very foreign, but one that I see as a desirable and necessary future, and the language in this book assumes and hopefully reinforces this ideal future, which really appealed to me.

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.

Play4agilelogo745cropped

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: 

CoachingNVC

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. 

 

 

May 20, 2013

Pricing, and a little bit about estimation.

Filed under: agile, kanban, lean, scrum, Uncategorized — Tags: , , , , , , — Kurt Häusler @ 12:54 pm

So I keep getting involved in discussions on twitter related to the different ways of basing prices for software projects, and it is hard to get some of the subtle details across in 140 character snippets so I thought it might be a good idea to put some ideas together in the longer form of a blog post. The whole thing is somewhat related to the #NoEstimates debate.

I also believe the base of my ideas is fairly mainstream. Most of the agile community (dominated by the Scrum community) talks about estimation in terms of estimating PBIs so you can plan how many to take on in each sprint. A few people still do it in ideal person days like Mike Cohn recommended back in the dark ages, which I am opposed to (but not to the point of getting into arguments about it) as I think there are some serious downsides to that approach. That is not a radical opinion, and it is the reason why most people use more abstract, relative units of size like story points, which I personally don’t advocate, but I don’t oppose either. Even most of the defenders of story point estimation for sprint planning recognise that the true advantage is in getting the team to talk about what needs to be done, and the actual estimate is a secondary benefit. A few of the more advanced teams, and even the inventor of story points Ron Jeffries himself, prefer to simply use a count of PBIs. This is the approach I find most sensible, when combined with backlog grooming and story splitting. Also after using Kanban for several years I have realised that estimating is pretty much wasteful. I don’t think that is a radical opinion either as it seems shared by much of the Kanban community, who make use of a metric called throughput which is essentially the same as velocity and is typically presented as a number of items done per unit of time.

But as long as all we are talking about is how many items to plan for each sprint, who cares? The consequences of over or underestimating are minimal. If we plan too few ask the PO for more, and the velocity goes up to plan more for the next sprint. If we over plan then we drop the velocity and plan less for the next sprint. As long as this is all we are using estimates for then who cares how we do it.

For me estimates are only really a problem when they are taken more seriously than intended. For example when calculating prices, or when forming an offer or contract that a customer may rightfully interpret to be a commitment to deliver, and expect to be based on something more solid than a guess. Sadly the agile community talks so much about estimation in conjunction with sprint planning, and very little about contracts and pricing. I have even heard people say that the way that contracts and prices are done is completely orthogonal to how the software “project” is carried out. I disagree completely. From my experience the way the contract is written and the way the work is priced are the fundamental factors that indicate to what degree any software development endeavour will be “agile” or not. Or should I say to what degree it is even appropriate for knowledge work and product development, or anything in the complex domain for that matter.

If some manager comes to the team and says “these requirements have to be done by the end of July, and we have a budget of 20 architect “person-days” and 60 developer person-days and 30 tester person days and 10 manager person days, now use Scrum to make it a reference agile project”, then your options are pretty limited.

I think the disagreements in the NoEstimates debate are based on a misunderstanding. The ProEstimates crowd are saying “What is wrong with estimates? It is just a simple tool to help teams plan how much work to take on each sprint”. The NoEstimates crowd are saying “if you are making promises to customers, and trying to price your work, there are much more professional ways to do it than guessing”. The ProEstimates crowd just don’t see things like offers, contracts and pricing to be relevant. Heck the Scrum Guide doesn’t even mention them. All that businessy stuff happens way upstream anyway so we just have to accept whatever deal management outside the Scrum team has made, and as long as we carry out the work according to Scrum we are all agile right?

I agree with both sides, which is possible because they are talking about completely different things. I just find the ProEstimate argument to be boring, obvious, non-controversial and not addressing any particular problem. The NoEstimate argument on the other hand is advocating one of the critical next steps that the software development community needs to take in order to restore a culture suitable for software development and good faith with our customers.

The other misunderstanding I see in the NoEstimates debate is that the ProEstimates crowd thinks the NoEstimates advocates are somehow refusing to answer questions like “How much does it cost?” and “How long will it take?”. This is quite false. As far as I am aware the NoEstimates crowd are attempting to answer exactly these questions using techniques with a higher level of professionalism and more reliability than guessing.

Anyway the opinions I have on pricing are based on experience, and they are also more relevant to some contexts than others. I believe this blog post is highly relevant to the following types of software development, which is where I have most experience:

  • Companies doing custom software development work for other companies.
  • Product companies where the customers pay for the features they want and even the bugs they want fixed.

I suspect this blog post might be less relevant for the following types of software development:

  • Internal IT. I have little experience in this area, and even less in how it is priced and funded, but I suspect things are a lot simpler than when dealing with an external customer
  • Product companies where the product is funded in another way separate to the development of features. E.g. via a subscription model, or advertising, or purchases of new versions. I do have a bit of experience in this area, and things are a lot simpler.

I think a lot of people on the ProEstimates side of the fence are engaged in the latter areas and simply don’t see the issues that the NoEstimates guys are having to deal with.

There is also a grey area in-between, such as where are large company has outsourced its IT and while the company doing the software development is technically doing custom development for a customer things are also much simpler as there is only one customer. In effect it is basically the same as internal IT.

So what is the problem?

I have worked for a number of companies in the former category that used similar methods for pricing software and suffered similar disadvantages because of it. Generally these companies rely on a horrendous mix of time tracking, rate cards, up front estimation in person-days, time & materials billing, bookable time and “slack” divided up according to percentages, and the need to explain to customers why the actual amount billed differed slightly from its up-front estimate. For me this is the worst. And so many of these customers are using agile approaches like Scrum to develop the software too. You would think they would be aware of the dangers of things like time tracking. The community (with the exception of Scott Ambler) seem to be unanimously against it. But unfortunately those with an understanding of knowledge work and product development are not those making the deals. They are usually a very different type of person unlikely to read books like Don Reinersten’s Flow, or engage in the subtleties of the economics of software development at conferences or online. They are more like the software equivalent of the used car salesman. 

So here is how it works: the customer has an idea of what they want. Sometimes this is just a vision (which is good), sometimes it is a more detailed list of requirements (which is ok, but a little bit wasteful as it is highly likely to change). The salesman will then take some of the team capacity and if the customer only had a vision those team members will then have to come up with some business and technical concept and estimate how many person-hours of each role is required to develop each bit of the solution. If the customer presented a more detailed list of requirements then they can skip the business concept, and just come up with the technical concept and an estimate. The salesman has to choose carefully how many and which team members get to be a part of the conception and estimation activity. You don’t want the whole team as this is all non-bookable time, which is perceived by such cultures as expensive, so usually the salesman picks the architect, the analyst and the best senior developer, or something like that.

This approach is already non-agile, or worse than that, it is fundamentally against the realities of knowledge work and product development, regardless of “agile”:

  • The idea of having a complete set of requirements at the beginning is long known to be unrealistic, the the downsides to this way of thinking are well known. Many of the requirements will, according to the Pareto Principle, be superfluous in the sense that their effort in being developed will be out of proportion to their use in the finished product. It is also a myth that anyone can know in advance what is required, This always changes. The customer never gets exactly what they want, and even before they see the first version they change their mind about what they think they require.
  • It is actually preferred, and more realistic to start with a mere vision. This allows the true scope to be discovered, adjust and grow as the development endeavour proceeds, and starts off with the knowledge that scope is and should be negotiable. The idea of having a complete set of requirements works against this. For the actual software company to start with something good (a vision) and discard all the advantages by turning that into a detailed list of requirements up front is bizarre and ridiculous. The chances of it being what is actually best for the customer are even less than if the customer themselves came up with a list.
  • It is also pretty disadvantageous to select a sub-set of the team to create the conceptions and estimates. This requires crossing the problem-solution line, and breaks one of the rules of estimation that it has to be done by the whole team. In software development, the team should be problem solvers. They should get an idea of something small that the customer desires, and work with the customer in solving the problem, implementing the solution as software and realising it as true customer value. With the used-car-salesman approach, the small sub-team of elites are trusted with the task of solving the problem, and determining the solution up-front, and the actual development team are reduced to mere source code typists, which is highly demotivating.
  • Additionally the estimates are usually much more optimistic than if they had been given by the team, and those in the sub-team are not available to the development team for assisting with the actual development of actual software.
  • It is also a waste of time, all these discussion that take place during conception and estimation still need to be held again so the actual whole team can understand them. (At least this second discussion might be bookable to the customer).
  • If you are using something like Scrum, combined with estimation in story points which is fairly typical, you have to go through and estimate everything again anyway.
  • Also these estimates are usually “ideal”. They only reflect the actual minimal time an expert might spend on typing in the solution once and that is all. Anything like research, or learning, or pair programming, or communicating with each other, or improving the system, or tests, or refactoring is extra. That is why project managers add a buffer to to the estimates or the price that the customer sees, so they have some wiggle room later, but the actual team still sees the tighter estimates. After all if you let them see the actual buffered values they will simply chew the buffer up with non-value-adding activities like refactoring or writing tests, and there won’t be any buffer left at the end to make up for the shortfall which for some reason always occurs at the end.

So what happens next? The developers start counting hours present in the workplace and recording them in some electronic system. This is called time-tracking, and suffers the following problems:

  • Some people say the main or only problem is the time that time-tracking takes. This might be the most obvious issue but it is the least of it. Sure it can chew up around 15 minutes per day, but time tracking is much more evil than that.
  • The developers have a budget per feature, and there is a general hectic vibe with everyone primarily concerned with which booking position every minute of the day belongs to. No one want’s to be the guy that has less bookable hours than anyone else. In fact everyone tries to keep their bookable hours as close to 100 percent as possible, as the general perception is that any hour not booked is wasted. Typically project managers and even product owners insist that anything like knowledge transfer, or writing tests, or refactoring or even one person in a programming pair shouldn’t be at the customer’s cost, and has to be booked to an internal booking position. As a result, these activities simply do not get done, or at least no one wants to spend much time on them.
  • The teams more expensive roles end up siting there idle. Since the project manager was involved in the technical conception and estimation, and was concerned with presenting as low a cost as possible to the customer, he preferred to see more (cheaper) junior developer hours being offered as more expensive architect or senior developer hours. As a result, even when the team is struggling to meet its sprint goals, the architects sit there doing nothing because if he did the work the customer would get a more expensive bill than if the junior developer did it. The customer would then come back and demand to know why he was charged architect costs for something that could have been done by a junior developer. As a result project managers insist on architects NOT helping the team to meet their sprint goals, which damages the feeling of trust in the team.
  • A related issue is when cheaper developers get assigned the tasks where there is a high risk of requiring more time than that estimated. I have seen a team suffer a huge drop in motivation when a student, with a cheap per hour rate, was given all the most interesting tasks (that were sold to the customer as junior or senior developer hours), because he essentially had more than twice as much time as estimated to do it, and you automatically have some extra buffer for the risky, more innovative and interesting parts of the “project”.

I hear a lot of managers claim that time & materials works well for them, and that estimates correspond very well with actual development hours. That is because developers are painfully aware of their budget, and compromise on quality in order not to “overspend” their time budget. Without fail these managers also wonder why they run into technical debt issues a year later. Actually they don’t wonder. They know it is down to poor commitment and discipline on the part of the developers. On the other side of that coin is that it discourages innovation, and encourages maximising expended effort. Assume a task was estimated at 5 days. If someone can find a clever way to do it in 2 days he probably should right? Well with T&M there is no incentive. If he does it in 2, then he might not have anything else to do for the week and his bookable hours will drop. Also the company will  get 3 days worth of money less. Usually project managers solve this by shuffling hours around and lying to the customer about what took how long. They will simply say it took 5 days, and use the extra 3 days to reduce something that took longer than expected.

Particularly sad are the companies that think they are cool and generous like google for allocating a 20% “slack” time that doesn’t have to be bookable. This implies that everyone is under extreme pressure to book the other 80% of their time. Guess what ends up being done in the 20%? Meetings, bug fixes that the product owner thinks should not be billed to the customer, writing tests, learning from other developers, pair programming and refactoring. It is much better NOT to have such a percentage goal of bookable hours. The team needs the freedom to decide for themselves how to best to allocate their time in order to deliver, and besides, the customer pays for everything anyway. It is not like the government pays for the 20% time. This trick might look good at first glance, but it is total bullshit that has no pros, and only cons.

There is one general issue that lies at the root cause of all the parts of this nasty approach to pricing software development efforts: The idea that it is appropriate to measure software in terms of person-hours. Once we get beyond that dangerous myth, we instantly solve a number of problems and we open things up to the next level of professionalism in managing software development.

So what is the alternative?

So let’s look at better models for pricing software in order from best to worst, according to my opinion:

  1. Value based pricing: The best way to price software is according to the value it brings the customer. We can negotiate with the customer and help him discover what sort of value the delivered software might bring, and come up with a price that correlates with the expected level of investment required to bring such a return. However I find this suffers from a couple of problems that might make this approach difficult:
    • Business value is hard to determine. Software development, when worthwhile, is a high risk endeavour, featuring an asymmetric payoff function similar to the development of medications. We can expect to start a large number of experiments with the hope that they will be highly successful, and expect that most of them will be canceled as soon as we discover that they are not going to be a big winner. The occasional big winner results in so much profit that it more than covers the losses associated with the “failed” experiments. (Actually, the information we learn from these experiments usually makes the investment worthwhile, so failure is probably mot the right word). The fact is, we often have to at least start the development process and test a feature or two on the market before we even know what its value might be. This is hard enough at the project level, and even harder at the “story” level that agile development prefers, so I suspect for this reason value based pricing to be very difficult in practice. One model that could work would be to measure actual value afterwards, but this requires a high level of trust, and exposes extra risks for all participants. It essentially makes the software development company a full stakeholder in the product, which may or may not make business sense.
    • The other issue is that customers may not be willing to share their expected value, even if they know it.  They want to get the lowest price possible, and not give the software vendor a hint as to the maximum they might pay. There are also a lot of things that can be done cheaply and easily, but result in huge wins for the customer. The vendor might think it is fair to take the usual percentage cut of the wins, but the customer most likely does not.
    • Even if we know the customer value, before we decide if we should do it or not we might like to know to what degree, if at all, it covers our costs. This means that even when using value based pricing, we might still have to use one of the following more cost-based methods to determine if we should do it or not.
  2. Price per feature (determined at time of commitment): My current favourite model is very simple and based on measuring the teams price per (average) groomed feature. It works especially well with a system where Kanban plays a role. You should have a rough idea of your costs. Ideally they are mostly a function of team salaries and fairly fixed, otherwise in more dynamic environments you can determine separate components, perhaps basing it partially on an average of previous months, and known costs for the next month. You simply divide these costs by the throughput and add an appropriate margin. Before the customer and team commit together to developing a feature, some backlog grooming should occur and the team should perform the usual steps of story splitting. Queue replenishment consists of presenting the split stories to the customer, together with the current price per feature. They can select as many stories as there are free places in the input queue. When working with multiple customers it is good to authorise the product owners to do this on behalf of the customer, or to establish some idea of how much team capacity is to be allocated to each customer (ideally in terms of total system WIP). This shouldn’t be too big a deal, the PO can communicate with the customer up until queue replenishment about what the price could be and how many free slots the customer will have. The price is fixed at the time of moving the item from the backlog to the input queue, and payment is due a number of days after the item is done. If you have a two stage commitment system, or end up cancelling more than a handful of items in the middle of the process and have multiple customers then it could get a little more complicated, but I might blog separately about that. I don’t currently see any disadvantages, but I know someone will have some questions about it so please challenge me in the comments, and allow me the opportunity to make this concept even more solid. I know a lot of people seem to think it will only work with items that are “roughly the same size”. This is not true, and in fact the concept of size is a bit bogus when considering the whole value stream. We groom and split in order to preserve some liquidity and flow in the process, to prevent large items from blocking the system, and to inhibit the lead time distribution from blowing out too far to the right. I fully expect significant differences in the measured lead times of different items, that is the reality of knowledge work and product development, but there is no real need why they all need different prices. If the customer has 3 features in the backlog, but only feels 2 are offer enough value to justify the price per feature, then he should only choose those 2.
  3. Renting team capacity for a period of time (in terms of system WIP, not in available person-hours): This might be an ok option for those doing a longer term software development effort, and wan’t to save the communication overheads of accepting a small offer every week or so. It is also based on a Kanban approach. Assuming costs (plus margin) of 100,000 per month, and a total system WIP limit of 100, then we could have one customer paying 30,000 per month for exclusive rights to 30 of that WIP, and so on. If the throughput is 100 items per month, we might expect he gets to see 30 items per month. Or he might not. We could provide both options and allow him to choose which is best for him.
  4. Fixed price per team-day or team-sprint (aka. T&M light): This is probably good for Scrum teams, or teams when you only have a single customer and don’t have too many issues with balancing capacity between different customers or classes of service. It is also based on costs plus margin. One discussion I got into recently on twitter was with a defender of T&M. It turns out they don’t do up-front estimates of entire projects, they don’t have rate cards, they don’t have a target number of billable hours and most importantly they don’t do time tracking. Basically for every day a team works, they get a bill for a team day with a discount for team members on holiday. To me this is a lot closer to a fixed price per team-day than the true T&M monster as typically practiced. However they reported it requires a large amount of trust, and only works when the team has a single customer (which some consider ideal, but I personally consider it a risk of the “all eggs in one basket” variety.) The team just developers iteration after iteration until either the product is good enough, or the customer decides they have spent enough money.
  5. Fixed price variable scope: This is the classic agile fixed price scenario where there is some budget set up in advance, and the team simply develops iteration after iteration until the money runs out. It is essentially equivalent to the fixed-price per sprint, except presumably the option to quit before the fixed budget runs out is excluded. I don’t know what is supposed to happen if the product is good enough before the budget runs out. I guess the team is supposed to keep developing unwanted features until the budget runs out. There is also the question of how is this budget determined. I guess the customer has some idea of what he wants to spend. I could also imagine it being based on a rough release plan, which is in turn based on an initial but negotiable backlog and a known velocity. I am not sure what advantages this model brings over the previously mentioned ones.
  6. Fixed price, fixed scope, but the price is obviously sufficient to cover costs and the scope is easily achievable by the due date: Sometimes we get lucky even with dysfunctional traditional methods. As long as we ask for more than enough money to cover things even if things go wrong, and we leave ourselves plenty of time to get things done, even with the inevitable changes in scope, then why not? It is still better than the full-on T&M model with all its disadvantages. But not much better.
  7. Fixed price, fixed scope, fixed due date, and the team thinks it will be tight: This might even be worse than full-on T&M. I don’t know which one is worse. They are both extremely damaging. Sadly they are the 2 most common approaches. In fact the typical Scrum-using but otherwise not very agile company thinks they are the only two options. They are convinced that one of them is not “agile” so the other one must be. Usually a company has a bad experience with number 7 so declares it un-agile, and then feels super smug and ultra-agile for using full-on T&M together with Scrum.

So there you have it. My current views on the various approaches to the pricing of software development. I have to mention again that my favourite is 2. I don’t really have a problem with any of 1-4. I don’t see much point in 5. 6, 7, and the full-on T&M I described at the beginning are the used-car salesman approaches. They are lazy, damaging, unprofessional and betray a poor understanding of how knowledge work and product development works. Instead of violating our customers and teams with such approaches we need to think about things a bit deeper, and consider the damage we are doing, and start behaving more like professionals. The relationship between the software development and the customer is too important to be left to sales-people. It requires product developers to be involved. It needs to be more like the way a doctor and their patient communicate, than the way we currently operate, as if it were possible to fix scope and sell person-hours like the kids at McDonalds sell fries.

I recently read a blog post from someone, it isn’t that great, it exhibits one of the misunderstandings about NoEstimates (he somehow thinks NoEstimates is all about refusing to answer the “how much” or the “how long” questions), but one quote was interesting:

If you don’t know where you are going, if you don’t have some notion of what done looks like, if you can’t tell me approximately how much and how long, please don’t start.

At first I thought, woah wait a minute, this pretty much excludes anything in the complex domain, aka anything worth while. Even beginner agilists know that software development is an experimental process, and it is quite typical to begin something before we know how much it will end up costing, or how long it will take. But on second thought I agree with him. There is no way to know what done looks like when we are talking about a large project, no way of knowing how much it should cost, and no way to know how long it will take. They can only ever be discovered once we have invested some effort in the information generation aka software development process. So I agree. We should not do large projects. However we do know what done looks like at the story level. We can say how much it will cost, and we can provide a certain degree of confidence about how long a story will take based on concrete measurements and backed up by statistics. So I agree. We should only ever do story sized things. Actually why not take his quote even more seriously and use it to base our definition of what we should attempt to develop? If we don’t know what done looks like, we can’t put a price on it, and we can’t say how long it will take then we shouldn’t start it. It is obvious what he means. We shouldn’t do anything larger than stories, we have to get away from projects being the main batch size of relevance to pricing, offers and customer communication in general.

So here are the main points again:

  • Don’t sell person-hours, it is not appropriate for things like software
  • Don’t pretend scope can be fixed in advanced
  • Don’t use time tracking
  • Don’t use T&M billing
  • Only estimate where and how it is appropriate, the whole team may use story points to plan how much work to take on per sprint, and that is pretty much the only place for estimation in software development.
  • Never estimate in hours, only relative units like points
  • Never base prices on estimates, use measurements instead
  • If you have customer contact, write offers, work out prices or negotiate contracts, please go to a couple of conferences, read a book or two, and engage with the community
  • Don’t think you are cool by gifting your employees 20% slack time (by insisting 80% of hours must be bookable), all you end up doing is pressuring the employees not to spend time doing what they should. And it really messes with the idea that a team should self-organise
  • If the offer and pricing is fundamentally not “agile” or at least makes no sense from a knowledge work and product development perspective, then planning the development using Scrum won’t help you much
  • Forget about “projects”. When it comes to prices and offers, we don’t want to deal with anything larger than a story

I have a feeling this might be a blog post I keep coming back to and refining. I already suspect I have left some interesting details out.

Any questions or comments? 

Addendum 1: Two additional models that I have been made aware of but forgot to include to this list are the “price per story point” model. I don’t prefer it, as it suffers from many of the same disadvantages that other approaches based on up-front estimation suffer, but if you are estimating in story points anyway, it might work for you. I would probably put it somewhere between 4 and 5 maybe. The other model is the incremental funding method. This is a really great one if you can get it to work. In this method we minimise initial investment and risk, and focus on developing a product that makes sufficient money to fund further development. This concept isn’t really an alternative pricing model as such, and can thus be combined with any of the above listed pricing models as an additional technique. You could even use it to filter out projects that should not be invested in past their initial MVP. Any projects that don’t self fund after a calculable investment in money or time should be cancelled, so that that investment can be channeled in more worthwhile activities. I believe Don Reinertsen’s book Flow even presents some useful numbers that can be used to help support such decisions in the section on asymmetric payoff functions.

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?

Older Posts »

The Shocking Blue Green Theme. Blog at WordPress.com.

Follow

Get every new post delivered to your Inbox.

Join 1,477 other followers

%d bloggers like this: