Gangnam Style

I participated in a PMI conference. I do believe that PMBok contains useful good practices and I do believe that the PMI approach is extremely practical.

There, I learnt a new term the technical project manager. So far, I had supposed that technical project manager was some kind of IT project manager or similar. In accordance with the PMI terminology, the technical project manager is a guy, who knows project management tool and methodology very well and who ignores the project members need, except the stakeholders, of course.

Because, the main subject of the conference was that a project manager had to have technical, leader and manager abilities. The difference between the leadership and the management is that objects are managed and people are leaded.

This approach is not very far from agile, is not it? If you are familiar with them meaning of the PMI expression ‘progressive elaboration’ than you must agree that PMI good practices and agile methodology are very close to each other.

Then why do many people count PMI and agile as opposite approaches? For the first sight, I would say because of the lack of knowledge. However, after the conference, my conviction has changed. Dozens of other reasons could stand behind the curtain. The first and maybe the most important reason could be economical. Both, the Scrum Alliance and PMI organizes exam on agile methodology. Certificate of which organizations has to be better? Which of the organizations can take the money of the agile candidates? These questions are uncomfortable, are not these?

Courses of Scrum Alliance are connected to software development. PMI counts that agile methodologies have to be extended on other industries, as well. And this approach is right; just think about lean methodology.

However, I did not like one of the presenters’ approaches of agile management in the conference. He announced that Scrum does not work; therefore it has to be modified. I do believe that modifying Scrum can cause more problems than benefits. Some people just modify Scrum rules because they do not understand the Scrum basis or they just do not want to struggle to keep them. In these cases, changing the rules can be very dangerous.

The presenter showed us some examples of modified Scrum rules saying that these examples were taken from real life.

The idea of the first example was developing first in iterations and testing when the code is ready. Testing had to be embedded in the entire process. Otherwise, the implementation-testing-correction-testing process could be a never ending story. Believe me, testing on the last day of a sprint guarantees the unsuccessful sprint. There is no time to correct errors and retest them until the end of the sprint.

The second example puzzled me. The idea was based on two separate iterations. The project itself was divided into two phases, the planning and the implementation phases. The deliverable of the planning phase was the system plan. The system plan was written through some iteration. The input of the implementation phase was the finished system plan. The implementation phase worked out through iterations. It is an interesting approach, is not it. If the system plan was ready, complete, and validated, then it had to be implemented. Why are iterations necessary in the implementation phase? It is the mystery.

So, be careful if you decided to change Scrum rules.

Project Failure

Nobody talks about the project failure in an agile environment. Some people even celebrate failed sprints. Soon, I will post an article reflecting my opinion about the failed sprints. Now, let me talk about the source of the problems, which ruin projects.

I am sure that in most of cases overestimating the power of agile methodology breaks the project. The project and the related work are never better than the Scrum team and the team's will and knowledge. Agile projects contain the same tasks as the waterfall projects do. The only difference is in organization of the related work and the motivation techniques. Agile is not a miracle; it is just a methodology. What is really count are the people, the agile team behind the methodology.

Lack of the knowledge on the agile methodology is on the second place on the list named agile project failure. Scrum prescribes only few rules; Kanban has only three rules. It is not very difficult to keep these rules, is not it?

I heard many time that the scrum rules must be altered. However, I rarely heard the explanation why scrum rules must be altered. Some says that the goal of the retrospective meetings is the altering the scrum rules. I do not agree. I believe that the agile rules should be untouched. In the retrospective meeting, the working principles must be altered in order to increase the production of the team.

Some weeks ago, I worked as an advisor. I was involved in other company’s project and my job was to analyze the project progress and the possibility of success.

For the first sight, the dark fate of the project was obvious. The team went against the basic Scrum rules. The sprint length was set to 30 days. They reserved 5 days for planning at the beginning of each project and the last 5 days of sprints were testing period.

Wow! Five-day sprint planning sounds a bit much. After some analyze, I realized why they had reserved five days for planning. They just did not know the real requirements. The Product backlog contains standalone stories and the relevant business processes could not be covered by stories.

They said that they had not had enough time analyze the requirements. They wanted to do it during the Sprints. I still wonder how they wanted to set priorities to stories if some of the stories were unknown. The other dangerous point was that the customer did not know much about stories, scrum and software implementation at all. They were sure that their existing business processes would be supported by the new IT system. The customer had no idea that the IT guys did not oversee the business requirements. The language of stories was mostly technical and therefore the business people did not understand them very well.

The testing period at the end of the sprint also could be very dangerous. Tests must be executed during the sprint, on the fly. Otherwise, there would be no time to correct the error and then you will have a non-working product at the end of the sprint. I know that it is true. I know it well. We made the same mistake some months ago.

I started my analyze work in the middle of the second sprint. I rang the bells, but nobody believed me. Nobody wanted to believe me.

