Battle Won

After 8 iterations, the team was able to correct more than 85% of errors. The agile project proved itself.

We estimated our tasks in hours. Nobody wanted to use the mysterious story point based estimations. The estimation process worked fairly well. We did not use any agile style estimation methods. We just did not need it. The new release was installed when the defined quantity of task passed the test. In this case, budget did not play very important role, as we worked on crises management. On the other hand, the team was ultimately committed; they did everything what they could and they enjoyed the look of the better and better working IT system.

Of course, we did estimate task. But the estimation process itself was a democratic conversation. In fact, we always reached consensus after a short discussion.

The length of daily meetings was decreased significantly. But we did not reached the desired 15 minutes. What the most surprised me was that the team had got to discuss the status of their work every day.

We did not have any special software. We used the old MS Excel. I found many different templates on the Internet and after some modification I could create an excellent MS Excel file to handle related PM tasks and even the Kanban board. The team was shared into 2 sub teams. The sub teams were located in different cities. Therefore, we installed Skype, which allowed sharing a computer screen. Such way, everybody could look the MS Excel based Kanban board from my notebook. Unfortunately, the recent version of Skype does not include this useful feature.

I would like to add some remark to the Kanban methodology. I often hear that Kanban is useful only for the support style work; I mean when the goal is to clean a production system from errors. According to this “theory” (I would say gossip), the only acceptable way is Scrum. No exception! I do not agree. I believe that the project objective determinate the proper project methodology.

Kanban is very flexible having only 3 rules and it is very powerful if you use WIP well.

In summary, our crises management was extremely effective. The customer received an almost error free IT system. The highly motivated team members did their best and did enjoy their work. The most interesting is that the inspiration for the team was not a bonus offer. Their motivation was the positive feedback they received after installations.

It was no question that they wanted to continue working in agile style. I felt the same.

First Impression

We met problems soon, on the first day after the planning. Nobody wanted to participate on daily meetings. Team members had remembered their first, so called agile project. Then they had spent hours on daily scrum, as nobody had known that we had been working in Scrum. It had been mere wasting expensive development time. But, I insisted on these meetings. I promised to keep 15 minute time box. These meeting lasted no less than 20 minutes and no more than 35. It was still more than prescribed. The source of the problem was that we often discussed technical problems. I tried to stop such discussion, but, I did not want to discourage them. I allowed expressing their thought and only after some minutes, I stopped them.

Our first iteration was impressive and interesting for all of us.

After the end of the iteration, the team gathered to discuss how we had been working. For me, it was very successful two weeks. Six errors with higher priority were corrected and installed. There was a long way to go, but our customer was happy. The customer saw the light at the end of the tunnel and started to believe in Kanban. I thanked the effective work of the team. It was cool to see their happy faces.

The retrospective continued with the discussion of the use of the daily meetings. Much to my astonishment, the team decided that daily meetings were useful and we had to keep them on the next iteration as well. Of course, they had remark about the length of the meetings. We had to reduce it to 15 minutes.

Of course, the technical problem had to be discussed. However, there was no space of such discussions of the daily meetings. The solution was obvious. If anybody had a problem, then it was discussed after the daily meetings. Such way only the necessary personnel was involved and the remaining part of the team could continue their work.

During the iteration, we had to organize a meeting in order to select a new task from the product backlog. It caused undesired delay in the development process as everybody had to interrupt the coding and went to a meeting. In accordance with the measured performance of the team, the limit on the selected for sprint tasks was raised from 5 to 6.

On the second two week iteration 7 more tasks were finished. The length of the daily meetings was decreased but we still did not reach the required 15 minutes. Otherwise, Kanban style seemed to work well.

The Beginning

So, I started my first agile project according to Kanban methodology. It was not an ordinary Kanban project, as I was both the product Owner and the Kanban Master, two in one, like in an old commercial.

Originally, Kanban has 3 basic rules:

• Workflow must be visualized.
• Quantity of task in at least one of the works must be limited.
• Flow must be measured.

I added some extra rules got from Srcum.

I wanted daily meetings as I counted very important to have information about the status of the project and I wanted to know problems as early as it was possible. On the other hand, some of the developers of the team liked to change the specifications. It was essential to keep them on the right path because the project budget was already empty and we did not have time to waste on developing unnecessary functions.

The product backlog was filled with not errors, which had to be corrected. Do not forget the aim of this project was crisis handling and releases containing error correction had to be installed as fast as it could be possible.

It was quite a challenge for me. Nobody working for my company had practice in agile methodology. Nobody had even theoretical knowledge on agile work. My PM experience suggested me that agile was the only way leading out of the problematic situation.

I had dozens of questions and there was nobody around, who knew the answers. How and when do the developers select tasks? How many corrected errors must be in a release? When shall the priority of stories be determined and changed? When do we plan tasks?

If you work in accordance with scrum, then you do not have similar problem. Scrum defines the sprint and the related work well. But, in this case, I had to avoid the fixed length development stages as the goal was to correct errors as soon as possible.

Of course, there were other problems as well. I did not know how to be agile. I read a lot and I was browsing YouTube searching for sample scenarios. But, I had never tried in practice. Nevertheless, some of the developers did not want any change.

The team had worked hard yet they had not met success. Consequently, the moral of the developer team was very low.

Why did not I give up? Because, I knew that the agile methodology would work and because, the team believed in me.

I explained my plans to the team. I created an optimistic presentation about the roadmap. The team liked it and they started to believe in my plans.

The Kanban board contained 5 columns:

• Tasks selected for the sprint,
• Planning,
• Implementation,
• Testing,
• Ready to install.

 I did not want the team to take too many tasks at the same time, as they had done it before. Therefore, the limit was set to the first column “Tasks selected for the sprint”. The team consisted of four developers and a tester. Therefore the limitation was set to 5. Such way, each developer had one task and they had one task in the buffer. The developers after implementation tested their work and our tester executed the integration test. The integration test covered the whole functionality of the IT system including data connections.

Integration test could contain no more than 5 tasks at the same time. It was the most important limit. Its purpose was to provide quick releases. As five tasks were ready they had to be put in operation. There were no scientific calculations in order to determinate the limit value. The other possible value was 3, which would have made more frequent releases. But, faster releases mean more installations. We did not want to waste time installing every second day.

We decided to organize meetings on every second Mondays. On these meetings we would tailor the working principles similar to Scrum retrospective and the team would select new tasks from the product backlog. In that case if all tasks had been implemented before the meeting the team had selected five tasks from the product backlog out of turn.

We also had an unusual QA. If a task did not pass the integration test, then it had to put back to the implementation. In such case, the developer had to decide if the related tasks could be repaired in a day. If more time was required, then the related story had to be withdrawn from the sprint and put back to the product backlog. I hope it does not sound complicated. The aim of this rule was to prevent the delay of the release and to speed up the crises handling process.

The other QA rule had very interesting impact. This rule said that if a task failed on the integration test the second time, too, then it had to be put back to the product backlog. I wanted this rule to provide the dynamism of the implementation process. But, the developers counted the second failure as the loss of face. Therefore, I met second failure only once.

Before starting the project, we had a half day off; we went to have fun with the team in order to raise their moral and have fun together.

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.