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.