Quite some years ago, after attending a presentation about lean production at Toyota, I decided to buy the book “The Toyota Way”. I had the feeling many of their 14 management principles would be applicable to professional services as well. I started reading the book, but never finished. Last weeks I read several posts about lean software development compared to another Agile working method: SCRUM. Honestly, despite the recent car issues that Toyota is facing, I feel both methods, or even a combination of these two, can help us deliver software in a better way.

Yesterday I was talking to a researcher of the Amsterdam University. As Goyello we take part in the Symbiosis program and from time to time they measure the progress of all the participants. During the interview we concluded that in many outsourcing projects in general the demand management is the weakest part and the main cause of failure. Nothing new, I stressed the importance before. The main question is probably why this keeps going wrong. I think the answer is simple: Software development is Art! And artists are hard to handle.

Just imagine yourself being the world famous painter Rembrandt van Rijn. Somebody hired you to prepare a nice painting of his company. Once you show him your almost finished painting, he requests you to remove a person and to move another one. And of course in his opinion this isn’t a big job.

Are you still there? How would you feel? Who’s the artist here? Who can decide whether something is easy or not?

Some time ago we decided to change our issue tracking system. We were using Trac which helped us a lot but at a certain moment it was no longer sufficient. The reason was simple. We wanted to create one work environment for our clients together with our developers and project managers. Among others we aimed to limit the amount of emails in between client and project manager. Was it a good decision to invite our clients to use our Project Management environment?

In my previous post I wrote about the client’s trust when using an Agile development approach. Based on my own experience I can provide the list of  at least 10 things you shouldn’t do unless you want to lose your clients’ trust (and eventually your credibility).

http://www.sxc.hu

In my previous post I wrote about the simple situation when incorrect agreements and lack of proper reactions leads to poor results. Clients always want to know two things. When the thing will be done, and how much it will cost. The rest is less important because they want to trust you. At least they should. Trust is very important because it usually makes the client come back with another order later on. In waterfall approach, trust is usually on the same level from the beginning to the end of the project. In Agile development, since you keep in touch with the client, there is a risk that trust will go away much earlier. Why does this happen? Is waterfall approach better?

Agile SCRUM defines the way how people should cooperate on the daily basis. However, in reality we are faced with situations where Agile rules are hard to use. How to handle such exceptions not destroying Agility in the team?

It’s been almost a year since we started implementing the Agile way of working by using SCRUM. During this time we have delivered several projects from very small to medium ones. Was it worth following this methodology? Is SCRUM really improving the way we deliver software? And what did we learn? Through this post we would like to share our experiences and lessons we lerarned. We are looking forward to receiving your feedback as well.

They already managed ages ago! So why don’t we manage to realize something as simple as a web application? Ages ago people managed to fulfill miraculous projects with hardly any tools. Today we can choose from a wide range of tools, but still we do not manage to run a project according to the client’s needs. What goes wrong?