Management

[翻譯] 敏捷方法如何毀掉你的專案


https://www.linkedin.com/pulse/how-agile-scrum-destroying-your-project-gabriel-valles

How Agile and Scrum are Destroying your Project.
敏捷方法如何毀掉你的專案

2015 年 2 月 25 日
原作者:Gabriel Valles

Is your project suffering, wounded, or dying? Are you using all the trendy buzzwords, management techniques, and cute little sticky notes, but still feel off course? Are you hiding out in meetings “strategizing", but deep down you know that you have no idea how to salvage this sinking ship? Are you using platitudes like “Work smarter not harder" as a last-ditch effort to seem authoritative?
你的專案正在邁向死亡嗎?你是否正使用使用各種流行的管理方法,或是那些可愛的便利貼,但仍覺得實際上幫助不大。你是否假裝說我們不開會,但發自內心卻覺得救不了這艘船?你是否一再地使用"要做的聰明不是做的辛苦"這種陳腔濫調來授權管理?

After the seminar and certification you felt like you could take on the world and that your amorphous “manager" role now had direction. What went wrong?
在研討會及教育認證之後,你覺得你應該可以勝任管理者的角色,但到底哪裡做錯了?

What went wrong was that you were sold “Management and Development Techniques", but what you really got was scheduling and tracking techniques.
有問題的地方其實你只是被販賣了一個管理課程,但實際上只學到了排程與項目追蹤的技能。

Just because you are leading a meeting does not mean you are leading a project. The problem with Agile and Scrum is not the techniques themselves, parts of which may be useful. The problem is that these methods pretend to manage while leaving the true role of managing the project vacant.
開會的技能並不等於帶領團隊的技能。問題就在於敏捷的方法本身並沒有錯,部分是有用的。但問題是在於這些方法假裝團隊不需要管理者的情形之下作管理。

They also have subtle but equally destructive qualities that lean away from efficiency and toward bureaucracy.
而且這些方法還有同時毀滅性及狡滑的特質,讓團隊遠離效率走向官僚。

They mask the Pseudo-manager’s accountability. This allows the Pseudo-manager to make no decisions and still benefit from a successful production, because they ”trust them to get the job done.” Trusting your team is good, but managers also need to have technical knowledge of process creation, streamlining and the medium they are working in. This allows them to take a true leadership role and understand when a particular method is inappropriate. Providing an environment to “let them figure it out” is good, but it needs to be backed up with competent leadership.    敏捷方法把責任管理隱藏起來了。這個"不需要管理的管理者"開始不用做決策,但專案仍推進,因為我們相信團隊會把工作做好。當然信任團隊是一件好事,但是管理者仍然必須擁有生產產品的技術知識,工作流串接,以及產品媒體的知識。只有這樣才讓管理者能夠勝任這個工作,同時判斷各種方法到底是不是適合的。提供一個環境讓員工自己解決問題是理想的,但有時候必須用有權能的領導作為後盾。

The Pseudo-manager doesn’t have to be an expert in any of the disciplines; instead, they rely solely on each discipline’s lead manager’s expertise. The problem arises when you have a multi-disciplinary team that doesn’t know how to communicate. This is where the Pseudo-manager starts losing control of the project. They must hope that they have a team member that steps up and can control the situation. If no one rises up, the Pseudo-manager will not have the ability to get the project back on course. If someone does step up and rescues the project, he will get a pat on the back, but the Pseudo-manager and techniques will get all the credit and promotions.    “不需要管理的管理者"不需要任一種專業,相反地,團隊是依賴不同的專家提供的建議。但當一個跨領域的團隊不知道怎麼在不同專業間溝通時問題就會浮現。這時"不需要管理的管理者"就會發現專案開始失控。如果團隊中沒有人願意出來協調,缺乏專業的主管將無法將專案導回正途。假如真的有人出馬拯救這個專案了,他只會收到一句幹的好!然後"不需要管理的管理者"繼續收割成果。

They are self-insulating. The Pseudo-manager imposes unnecessary procedural burdens on production. The project will still get done despite, not because of them. This makes it appear as if the method worked, when in fact it was just a distraction.    敏捷方法讓團隊隔離了,"不需要管理的管理者"只是提出了一些其實製作上不必要的流程。當然專案依然會完成,但其實跟這些方法沒關係。敏捷方法弄得好像專案完成是因為這些方法,但其實這些方法只是讓團隊分心。

