A couple of weeks ago, I was peer reviewing some work by a colleague. I was struggling to communicate what was and what was not covered by the popular agile processes - what I call the scope of the process. For example, Scrum and eXtreme Programming essentially focus on a single small, cross-functional, development team. At a fundamental level, they do not cover larger teams or projects or organizations consisting of many small dependent teams. They say little about how customers or product owners decide on the business value and priority of the user stories or backlog items they create. Neither do they say much about working with a formal testing organization.
While there are plenty of suggestions and some popular approaches to extending Scrum and eXtreme Programming to cover multiple dependent teams, they are just that; extensions to the original core set of rules or practices.
Anyway rather than try and explain this by waving my hands around I resorted to drawing a picture to communicate what was in my head. Although very simplistic, it seemed to help so I thought I'd share it. If I have done it correctly, you should be able to click on the image below to see it full-size (legibly in other words) in a separate, pop-up window.
The green dashed box represents the scope of Scrum/XP and supporting tools like Borland TeamFocus today; sets of small independent teams working from their own backlogs.
The red dashed line represents the space where more and more organizations that have been using agile successfully for a while seem to be focusing. In these organizations individual development teams are working well. The result is that inefficiencies in working practices around the individual teams are starting to show up. This enlarged scope is closer to that covered by an approach like Feature-Driven Development (FDD) with broader demand management aspects informing the individual team product backlogs and collaboration across teams around an overall domain and technical architecture where appropriate. It is the space I see the combination of tools like Borland Team Demand and Team Focus being applicable, for example. Of course, we can't forget Borland Togetherfor recording and communicating the overall architecture as it emerges from collaborative design sessions.
Outside of the red dashed line are the activities that trigger new projects or changes to existing systems, and my colleague's interesting contention that this should all be inspired from a business process improvement perspective. He asserts that all IT development work should be about improving one or more steps in a process somewhere and if we understand our processes or our customer's business processes well enough we can use that knowledge to identify and prioritize development work. For example, Borland as a software tools vendor needs to understand the end-to-end processes involved with developing and delivering software. Identifying pain points, bottlenecks, opportunities for increased efficiency, etc, in those processes enables us to deliver genuinely useful and easy-to-use products.
What the picture does not show explicitly is the current interest in more sophisticated agile testing with tools like the Borland Silk suite. The idea is included implicitly in the Design, Build and VERIFY activities.
Also not shown are the measurement and analytic aspects that I view as another dimension to the picture entirely.
All suggestions for a better picture would be gratefully received.