Jul 4, 2013

Fail or Agile

Months later that I had met Scrum, I had to go to a business trip. I had time during traveling to read. My boss recommended a book titled 'Scrum or Kanban? Take the best from both'. This book was very interesting. It was very easy to read and when I returned I knew that I would try it. I had no idea how soon I would try agile methods.
I always have good relationship with our customers. I believe that every contract, every project must be good for both of us. Also, I believe that we must help each other during the projects and after them.
Back to the story, I got a phone call late evening. One of our customers asked for my boss's boss's phone number. I gave him and I asked if he had any problem. Well, we had a conversation lasting for more than an hour. My colleague project manager was ignoring his error reports and they had been working with an IT system containing dozens of errors for two and a half months. I told him to go to bad and I promised to eliminate the problems.
Next day, I gathered the team and the PM. After explaining the situation, we agreed that we had to act without delay. It was obvious that I would lead the team. We did not even talk about it.
It was an obvious solution to make an agile project as the errors had to be corrected as soon as possible. My first thought was about the scrum. Maybe because it was more formal than Kanban, as Kanban has only three rules. The biggest challenge was to divide the required works into sprints. I admit I had no idea how to do that. There was no time to examine how others did Scrum. From the other hand, my instinct knew that Kanban was the better way. Well, maybe it was not the Force who leaded me on the agile path. Just Kanban allowed transfering releases faster that Scrum. There was no need to wait for the end of the two-week sprint. When some corrections would be ready, the new release would go live.
But, before starting the work, we had to analyze what had leaded to the problematic situation. The source of the problem was a wrong decision. The team had wanted to correct all errors in one gigantic release. While they were working on the correction, new errors occurred. The team decided to correct the new errors, too. However, the new correction in most of cases made conflicts with the old ones. Therefore, the old corrections had to be corrected again. It became an endless chain of errors.
It was the reason that the basic Kanban rule (WIP) was to release the new system after three errors were corrected.
This was the first real agile project in life of the firm I worked for and in my life as well.

No comments:

Post a Comment