Some of the principles of Agile are so ambiguous, broad, or so obvious that they become non-principles, such as , “Continuous attention to technical excellence and good design enhances agility.”    敏捷的一些原則其實是很混淆的,不準確,或是大家都知道的東西,也就是說有跟沒有其實也沒關係,比如說:繼續專注在技術卓越,好的設計會加強靈活度。

They are designed to work in a software development environment where everyone speaks a common (programming) language. They break down when working in video games and multimedia where three or four more disciplines are present.    敏捷方法是設計來用在軟體開發環境的,團隊內都講同一種語言(技術),當運用在遊戲及多媒體產業時,團隊內其實有三到四種專業領域。

The most insidious quality is that these pseudo-management techniques leave a team rudderless, and before the project fails the Pseudo-manager has enough warning to sink back into the bureaucracy and start the process over again on a different project, while the rest of the team works inhumane hours on a death-march to unemployment.    在這個"不需要管理的管理技術"內最狡猾的特質就是讓團隊沒有方向,在專案失敗之前,管理者會得到警訊告,默默開啟另一個新專案,讓其他團隊用不人性的工時,沒有管理的情形下繼續往失敗衝刺。

A real manager is like a clock-maker. He coordinates hundreds of moving pieces and knows each function and how to engineer their efficiency. He seeks to understand all the moving parts of a production and to streamline inefficiencies out of the pipeline. There is no seminar formula for this. Ask questions, find problems and create solutions. Agile and Scrum are not clock-makers, and if used incorrectly it becomes obvious that they were one of the extraneous gears that was causing the watch not to work.
真正的管理者是一個精密手表的製作者。他們會協調上百個工作,知道每個工作的功能,工程師如何有效率工作。他們會試圖了解每個製程的部分,把無效率的部分移出。問問題,找問題,找方法不是上課可以學到的。敏捷方法並非製作手表,假如不適當的使用,顯然就會在製程中放入不需要的流程,導致團隊無法運作。

Have you seen this happen to your project? Am I totally off-base? Let me know in the comments.
你也看到這些在你團隊發生嗎?我說的是否正確,讓我知道你的意見。

請繼續閱讀第二部分。

In PART 2, I address some of the comments from PART 1 which you can read at this link.
在第二部分,我先補充第一部分Chris寫的意見。

Chris Wrote:

It seems disingenuous to claim that poor management is the fault of either agile or waterfall project management. A poor manager is a poor manager, period. Similarly, most managers believe – wrongly – that a project’s success or failure hinges on them. Here’s a test: remove the team – what is the outcome? Certain failure. Remove the manager – what’s the outcome? Maybe failure, maybe success. So – who’s to blame? The process or person?     這篇文章似乎聲稱不當管理是敏捷或瀑布式方法論的過錯一樣。不乏不會管理的人。相同,大多數的管理者錯誤的認為團隊的成功與失敗是他們所造就的。顯然移除團隊,這個專案顯然不會有任何產出。移除管理者也許還能有普通的產出。人的問題不應該歸咎給流程的問題。

Thanks for your comment Chris. The answer is that it is both the process and the person are to blame if a project fails. You are also correct in stating that a team could succeed without a manager.
感謝Chris的意見。我認為假如專案失敗的時候我們應該同時對流程及人的問題做出譴責。你的說法會在專案開始就沒有管理人員時還能成功時成立。

The major problem with these seminar style management techniques is that they tend to replace, what I call, “Production Engineering" with production/management techniques. The first seeks to understand all the moving parts and engineer a efficient process. The second seeks to impose techniques on a process that may not be correctly developed.
這些管理課程最大的問題是他們試圖把製造工程轉換為管理方法的問題。前者是找尋工程的效率瓶頸,後者則是試圖改變那些可能不正確的流程。

After 20+ years it has become very easy to spot a mismanaged production and pseudo-managers.
在二十年的開發經驗後,很容易分出甚麼是沒有人注意到的製程問題,甚麼是不做管理的管理者。

One good starting place is the filing structure and naming conventions. If these are disorganized and haphazard, chances are “management" missed a crucial phase in project-setup. It’s like Walmart with no inventory system. From this point you can usually uncover a systemic lack of oversight for the entire project.    簡單就是看檔案結構及命名規則,假如制定不良好或不確實實行,表示在專案開始時沒有管理。就像Walmart網站沒有購物車系統一樣。通常從小處就可以看到整個專案的控管失當。

