The primacy of work over tools explains why ALM 1.0 died quickly from its own success. Having convinced app dev teams of the value of point solutions for task management, planning testing, requirements, release management, and other functions, the obvious question on practically every customer's mind was, "What other tools might help us?" We should be careful about how we understand that question, which is not synonymous with, "What other activities might we make easier or more successful?" The tools are, more often than not, part of the same activity. Planning, for example, should identify risks that shape what requirements you write and what tests you build.

As an analyst, I hear this demand for ALM integration practically every day. When I have inquiry discussions with clients about ALM, the discussion inevitably moves beyond the boundaries of any one tool. For example, I recently had a telephone conversation that started with a question about user stories. The bigger question was the road map for Agile teams, which in spite of techniques such as epics and themes, may not be as clear to people outside of the team as it is for the team members themselves.