The situation changed at the end of the second sprint. The IT guys celebrated the end of the failed sprint. The business guys did not understand the reason of the celebration. They understood only that after two months there was nothing to see.

Then they decided to listen to me and revision their working principles. Why do I tell this all to you? I just would like to draw your attention that it is not a good idea to change to basic Scrum rules. Of course, you can do it. However, before acting so, take a deep breath and think if it is worth.

Conflict of Interest

Some years ago, common knowledge said that sometimes the project manager's interest turned against the interest of the company he worked for. Then I accepted this theory.

According to the PMBok, there should not be such conflict of interest. It is obvious, is not it? The project manager is the part of the organization. Therefore, if such conflict exists, then it is between the project manager as a project leader and the same project manager as an employee. In other words, the conflict exists only inside the project manager, in his mind. Therefore, there is no such conflict in a healthy organization and in the mind of a healthy project manager.

I admit it is not a soul warming feeling, when you are the project manager and it is your project what is cancelled. However, you do not have to worry if the cancellation was not because of your fault.

I believe in the latter theory and I have been working according to it for more than five years. It became so natural that I even forgot about it. Last week, my Scrum Master mentioned that we had different interests. I did not understand as we were working on the same project, on the same product. I asked explanation; but I did not receive it. The Scrum Master mentioned something about agile principles.

I have participated in Certified Scrum Product Owner training, where the trainer mentioned this conflict, as well.

I do not like such conflict of interest and I do not want it to be in my team. Conflict in the team... It sounds awful, does not it. I just cannot image a Product Owner or a Scrum Master, who want any conflict in their Scrum Team.

I believe that the entire Scrum Team exists and works in order to create an outstanding product. The members of the team have common interest, which is to reach the project goal. There should not be conflict of interest; there should not be unresolved conflicts inside the team. Of course, I admit that conflicts are useful, because they put problems in the spot light. However, conflicts must be resolved or avoided. I indeed believe it.

Into Scrum

My first Scrum project was an upgrade of an IT system with a system interface implementation and the implementation of some new features.

It was an experimental project from point of view of methodology. We wanted to try how we could work in Scrum. Of course, the tasks were real and we had to keep the budget.

We were self-confident after successful agile projects. Two developers joined the team. Our optimism infected them. It was why they waited to new methodology with excitement.

We solved our tasks in four two-week long sprints. The project itself was a great success. Of course we met challenges during the work. We discussed them on the Sprint Retrospectives, fairly successfully. I think they may be interesting to you, as well.

I was afraid of dividing stories among sprints. I just did not want the team have idling issues. In order to avoid it, everybody got an out-of-project task. In case of idling, they could work on these tasks.

The project was successful yet the first sprint failed because of the following reasons:

At this time, we did not have a tester; developers had to test their work. It was the first problem we met, nobody include test in the estimation of tasks. Developers forgot of the upgrading manuals and code commenting.

The spirit of the Daily Scrum also had to be changed after the first sprint. If any of developers had a problem during the preceding day and solved it, then he did not mention this problem on the following Daily Scrum. Such way, two or more developers got over the same problem. We agreed with informing each other about all solved problem. Also, developers were afraid of mentioning problems. They were fighting the problem until the last drops of blood, wasting their time.

The second sprint was successful, but we did not have any reserved time. During the sprint the team had to support an IT system and in case of urgent incident some of the team members had to go to work on the incident. These support activities were very frequent during the second sprint. The team was still shy to inform each other about the problem or to ask help from me. I did not mention I was the Product Owner and the Scrum Master at the same time. We were discussion about the individuals and the team and I thought that everybody understood that if one of us had a problem then all of us had the same problem.

After solving the problems of the first two sprints, the third sprint offered other challenges.

One of us, the new team member, was a night person. He was unable to arrive on time to the Daily Scrums. The team was waiting for 10 – 15 minutes each day. We decided to start Daily Scrums an hour later.

We met an interesting cascade effect problem. The tasks were built on each other. So, if the one of the tasks was late, then the whole story must have been late. The team suggested putting one task in one story, and according to their opinion the stories had to be independent. I refused this suggestion. First, such solution would have an effect on the Product Backlog. Second, it is impossible to have so many independent stories in a project. And last but not least, they still were thinking as individuals not a team. During the next sprint, everybody got a half-day off and we went to play an adult game (escape from the room) in order to be a team.

The last sprint was real success. The team had only remarks regarding the testing. The subject of the discussion was how to handle if the other developer’s tasks caused problems during the testing. Our proposal was that the developer who had written the erroneous code had to correct his code as soon as possible in order to avoid his mate’s idling.

In summary, the customer and our boss were content. The team was proud of their work, too. However, the team had a small problem, which would grow fast during the next common work. The team member, who was unable to come the morning meeting on time, earned other’s displeasure.

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.