If you ask someone in software engineering about their processes, you are likely to get some combination of the following responses:
- A slideshow walkthru of their release cycles and processes
- A rundown of tools implemented by various teams
- A repository of various artifacts generated through their delivery cycle that may reflect execution of the process steps
In other words, hints of an organization or team's processes typically exist in some combination of Powerpoint slides, collection of tools and evidence of process-related artifacts but not quite integrated into the environment itself.
The degree of details or comprehensiveness of the information you will encounter will depend a lot on the organization's process discipline and maturity.
The problem here is that these responses do not totally reflect what is really happening. At best, it reflects the intent of the process implementers (usually engineering managers) and generally a high level articulation of that intent. So you would either take their word for it or conduct a more thorough due diligence which would be an elaborate set of interviews, reviews of artifacts, delivery plans, etc. That is, if you are an outsider. If you are the one who has just joined the team, then the process learning is in itself an ongoing process. You will learn the processes mostly by getting involved with the team(s) through various exercises of maintenance cycles, patch fixes, release deliveries, and so on. In other words, there is a ramp up period for you which could easily take several weeks or months -- just to learn how to perform your tasks within the context of the team's process culture.
It is no wonder that teams are so often out of sync with respect to their processes. This is particularly an acute problem when teams are distributed. When outsourcing or offshoring, most teams do not even bother to align their processes. Teams adopt their own local process cultures.
As one would expect, this is a key contributor to high failure rates in software projects with offshore or distributed teams.
This problem exists because software engineering process definition, its integration into the lifecycle and tracking (for exceptions and compliance) -- are manually intensive and tedious. Diligent and disciplined managers are able to maintain some level of efficiencies with small local teams but their efforts quickly become unwieldy and impractical when the team size grows beyond 10-15, and when they introduce offshore teams into the mix.
Tool vendors do not tackle this problem because they are focused on their tools being adaptable across processes and methodologies. They do not care about what process you choose, nor do they impose one. They simply want you to be able to use their tools.
ALM vendors take a step forward by offering you an integrated environment that is committed to a certain methodology. Whatever the latest trends may be, you can find a vendor with an integrated environment that reflects a reasonable integrated representation of a lifecycle of that trend. Here, you have to commit to their methodology and their environment. You cannot mix paradigms.
So what do you do for your own environment? If you have chosen best of breed tools for your teams, and have implemented processes and methodologies that most closely reflect your business needs, teams' cultures and abilities -- how then do you effectively capture these processes and methodologies in sufficient details, reuse them, modify them, disseminate them to your teams, reduce their ramp up cycles, enact methodologies for specific projects, automatically have your tools configured to represent the processes, and track the process execution through a project lifecycle?
How indeed!!
Well, now there is a way :)
http://www.zagile.com/introductiontozcomposer.html
-Sanjiva, Orinda, Nov, '08.
Comments