Another sign is an MVP (minimum viable product) that is built without the ability to iterate quickly and is more like a rats-nest of code vs. clean components that can be easily removed or added.    另一個指標是原型的工程品質,因為此時還沒有迭代,到底是像垃圾堆一樣的程式碼,還是用清楚的元件系統寫出的。

A good way to spot a pseudo-manager is to track how much schedule/tracking contact they make with each discipline on a team vs. how much technical/problem-solving/process-creating contact they make. The first is a sure sign of a pseudo-manager.    發覺沒有做管理的好方法就是觀察是時程追蹤的訊息比較多,還是解決技術問題的訊息比較多。前者就是只做管理。

A good rule of thumb I use is: If you are NOT consistently learning from your manager you may be in a bureaucracy. One is an Administrator one is a Mentor. Administrators in technical disciplines are always useless.    我用的一個簡單的好方法就是:假如你沒有持續從你的管理者學到東西,那麼他就是一個官僚。試著分辨他只是一個橡皮圖章還是一個導師。在技術專案上的橡皮圖章永遠都是該捨棄的。

These are just a few ways to spot projects in trouble. There are many more.
這都是發現專案進入困難的方法。

Brian wrote:
另外Brian寫道

The recurring root cause of failed scrum projects is leadership. Only if there was a way to turn managers into solid agile leaders…     失敗的敏捷專案就是因為使用了舊時代的管理者。除非可以把管理者變為敏捷領袖。

Thanks for your comment Brian. I know you did not mean it this way, but unfortunately, this line of reasoning is what I call the “Escape Hatch" for people in the Agile/Scrum certification and consulting industries and it screams of bureaucratic CYA.
感謝Brian留言。我知道你其實意思不是這樣,不幸地,這段話其實正是我所說通過敏捷課程跑來當管理者那群人的推託之詞。

“It’s not the snake oil, its the way you used it." said the salesman.
業務員都會說:這是仙丹,只是你不會用而已。

When creating custom process you must build with the contingency that there will be trouble (lack of leadership, flakey clients, production delays, etc.)
當製作專案時,我們必須預備各種可能的意外事故。(譬如說沒有人來率領,找麻煩的客戶,時程延遲)

If Agile/Scrum only work in ideal situations that means they don’t work in the real world.
假如敏捷只能在理想狀況中運作,那表示它不適合這個真實世界。

Christin said:
Christin說到:

Valid points and yet having seen and been part of successful agile projects in games, we first need to recognize that agile was not developed with our kind of software in mind, creative elements just blow up a lot of it, and that bending the mold while staying true to what the principles are trying to help you create and foster is an important part of the process.     正確,還沒看到一個成功的敏捷遊戲專案,我們必須了解敏捷並非用來設計我們這種軟體,創意元素是來自靈感。流程不應該改變原本創造的環境,而醞釀是這個流程的重要部分。

Personally I think game projects are the most agile of agile projects in everyway but at the end of the day there are two elements that need to be there for success no mater what the process used – a leader with a clear vision who knows defined priorities matter and that by focusing on/communicating that vision, the team is an empowered partner in getting the project completed with the right set of features.     我個人覺得遊戲專案是最敏捷的專案,但少了這兩個元素就不成:具備清楚視野,專注並溝通此視野,能夠排定優先度的領導者;團隊被完全授權來完成那些遊戲特色。

Well said Christin. Agile was created in a Software (major)/ Art,Game Design, UI,UX (minor) environment.
Christin說的好。敏捷方法大部分適合軟體產業,小部分適合創意產業。

When Game Design, Art Production, Monetization and Software all move into the major category simultaneously the management dynamics change completely.
遊戲設計,美術繪製,付費點,軟體都放到一起時,常常需要動態調整優先度。

In Educational Software add Subject Matter Experts, and Writers and it gets even more unwieldy.
若在教育軟體的開發中,專家及作家常常就會覺得難以融入。

And yes, A leader with a clear vision and technical competence that inspires the team will supersede any process.
而沒錯,具備清楚視野的領導者在各種開發方法都很重要。

Agree? Disagree? Let me know in the comments.
同意嗎?留言讓我知道。

廣告

One thought on “[翻譯] 敏捷方法如何毀掉你的專案

發表迴響

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com Logo

您的留言將使用 WordPress.com 帳號。 登出 / 變更 )

Twitter picture

您的留言將使用 Twitter 帳號。 登出 / 變更 )

Facebook照片

您的留言將使用 Facebook 帳號。 登出 / 變更 )

Google+ photo

您的留言將使用 Google+ 帳號。 登出 / 變更 )

連結到 %s