How Agile and Scrum are Destroying your Project.
2015 年 2 月 25 日
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.
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.
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.
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.
“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.
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.
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.