Kallokain

If you are interested in systems thinking, you might want to watch Ron Davison's webcasts . I haven't viewed the whole series yet, but what I have seen is interesting.

I have just released part three in the How Organizations Change series. I decided to split the material into more digestible chunks, so I discuss only one of the root causes that make it difficult for organizations to learn and adapt: fear. The webcast contains material from a ZDNet Australia interview with Lloyd Taylor, VP of Operations at LinkedIn. I would like to thank Brian Haverty, Editorial Director of CNet Australia for permission to use the interview. The full interview is available at http://www.zdnet.com.au/insight/soa/LinkedIn-Lloyd-Taylor- VP-of-Technical-Operations/0,139023731,339285616,00.htm The webcast also contains an excerpt from the A Day with Dr. Russell L. Ackoff conference at JudgeLink. I would like to thank Dr. Ackoff for his kind permission to use the material in my webcast. Dr. Ackoff's talk at the conference was inspired, to say the least. You can view it all at http://www.judgelink.org/Presentations/GirlsLink/index.html .

Speaking of measurements that do not work, Jeff Sutherland has written an interesting article about time sheets in software development. Good stuff. Go have a look.

Ken Judy posted a thoughtful reply to my post commenting his post about productivity metrics. Judy writes: Just to be clear, my objection is not that agile should not be justified by hard numbers but that I haven't seen a metric for productivity gain specifically that both stood systematic scrutiny and was economically feasible for the average business to collect. If you have an andon (board with sticky notes representing units of work) set up, it is easy for the ScrumMaster (or project manager, if you do not use Scrum), to enter information about when each sticky note is moved into a spreadsheet. This takes the ScrumMaster a few minutes every day. (Or every other day. I would not recommend measuring less frequently, because if you do, you will miss information about inventory build up, and slow down responses to problems.) From the raw data the spreadsheet can produce: A burn-down graph. The usual way of visualizing progress in Scrum projects A cumulative flow-chart, showing b

In a recent article Ken Judy takes the stand that agile software development should not be adopted on the grounds of higher productivity. The reason for that, Judy claims, is that there are better ways to justify adopting agile than with hard numbers. I can sympatize, because I have worked in my share of software development projects where the measurements did more harm than good. Nevertheless, I believe Judy is wrong in this instance. Most organizations measure the wrong thing. That does not imply that measuring is bad in itself. Judy is correct in stating that measurements drive behavior. He is also correct in stating that in most software development projects, measurements have unintended side effects. In many cases these side effects are quite nasty. The problem is not with the idea of measuring, the problem is that how to design measurement systems, and how to use them effectively, is poorly understood. To begin with, it is useless to measure unless we know the purpose of our mea

My blog has drawn attention from spammers lately. Therefore I have turned comment moderation on. I hope this will help.

I won't blog much the next couple of days because I am working on the third and final (, OK, probably final,) part of the How Organizations Change webcasts. One of the things needed to solve the problems discussed in part two is to stamp out fear by rewarding failure. By sheer coincidence, Falkayn posted a short article on the same topic today. He also linked to a ZDNET interview with Lloyd Taylor , VP of Technical Operations at LinkedIn. Here is a brief excerpt from the interview: Dan Farber: Now, it looks like you have spent an entire career innovating, how do you create that culture of innovation in these different places that you go, how do you inspire people to kind of break all the rules? Lloyd Taylor: The culture needs to reward failure. That is the answer.

I have just released a new webcast in the How Organizations Change series. This is the second part, and it is titles Obstacles to Learning . Like any proper 2nd part (compare with Star Wars: Empire Strikes Back ), this presentation is all about problems. The third and final part will present solutions, and thus be a lot more upbeat. You will notice a change in how the video looks, compared to earlier videos. This is because I have switched from iMovie to Final Cut Express. I like iMovie, but over the next few months I plan to do some things that require a bit more horsepower.

Too busy to blog much at the moment, but if you want to read something thoughtful, I recommend that you read the Prefer Design Skills article by Martin Fowler. Fowler is one of the deep thinkers in software development. He wrote the book on refactoring. refactoring is nowadays one of the basic techniques of agile software development. Refactoring is also a cornerstone in design methods like Kent Beck's Test-Driven Design (TDD) and Behavior-Driven Design. Done correctly, refactoring can totally transform the economics of maintaining and developing code. In conjunction with a few other things, that is. Prefer Design Skills , is one of those things, and it is often overlooked. The reason, I believe, is that Prefer Design Skills is a management pattern. In many organizations there is an unfortunate disconnect between what software developers do, and what management does. For example, companies invest vast amounts of money in object oriented tools and languages every year. These tools

This might be old news to most of you, but Clarke Ching recently published two podcasts with an interview with Eli Schragenheim: Part One Part Two Eli is a respected TOC management expert, with several published books to his credit. One of my favorites is Management Dilemmas .

I recently published an article about Net Promoter Score (NPS). Over the next few months, I will run an experiment. I am going to use NPS to improve your satisfaction with my blog. Therefore I have two questions for you: On a scale of 0-10, how likely are you to recommend my blog on your blog, or recommend it to friends and colleagues? What is the main reason for giving the score you did? I will publish a new survey once per month over the next few months. If you comment on this post, I hope you will reply to future surveys too. I am using Google Analytics to check how many visits I get, and what the most popular articles are. In six months I will write an article about the results: Did reader satisfaction improve? If so, did increased reader satisfaction result in more readers? Some of you have blogs of your own, and are interested in process improvement, so why not do the same thing? It would be interesting to try improving (and expanding the readership of) a group of blogs. In six