To Do Lists or not To Do Lists

Friday, October 31, 2008 4:31:30 PM (Romance Standard Time, UTC+01:00)
At some stage in my life, my experience of time changed from being something I had plenty of, sometimes even too much, to being a very scarce resource where tasks and chores compete for time and attention.

The other day I walked past a place where  there used to be a cherry plum tree. I remembered how I as a kid, could spend hours in that tree, enjoying the half-ripe plums, without ever feeling there was anything more important or serious to do. Usually there was a price to pay the next day, but that did not prevent me from doing it again again. While I mourning that lost paradise, and looking for a way to find it again, there is the practical problem of managing, remembering and prioritizing all the stuff I have to do.

Over the years I have used multiple systems: Sticky notes, task lists in Outlook, notebooks of all kind, emails send to myself, mindmaps, and probably a few more I can't remember. All of them were great for a while, but all had limitations that let me to eventfully give them up. For instance Sticky notes are great, tangible and practical - as long as you are the same place all the time. Mindmaps are great for a brainstorming a set of tasks, but more tedious on a daily basis.

But now I have used a tool continuously for more than a year, and I am still surprised by the way it can fit to any of my changing work modes and places.

The name of the tool is Remember the Milktm . It is a free, webbased tool. What I really like about it is that it  is simple, easy to use, and at the same time extraordinary flexible in terms of input and output.

The core of the product is a set of tasklists, each containing tasks, that can be prioritized, have a due dates, estimates and a few other things. It is easy to create and remove lists. 

But what it really impressive is the numerous ways to enter new tasks and the equally impressive amount of ways to manage and be reminded of tasks:    

First of all there is a nice Ajax based Web-UI. From that I can enter  and maintain all my tasks as well as my lists. That probably the least important part of RTM. 

I mostly interface with RTM through my iGoogle Dashboard in Firebox.  I also have access to my tasks via Gmail, Google Calendar, Skype and on my mobile phone.   Every morning I get a friendly email, telling me which tasks are due today, and if they are due at a certain hour, I get a reminder at that time too. Besides iGoogle, Google Calendar and Gmail,  I can enter tasks on my mobile phone or through email.

Try it out! - maybe you too will never need another tool to manage your tasks




By Bent Jensen

Posted in Tools |Comments [0]     

When the good guys behave badly

Monday, October 20, 2008 2:40:56 PM (Romance Standard Time, UTC+01:00)
Here at BestBrains we like innovative companies, and especially we like those that use innovation to solve on of the big problems of this era - Global Warming.

Tesla Motors are one of those companies. They are producing the Tesla Roadster, a cool, all electric sportscar.

Unfortunately Tesla apparently can not demonstrate mature leadership that matches the coolness and innovation of their products. 

According to this blog post and this they apparently decided to close their Detroit office. That means that 90% of the staff there will be without a job.  Information about this was given in a blog-post and those that did not get the message went to work, just to find out that they were fired when logging on to their computers.

One can only hope that management will be able to restore trust and morale in the remaining staff - or we will may seen just another good company destroyed by poor management.


By Bent Jensen

Posted in management |Comments [2]     

Good lean blogs and podcasts

Wednesday, October 15, 2008 8:04:10 PM (Romance Standard Time, UTC+01:00)
There is a lot of good stuff about lean on the Internet. Some of my favourites are:

Gemba Panta Rei: This is hosted by Gemba Research, a Washington DC based consulting company. Jon Miller, the main contributor, has a lot of insightful and interesting posts. For example the latest blog post is about how Dwight D Eisenhower could be seen as a lean thinker

Lean blog is written mainly by Mark Graban. It has a lot of good stuff, much of it related to Lean Healthcare, which is Mr. Grabans main interest. It also hosts a podcast service: lean blog podcast with interviews with leading lean thinkers to put on your MP3 player. For instance in episode #43 you can hear a wonderful impersonation of Dr. Deming, telling why Six Sigma is not in line with his philosphy.

The Elegant Solution, by the author of the book of the same name is a well-written blog about lean and Toyota. See for instance this post about A3 -thinking





By Bent Jensen

Posted in Lean |Comments [1]     

One more thing about Estimation (and Planning)

Tuesday, October 14, 2008 7:55:49 PM (Romance Standard Time, UTC+01:00)
In a "Traditional"  approach to estimation a set of detailed requirements are analyzed, and from that analysis a solution is designed that will fullfill these requiments. We then estimate the time it will take for us to build that design.

If we do Agile development, we instead measure the relative size of each of a set of high-level requirements (e.g. in the form of User Stories). We then assign a conversion factor to the relative sizes of the User Stories, to be able to predict, when we can have what done. If we do not know how long time it takes, we can do a small iteration, and see how much we are able to complete in e.g. a week. We then use that knowledge to extrapolate from the whole set of requirements, to arrive at a delivery date.

