Enterprise Concerns
Most IT departments have numerous systems in production, many currently in development, and many more under consideration. The implication is that to be truly effective you need to take the cross-system IT lifecycle into account, not just the system lifecycle. Yes, letting your architecture evolve over time is a great concept, but wouldn't it be great to take advantage of a common architecture and reusable assets? Yes, we want to implement requirements in priority order to achieve the highest return on investment (ROI) possible for that system, but wouldn't it be nice to work on the most important projects to begin with? Yes, it's nice that we can mock out access to data sources, but wouldn't it be great to easily work with existing data sources so that we don't have to create yet another silo database? Yes, retrospectives are great ways to identify potential improvements for a team to adopt, but shouldn't we have a mechanism to share those findings with other teams? We need to look beyond the needs of single project teams; otherwise, we've merely found ways to more efficiently create silo application, contributing to the overall maintenance burden within 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 to address the range of enterprise-level issues in as agile a manner as possible. The goal of these enterprise activities should be to support the overall organization as well as to enhance the efforts of project teams. The good news is that we're seeing greater focus on enterprise-level issues within the agile community. The bad news is that we seem to be reinventing the wheel. We don't need to because there's a lot of great material out there if we only choose to leverage it. The EUP clearly takes a lightweight, collaborative approach to enterprise activities, and the Information Technology Information Library (ITIL) v3 provides even greater detail if you're interested. You can find out more about the EUP at www.enterpriseunifiedprocess.com and about ITIL at www.itil-officialsite.com.
Agile@Scale
There's a lot more to software development than the construction lifecycle of Figure 1. Let's not get fooled by marketing rhetoric and let's not think that we need to reinvent the wheel just because we have a new generation of methodologists who are in the process of figuring things out yet again. There's a lot of value in Scrum, 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 |
