Aug 28 2011
How I read Maurits’ “Why Scrum will never work”
Recently, a blog post by Maurits called “Why Scrum will never work” broke the quite village of scrum and agile community in China. One of the popular technical blog called Coolshell translated the original post and also appended it with some translator Chen Hao’s thoughts who is a tech geek, one of my good friends.
As majority of the software development teams have already understood what agile is and how a team could benefit from agile adoption. It is regardless of other people’s view. It was my view too until I saw a question from Zhihu, the Chinese version of “Quora” that has been under development by Innovation Works (Chuangxin in Chinese) a company founded by Kai-Fu Lee.
Let me put my own view on Maurits’ 9 reasons of Why Scrum will never work.
Firstly, I personally do not believe that great methodologies or engineering practices are mandatory for creating successful products, especially small and simple products. Secondly I do not reckon that Scrum could go a long way without adopting widely-used engineering practices, such as continuous integration, automation tests, simple design, code review and etc.
In my mind, agile does not only mean the combination of scrum and Extreme programing but also a set of methodologies that could create goal driven, self motivated, self-organized and learning teams that is guided by lean principles. It is the reason that I chose helping many product teams to be better and better as my career.
Reason 1: I certainly agree that there are people out there who find that it is hard to trust someone at first place. I had experience that some of the team members did not want me to help them although the majority of the team members did desperately. Why? There are trust discrimination. You can read one of my blog posts about it (In Chinese). However it does not mean that this group of people would never to trust or intended to doubt you. If you had already read my blog, you would find out that they would trust someone else because “someone else” is either authorities, friends, family or engineers who share the same value, love the same culture. No one would disagree that un-trusted teams were virus, inefficient and one of the top reasons that project failed. So everyone dream or plan or is creating a trusted team. I am doing it now. It is not easy but you got to do it if you really do want to create great products, not waste your life. When you have a trusted team, you are half way to success.
Reason 2: Most of the software engineers are underpaid, really? Good software engineers got paid very well in companies like Huawei, Tencent, Chuangxin, Google, Facebook, Twitter, Amazon. You could give me a longer list if you spend more than 30 seconds. If you are good engineers, you even could create your own business, Mark Zuckerberg, Larry Page, Bill gates, those lads who own billions of dollars used to be engineers. Thousands and thousands of engineers created the miracle in Silicon Valley. BTW, they are still doing it. Yes! There are engineers who are underpaid unfortunately. If they have potential they would get better paid. If they believe they do but are still short of money, there are chances that they are not good engineers. They could be really good at architecting products but might not be good at engineering; good at programming but might not be good at communication. Being successful requires lots of skills and experience. You have to learn it as soon as you are free. BTW, everyone in the world believe that they are underpaid and it does not matter what you do for living. The only one that I heard did claim that they were overpaid was Warren Buffett
Reason 3: As the above reasons could not be proved itself, some teams need managers, some team could be self-organized. However, the best managers that I knew do not only do assigning tasks, managing developers. They create clear goals, coach inexperienced team mates. They certainly do not micromanage and they care about the results and leave enough space for mature teams to manage by themselves.
Reason 4: Scrum is not only a process, if you really read the book, practice it in more than 3 projects, you would certainly understand that scrum could help a team learn faster, get mature faster, make mistakes earlier, correct mistakes earlier even fail earlier. Experience people would create better teams. Intelligent people might not. I am not very clear about the definition of “Good people”. I guess that it means nice and experienced guys.
Reason 5: There are two types of projects roughly speaking, customized and public. Majority of the public products such as social network, search engine, online games have their product owners(managers). They care about their users’ feedback, they look their products like their own kids. On the other hand, customized software owners normally business manager in client organization might not care the products at all. But the ones who do, they delivered better results, they got better chance of promotion.
Reason 6: I watched a great presentation on TED a while ago. The speaker is a professor who did research of how to motivate knowledge workers. As the result, normally knowledge workers (e.g. software engineers) keen to improve themselves because they want to be more experienced, learned more knowledge and become senior. Compared to being a authorities in some areas they might care a bit less than the compensation that they would deserve. This is a lot different as the rest of the world. Knowledge workers are a group of special productivity.
Reason 7: Product owners focuses on “what” and “why”. The development team decide “how” BUT they also need to know what and why. It is misunderstanding of agile principle and methodologies. The first key thing that I did in my current agile organization transition project was to bring the key teams member to finalize project goals, key strategies, and etc then broadcasted to the whole team. It has been and always should be the first step of creating a goal driven team.
Of course there will always be deadlines, which help the business and development to find the miracle balance of value and investment. The whole nation of Chinese people are doing it,
finding the balance.
Quality is part of the product feature. Why? If there are bugs in one feature it means that it does not work, or in another word, it was not accomplished or developed. So maintaining good quality of a software equal to saving feature.
Reason 8: Unfortunately most of the teams that I worked with CARE a great deal of quality. Why? It does not because that Joe Average programmer got paid between 9 and 5. It is because they did not want to suck their own balls to fix hundreds bugs, working a lot of overtime to complete their own jobs. They do care because knowledge workers want to be professional and they do not want to be shamed about their work. They care about the faces.
Reason 9: Sadly it is the only reason that I totally agree. Agile methodologies do not suit for the government projects or fix bid projects. When I was an Operations Director of an IT company, I convinced my client to convert fix bid model to time and material. What was the difference? It gave my client more freedom and increased return of investment a lot. Did they care? Of course they did. Most of the government projects were managed under Prince II in the UK and waterfall in China. Because they are not using their own money, they use ours. They use our taxes. If you do not want your money to get wasted, try your best to convince your clients switching to agile.
In the end, I do not care if a project uses agile, scrum, waterfall, CMMI. I really don’t. What I care are “building great teams”, “deliver financial objectives”, “creating elegant products”, “satisfying customers”, “improving clients’ profitability”. It happened that agile along with other effective methodologies helped me to achieve the goals. What’s more? I want to see the happiness of the users who use my products, games, and everything my team and myself create.
Chinese translation:
近来，Maurits的一篇博文“Why Scrum will never work” 一石激起千层浪。著名技术分享网站酷壳（http://coolshell.cn/articles/5044.html）翻译了这篇文章，我的好朋友，网站创始人陈浩还加入了他的一些想法。
直到我看到在知乎（http://www.zhihu.com/question/19793669）上的一个问题之前，我也认为大多数软件开发团队已然知道敏捷是什么，可以给团队带来什么。他们可能完全不在乎别人怎么看敏捷。（注：知乎是李开复老师创新工场孵化的类似于Quora的一个中文问答网站）
说一下我对Maurits9个“Scrum永远不能成功的原因“的解读：
首先，我个人认为一个产品的成功和是不是使用什么方法论，工程实践没有必然联系，尤其是对于小而简单的产品更是如此。其次，我个人不认为在没有广泛应用的软件工程实践的支撑下Scrum可以持续不走样的保持下去。这些工程实践包括持续集成，自动化测试，简单设计，代码审查等等。
我个人理解，敏捷不单单是Scrum和极限编程的集合，而是一个以精益原则为基础，可以创造目标驱动，自我驱动和学习型的团队的一整套方法论。这也是我选择帮助很多产品团队不断完善自我作为我职业的原因。
原因1：我完全赞同，的确有些人很难在最开始相信别人。我也曾有过一个团队中的大多数人希望得到我的帮助，但是个别人非常抵制的经历。为什么会这样呢？因为“信任歧视”！你可以读我另外一篇博文有对这个话题的分析（http://blog.sina.com.cn/s/blog_626530940100mn3c.html）。但是这并不意味着，这些人永远不会或者故意不相信别人。如果您已经读过我的博客，你就知道他们其实相信某些人。这些人是领域专家，朋友，家庭成员或者和他们有共同价值观的工程师。任何人都不会否定，“团队中没有信任”是项目失败的首要原因之一，是毒药，也会造成工作效率低下。因此每个人都希望能建立一个互相信任的团队。我也在努力帮助团队互相信任。如果你想创造出牛X的产品，不想浪费你宝贵的生命，这就是一个非常有挑战但不得不做的任务。当你拥有这样一个团队，你成功一半了。
原因2：大多数软件工程师收入不高？在华为，腾讯，创新工场，Google, Facebook, Twitter, Amazon，好的工程师薪水很高。如果你花超过30秒时间，你会列出一个更长的名单。如果你是好的工程师，你甚至可以创业，自己当老板，Mark Zuckerberg（Facebook创始人），Larry Page（Google创始人），Bill Gates（微软创始人）这些拥有百亿身家的人都曾经是工程师。在硅谷成千上万的工程师创造暴富神话。并且，这些神话还在发生着。的确有工程师的薪水不高。如果他们是有潜力的，他们的薪水可能会上涨。如果他们自认为是好工程师，但是缺钱花，那我猜有可能他们不是好工程师。他们或许擅长架构设计，但是不擅长软件工程；或许代码写得很好，但是交流能力欠缺。成功是需要经验和技能的积累。你必须无时不刻的学习。并且，每个人，无论他所在什么行业都会抱怨老板应该给我更多报酬，近来我只听说一个人说他收入太高，政府应该多收他的税。这个人就是著名投资人巴菲特。
原因3：既然Maurits的原因2是悖论，一些团队需要管理者，一些可以自组织。很多我认识的非常好的管理者不单单是分任务，管理开发人员，对于他们来说更重要的是设定清晰目标，辅导缺乏经验的队员。他们的共性是不追求细节管理，但是结果考核，授权给团队去发挥。
原因4：Scrum不单单是一个流程，如果你读过这本书，并且在3个以上的项目中实践过Scrum的话，你一定会理解，Scrum可以帮助团队快速学习，快速成长，早犯错误，早改进，早失败，早总结。相对于聪明人来讲，有经验的人可以创造出更好的团队。我不太理解Maurits所说的”Good people”，我猜可能是和善，并且有经验的人吧。
原因5：项目或产品大致上分成两种，一种是定制开发，一种是面向大众的产品。大多数面向大众的产品，例如SNS，搜索引擎，电子商务，在线游戏都会有产品经理负责。他们非常关注用户反馈，他们把自己的产品当做自己的baby一样看待。大多数情况下，定制开发软件的决策者往往是客户方的业务经理，他们未必那么关心产品。我个人经验中，那些非常关注产品的业务经理往往得到更早的晋升。
原因6：我曾经在TED上看过一个演讲，演讲嘉宾是Dan Pink（http://www.ted.com/talks/dan_pink_on_motivation.html），他研究一个“如何激励知识工作者”的题目。其结论是：知识工作者通常情况下有意愿提高自己，因为他们希望成为更有经验的人，学习更多知识，变得更资深。相对于在某个领域成为专家的追求，他们对收入的诉求相对会小一点。这是一个和其他领域非常不同的群体。知识工作者是一个极为特殊的生产力。
原因7：产品经理专注与“做什么”和“为什么做”。开发团队专注于“如何做”，但是他们同样需要知道“做什么”和“为什么做”。Maurits的观点是对敏捷原则和方法论的一种片面的理解。我正在参与的一个敏捷组织转型项目中，我所作的第一件事情就是和项目核心成员共同确定项目目标，策略等，之后给团队所有成员解释。这是创建一个目标驱动团队的第一步也是必要一步。
“交付期限”是必须有的，它可以帮助业务部门和开发团队巧妙的找到投资回报的平衡点。中国人的文化就是这种“中庸”文化。
产品质量也是“功能”，为什么呢？如果某个功能有bug，这意味该功能不能使用，换句话说就是这个功能的开发没有完成。因此维护产品的质量等同于“挽救”功能。
原因8：幸运的是，大多数我曾工作过的项目“极其”在乎产品质量。为什么呢？其原因不是这些“平均水平”的工程师只朝九晚五的工作，而是因为他们并不想痛苦的加班加点的修bug。作为“知识工作者”他们希望自己更专业，更牛X，不想丢脸。
原因9：对于这条原因，我倒是不得不赞同。对于政府项目和固定预算固定范围的项目，敏捷不是一个合适的方法。当我在英国做一家IT公司的运营总监（COO）的时候，我说服了我的客户从这种固定时间固定范围的方法转换成按人天付费的方法。最大的区别是什么？这种新的方式给予我的客户更大的自由去争取更多的投资回报。他们在乎么？当然在乎！在英国，大多数的政府项目使用Prince II来管理，在中国瀑布模式还是主流。如果你不想你上缴的税收浪费掉，尽你最大的努力说服你的客户转向敏捷方式吧。
最后说几句，我真的不在乎一个项目是用敏捷，Scrum，瀑布或者CMMI，完全不在乎。我真正在乎的是“组建牛X团队”，“实现商业目标”，“创造出高品质产品”，“让客户满意”，“增强客户盈利能力”。恰好，包括敏捷在内的一些有效的方法论帮助我去实现了以上的目标。我更希望看到我们的用户在使用我们产品，玩我们的游戏的时候得到真正的开心和便捷。
//
