Dr. Dobb‘s | Scaling Scrum | （三）

Enterprise Concerns
Most IT departments have numerous systems in production, many currentlyin development, and many more under consideration. The implication isthat to be truly effective you need to take the cross-system ITlifecycle into account, not just the system lifecycle. Yes, lettingyour architecture evolve over time is a great concept, but wouldn‘t itbe great to take advantage of a common architecture and reusableassets? Yes, we want to implement requirements in priority order toachieve the highest return on investment (ROI) possible for thatsystem, but wouldn‘t it be nice to work on the most important projectsto begin with? Yes, it‘s nice that we can mock out access to datasources, but wouldn‘t it be great to easily work with existing datasources so that we don‘t have to create yet another silo database? Yes,retrospectives are great ways to identify potential improvements for ateam to adopt, but shouldn‘t we have a mechanism to share thosefindings with other teams? We need to look beyond the needs of singleproject teams; otherwise, we‘ve merely found ways to more efficientlycreate silo application, contributing to the overall maintenance burdenwithin your organization.
You can, and should, be as agile as possible at these activities, and yes, you can choose to do so. A few years ago, I wrote The Enterprise Unified Process(Pearson Education, 2005) with Mike Vizdos, which described how toaddress the range of enterprise-level issues in as agile a manner aspossible. The goal of these enterprise activities should be to supportthe overall organization as well as to enhance the efforts of projectteams. The good news is that we‘re seeing greater focus onenterprise-level issues within the agile community. The bad news isthat we seem to be reinventing the wheel. We don‘t need to becausethere‘s a lot of great material out there if we only choose to leverageit. The EUP clearly takes a lightweight, collaborative approach toenterprise activities, and the Information Technology InformationLibrary (ITIL) v3 provides even greater detail if you‘re interested.You can find out more about the EUP atwww.enterpriseunifiedprocess.com and about ITIL atwww.itil-officialsite.com.
Agile@Scale
There‘s a lot more to software development than the constructionlifecycle of Figure 1. Let‘s not get fooled by marketing rhetoric andlet‘s not think that we need to reinvent the wheel just because we havea new generation of methodologists who are in the process of figuringthings out yet again. There‘s a lot of value in , but we need to approach it with open eyes and recognize that it‘s only one part of the overall IT process solution.
Normalizing the Terminology
Scrum uses some strange terminology, a strategy that has its advantages and disadvantages. The primary advantage is that it helps people new to agile development to break out of their preconceptions as to how things should work. Yet this comes at a price. People initially find the terminology to be confusing because it really doesn‘t make much sense. For example, nobody "sprints" through a long-distance race. The term "Scrum Master" instantly evokes thoughts about someone wearing leather who whips people if they don‘t do what they‘re commanded, the exact opposite of what the role is really about. The term "Scrum meeting" makes no sense whatsoever to people who aren‘t familiar with rugby, and arguably "team huddle" or simply "daily stand-up" meetings are better terms. Worse yet, anyone who has ever played rugby will tell you that scrums are only fun up until the point that you get elbowed in the face. In short, more accurate terminology would be:
• Iteration or Time Box instead of Sprint.
• Coach or Team Leader instead of Scrum Master.
• Daily Stand-Up Meeting instead of Scrum Meeting.
—SWA