If I am to choose from those two methods, I will greatly recommend the latter. simply because the detailed analysis and design, always misses something, and because it has an underlying assumption that nothing, or very little will be changed over the course of the project - thus the investment in the detailed analysis and design is justified. Anyone who has created software in the real world know that is never the case.

But both approaches treat estimation, as if the size of a piece of functionality or time it will take to complete it, is a real characteristic of the feature, and what we do in estimation is trying to find that hidden, true number.

I will call both these approaches Reactive estimation.


And off course there is something I will call  Proactive estimation. In this kind of estimation, the estimators acknowledge that creating a piece of software, is a creative process, where problems are solved on a daily basis, and that the level of teamwork, dedication, creativity and problem-solving skills are the factors that really determine the lenght of a software schedule. In this kind of thinking, a team will commit to deliver a product to a certain date, but they know, that what will be delivered, will depend on their ability to learn and solve problems along the way. The development process is then organized to accelerate learning, and plan  in a way that keeps decisions  open as long as possible. In that way the team will arrive at the best possible result at the given date.  Much the same way a play normally always will have premiere at the date that was planned months of even years earlier.

Does this sound to crazy to you? Maybe - but that is the way Toyota creates new cars, on time and with fewer resources than their competitors, and I am convinced that some kind of proactive estimation was used when the iPod and the iPhone was created.

By Bent Jensen

Posted in Agile | Lean | Learning | Problem Solving | Estimation |Comments [0]     

Lean Pilgrimage to Japan, Spring 2009

Monday, October 13, 2008 9:12:50 PM (Romance Standard Time, UTC+01:00)





In April 2008 we went on an eye- and mind-opening study tour to Japan.  We visited a number of software companies, saw Toyotas Tsutumi plant and met the Agile Software Development Community in Tokyo.

We are planning to do a similar tour the week of April 20'th 2009.  This time the two leading thinkers in the area of Lean Software Development; Mary and Tom Poppendieck will join us.

The trip will allow a first hand experience of the japanese society and business life, as well as visits to a number of lean companies.

There will be a limited number of seats available to customers and friends

If you would like to participate, please write to bent.jensen@bestbrains.dk


By Bent Jensen

Posted in Lean |Comments [0]     

Trust in Software Development

Monday, October 13, 2008 9:47:39 AM (Romance Standard Time, UTC+01:00)

At BestBrains we firmly believe in trust as a key factor in successful Software Development.

We have all seen and experienced situations with lack of trust: Teams where problems are hidden instead of brought to the surface because team members does not trust their colleagues or managers, Companies where lack of trust between departments, leads to inefficient non-negotiable contracts between e.g Product Management and Development, and relations between customers and suppliers of large IT-projects where complicated contracts replace collaboration.

As engineers we do also traditionally see the lack of trust as a problem that mainly has its roots not in engineering, but on the other side of the fence, where people decide not to trust engineers. In our own self-understanding we are off-course trustworthy.

Saturday night I had an experience that led me to think, that maybe it is not that simple. Maybe there is a reason for the lack of trust, and maybe engineers has a role to play in changing the equation.

The event was a play at Copenhagen's beautiful new playhouse. The name of the play was "Håndværkerne" - "The Craftsmen".  In the play a young couple had hired a group of craftsmen to renovate their house. Again and again the work was delayed, and often the craftsmen asked for more money, with a sentence like "We know it is difficult for you as lay-men to understand, but it is not possible to predict this kind of - [some construction technicality here]  - but it is common, and there is really no choice, but to pay the money, otherwise the work will come to a halt". The young couple got more and more desperate with a feeling of total loos of control, and ended up killing the craftsmen one by one. Now they could start over with a new crew - that apparently were more trustworthy, or the couple knew how to manage them, because it all ended with a party in the beautiful renovated house.


A friend stated  afterwards, that this play was about the revenge of the Danish middle-class. For a number of years there has been a shortage of skilled labor, which has led to a upward price-spiral and a downward quality-spiral. Nearly everyone around the table had experiences with delays, poor quality, and exorbitant prices.  

Maybe similar experiences in the Software Industry has led to the current misery and lack of trust in many companies and between customers and suppliers. Maybe at some places arrogant, non-professional engineering organizations has driven their counterparts and customers to a level of desperation, where they, since we do normally not kill each other in Danish companies, have invented systems of contracts, and processes that mainly serves to protect from the lack of trust.


So how do we as engineers learn from this? In my view it is not enough to say "Trust me". We must prove to be trustworthy, and the road to that goes through delivering on our promises and by giving our customers, and the organization we are serving  a level of real control with the process. First then engineering organizations can begin to expect others to trust them and thus be able to remove the inefficiencies of mistrust.







By Bent Jensen

Posted in management | Waste | Trust |Comments [0]