敏捷思维和Scrum，哪个是第一位？

大多数决定走向敏捷开发的公司最终都使用Scrum作为敏捷开发的方法。他们认为在他们大部分的团队里面使用Scrum就能够给他们带来作为一个敏捷开发公司的所有好处，但是这样往往会导致一个令人失望的结局。最主要的问题是这些公司应该考虑一些其他的方式。在开始Scrum之前，必须确定的是他们愿意采取敏捷的思维方式。你可以采用Scrum，但是首先你必须是敏捷的。

Scrum是否应该解决我们的问题？

在我之前柏林的工作中，我们的团队有一个稳定的流程但是很少有自主权，我们依赖不同的团队，因此我们的能力被限制。所以我们认为Scrum可以使我们变得敏捷，相应的问题也会消失。

于是我们逐渐开始Scrum并开始每天开一次Scrum会议。紧接着，我们决定将我们的迭代周期设置为两周，也就是说每两周我们就应该有一个新发布。于是问题来了，对于其他团队的依赖性导致我们的Scrum变得一团糟。除了我们在冲刺结束的2-3天前准备好我们的软件外，QA团队并没有足够的时间来审核我们的发布，TechOps团队也没有足够的时间来部署。以至于我们仍然是每45天甚至更久才发布一个版本。Scrum给我们带来的唯一一个改变就是增加了一系列的会议，很快这些会议也就失去了他们该有的意义。

这使得我们的发布缩短至每20-30天一次，仍然远长于我们最初制定的两周一次迭代。公司发展的很快也有了很多新的项目，但是没有新的TechOps工程师，所以他们没有足够的时间去处理每个人的每件事情。

波兰的救援！

就是在这期间，我们项目的领导从阿姆斯特丹调到了波兰，新的管理者已经有几年的Scrum经验，他们知道为了改进我们的效率，我们需要避免对其他团队的依赖。

我们新的团队成员已经从开发到部署负责他们的产品一年多的时间了，在此之前，他们跟我们遇到过同样的问题。他们有一个很棒的解决方案：将项目迁移到AWS上。于是他们准备了一个很详细的预算，描述了迁移到AWS所需的费用并展示给了管理者。当他们看到这将会将我们的运维成本减少到一半的时候就欣然同意了这个方案。于是，在波兰团队的帮助下，我们能够在脱离对TechOps团队依赖的情况下同等程度的完成我们的工作。最终，在决定开始Scrum之后的四个月时，终于实现了每两周一个发布的目标。

结语

如果你想变得敏捷，只采用类似Scrum这样的开发框架是不够的，你必须改变思维方式，并且管理者也必须改变追求“万无一失”的观念。公司必须承担让团队变得跨领域且更自主所带来风险。如果在管理者和员工之间没有这样的信任，那么想实现敏捷开发就会变得更复杂。

我们很幸运有一个思维开放的管理团队，让我们负责整个开发过程也愿为此承担风险。如果你也同样幸运，不要再等了，赶快全面负责你的项目吧，你不会为这个决定后悔的。

敏捷思维和Scrum哪个是第一位？当然是敏捷思维啦。

英文原文：

What came first, Agile or Scrum?

Most companies that decide to go Agile, end up using Scrum as the highway to agility. They think that doing a Scrum process in most of their teams will give them all the benefits of being an agile company. Sadly, this usually ends up in nothing else than disappointment. The main problem is that companies should think the other way around. Before start doing Scrum, they must be sure that they are willing to adopt the agile mindset. You can DO Scrum, but first you must BE agile.

Scrum should solve our problems, shouldn’t it?

On a previous job I had in Berlin, our team had a smooth process but little autonomy. We were dependant on different teams and that was reducing our capacity. So we thought that doing Scrum we were going to become agile and this problems were going to disappear.

We started doing Scrum incrementally and started by doing a daily standup meeting. Later on, we decided to time-box our iterations to two weeks. So we decided that every two weeks, we should have a new release. And here is where problems arrived. Dependencies with other teams made our Scrum process a disaster. Besides we had our software ready 2 or 3 days before the end of the sprint, there was never enough time for the QA team to approve our release and for the TechOps team to deploy it. So instead of releasing every 2 weeks, we were still releasing every 45 days or more. The only thing that Scrum did to our process was introducing a bunch of meetings which lost their sense very quickly.

Developer? It doesn’t mean you can’t test

So the first step was trying to get rid of the QA team dependency. And the way we decided as a team to solve it was by asking the company for a TDDtraining. We thought that by incrementing our test coverage and presenting it nicely to management they would be convinced that we could do the QA job. After this we started having releases with 80% test coverage, and we were happy doing it. We felt that ownership of the project started to become ours. We convinced management that we could do the development and also the testing. The only thing the QA team should do was checking the continuous integration platform before every release and confirm that everything was green there.

This improved our process by releasing every 20-30 days. Still far from the two weeks cycle we pretended when we decided to do Scrum. The company was growing a lot and there were many new projects, but not many new TechOps engineers, so they had no time to handle everything for everybody.

Poland to the rescue!

It was during this time, that the leadership of our project was moved from Amsterdam to Łódź(Poland). The new management had already a few years working with Scrum, and they knew that in order to improve our performance we needed to remove any dependencies with external teams.

Our new team members had already more than 1 year being fully responsible for their product, from development to deployment. Before that, they had the same issues we had. So their smart move was to create a plan to move their project to Amazon’s cloud (AWS). So they prepared a detailed budget report of how much would it cost to host all their environments in AWS and presented it to management. And when management saw that the numbers would reduce operations cost by the half, guess what? Approved! So with the polish team help, we could do the same thing and finally removed our dependency with TechOps. And around 4 months after deciding to do Scrum, we achieved our “one release every two weeks” goal.

The Learning

If you want to become agile, it’s not enough to just use an agile framework like Scrum. You MUST change your mind and management MUST change their “failure safe” way of thinking. The company must take the risk of letting teams to be multidisciplinary and self-organised. If there is no trust between management and employees, becoming agile gets very complicated.

We were lucky to have an open minded management team which decided to take the risk and let us be fully responsible for the whole development process. So if you have the same luck, don’t waste your time and take full ownership of your project, you’ll never regret that decision.

What came first then, Agile of Scrum? Agile for sure.

本文作者Mauricio Payetta是点融网首席软件开发工程师，原Lending Club工程师，对于敏捷开发有着深入的研究。翻译水平有限，如果有不准确的地方请大家指正。

本文由 @Mauricio Payetta 原创发布于人人都是产品经理 ，未经许可，禁止转载。