Last week I was visiting a software development company in L’viv (Ukraine) and had a business dinner with the CEO of the company. During the dinner we talked about software development processes and how they were implemented in his company. The subject turned to the way the company implemented SCRUM.
First a little background information. About 6 months ago a project manager of this company was suggesting to me that he would like to implement SCRUM in the teams that are working for my employer. Since I was already a fan of SCRUM and was thinking about implementing it in our development teams as well I agreed with the suggestion and so we decided to implement SCRUM with the project manager, who was a certified SCRUM master, as the SCRUM master. Not happy with the results after a few months I decided to evaluate and look for improvements. It turned out that SCRUM was not implemented at all. The only thing of SCRUM that was used was the daily standup. The concepts of a product backlog, planning poker, sprint review, retrospective and planning meetings were still unknown to the team members and even though we decided to work in sprints of two weeks, because of the incomplete SCRUM implementation the team members did not even know when the sprint was finished or started. I decided to step into the driver seat myself and became SCRUM master of the 3 development teams we have. After a few months we are finally seeing the advantages in the quality and completeness of the deliverables and can look back to a successful start with the SCRUM process.
Now back to the discussion I was having with the CEO of this company. I asked him why his company did not use SCRUM. He replied with the remark that they only used the parts of SCRUM that suited their company and that he did not like the fact that SCRUM as a result make the company lose control over the development process. Not understanding what he meant I asked him to explain it further. He explained that in his view there were the following flaws in SCRUM:
- No documentation of specifications.
- No overall planning of the entire project.
- Functionality is prioritized by developers and not by business value.
- No up front overview of all functionality that will be implemented because everything is cut up in 2 week periods.
- Developers are in command of the project instead of the end customer.
I was surprised to hear this and asked him were he got this information. It turned out that his source of information regarding SCRUM were a group of developers. I gave him a short overview of the lifetime of a SCRUM project and all its concepts. We spoke about user story writing workshops, assigning business value to user stories, the concept of the product backlog, release backlog and sprint backlog and the role of the product owner in the SCRUM process.
At the end of the dinner he was intrigued about the possibilities of SCRUM and pleased to hear that it contains most, if not all aspects that, to his judgement, were needed to provide him with the control of software development projects that he is looking for. We ended the dinner with an appointment to discuss it into further detail and to see if and how it could be introduced in his company.
Now the clue to this post is that it is essential to retrieve your information from the right sources. I have no doubts that the developers that gave him the information about SCRUM had nothing but good intentions, but apparently their knowledge was limited to their own role in the process and that caused the company owner to get a one sighted blurred vision of SCRUM, not knowing what else it had to offer.