Craig Larman 論敏捷與 Scrum
張恂 編譯序
最近國內某家知名大型軟體企業找到我和 Craig Larman，希望能請 Larman 和我一同組隊，為他們提供敏捷實施諮詢。他們同時交給 Larman 一份 RFP（Request For Proposals），請 Larman 提提建議。我們在這份 RFP 中發現了不少問題。於是，Craig 在與客戶和我的三方通訊中談到了到底什麼是敏捷，大中型組織和團隊實施敏捷時應該注意的地方。
我發覺，這篇短文對於我們國內的讀者、敏捷實踐者來說，無疑具有很高的指導價值。在徵得 Craig 的同意後，我對原文作了一些編譯，在此一併奉獻給大家。
敏捷價值觀
Scrum and agile is not a practice; it is a set of values that imply a deep understanding and learning by the leadership team, and then transformation of the culture and new behaviors by the senior management team based on the agile values.
The 4 agile values are:
1. Individuals and interactions over processes and tools
This implies a focus on the quality of empowered individuals, building great people with deep root-cause thinking skills, and on removing communication barriers, eliminating handoff and handover processes, eliminating separated functional teams, eliminating distributed teams, and so forth, and focusing on close communication and very close collaboration between product mgmt and R&D and business mgmt. And it implies that official defined processes and tools are not very important, and the belief that success comes primarily from a focus on defined processes (rather than individuals and interactions) is mistaken.
2. Working software over comprehensive documentation
That should be self explanatory.
3. Customer collaboration over contract negotiation
A 'contract' in this context does not really mean a commercial contract (though that is part of it); rather, it is implies all forms of specifications, plans, requirements documents, etc. This value says that the belief that focusing on formalized specifications or plans and handing them off to others, and on focusing on conforming to these 'contracts' (plans, etc.) is a mistaken focus -- it will not primarily lead to success. Rather, in agile values we focus on close collaboration, learning and discovery, and a daily interplay between (for example) product mgmt and R&D. We stop focusing on plans, specifications, etc, and instead focus on collaboration, discovery evolution.
4. Responding to change over following a plan
This value implies that we stop focusing on defining and conforming to "plans" (process definitions, gant-chart schedules, etc) and we stop focusing on prediction and conforming to predictions; rather, we focus on learning and evolution, developing a culture that emphasizes adaptation rather than conformance.
敏捷原則
There are also 12 agile principles. I don't have time to go into all of them, but some of the principles indicate the following:
* Self organizing teams
This implies the end of command-and-control mgmt. Teams self-organize and define themselves how they work to fulfill the goals of the iteration, and that they define their own process (each iteration) that helps them towards their goals. In Scrum, no mgmt is allowed to inspect, track, manage, or measure how teams work within an iteration.
* Empirical process
This implies the end of defined processes, and instead a culture of "4 week processes created by each team" based on inspect and adapt culture. There is no official corporate process (other than Scrum). Each team defines, owns and evolves their own 4-week process. At the end of each iteration, they do a retrospective and define a new 4-week process. The entire process culture expresses the Toyota mindset emphasized by the Toyota CEO, "Challenge everything, all the time. Do not accept the status quo of existing process practices."
* The end of sequential life cycles
In agile methods there is no Requirements Phase, Testing Phase, Integration Phase. There is no handoff of a specifications from one group to another, etc.
* Co-located cross-functional feature teams that together do the analysis, development, and testing of customer-centric end-2-end features
Agile thoughtleaders sometimes summarize all this as: you don't _do_ agile, you _be_ agile.
Please note this is not my opinion; this is what 'agile' is officially defined as -- by the Agile Manifesto. if you engage a consulting group that is not focusing on these messages and insight, you have not met a group that really understands agile methods.
大中型團隊的敏捷實施
Agile is not a practice that a development team adopts, it is a fundamental change in mindset of how to work by the leadership. In terms of effort and time, this usually involves, for an organization your (the customer's) size, between 2-4 years of intensive change initiative, focusing primarily on working with the leadership and senior product and business management groups. Adopting agile involves large-scale re-education away from traditional practices and processes and mindset, involving thousands of people needing to go through a transformation of understanding and behaviors, large-scale education of thousands of people in the Scrum method (through the CSM and Product Owner trainings, etc), based on the agile and scrum values -- and for most benefit, the lean thinking principles as well.
This is very different than what the RFP proposed, which implies the customer believes they understand what agile is, and the document implies 'agile' is viewed as a set of practices (rather than a set of values and mgmt behavior. changes), and that 'agile' can be adopted by a development group (rather than senior mgmt) and in a few weeks (rather than in terms of years), and that it can be recorded in a book or guide (rather than in a deep change in mindset).
Clients who engage me or the other real agile thoughtleaders start from the viewpoint of "we don't really know what agile is. would you like to come and explain and guide us, and advise on next steps?" This is related to the 3rd agile value: "customer collaboration over contract negotiation." What is needed in a real agile transformation RFP is a focus on the senior mgmt wanting to learn -- a discovery process guided by good coaches of your leadership team. The RFP would indicate a focus on working primarily (to start with) the senior leadership teams and on learning/guidance.
regards, craig
www.craiglarman.com
author of:
- (next) Scaling Lean and Agile Development: Successful Large, Multisite & Offshore Products
- Agile and Iterative Development: a Manager's Guide