Abstract
In software development, there is an interplay between Software Process models and Software Process enactments. The former tends to be abstract descriptions or plans. The latter tends to be specific instantiations of some ideal procedure. In this paper, we examine the role of work artifacts and conversations in negotiating between prescriptions from a model and the contingencies that arise in an enactment. A qualitative field study at two Agile software development companies was conducted to investigate the role of artifacts in the software development work and the relationship between these artifacts and the Software Process. Documentation of software requirements is a major concern among software developers and software researchers. Agile software development denotes a different relationship to documentation, one that warrants investigation. Empirical findings are presented which suggest a new understanding of the relationship between artifacts and Software Process. The paper argues that Software Process is a generative system, which participants called “The Conversation,” that emerges out of the interplay between Software Process models and Software Process enactments.
This is a preview of subscription content, log in via an institution to check access.
Similar content being viewed by others
Notes
We found that many of our study participants distinguished Agile from other processes based on the role of documentation. They compared and contrasted different Software Processes in terms of documentation. For example, Brett, a Product Owner at Fast Tools gave a rundown of various processes: “Some software teams work collaboratively and iteratively but produce tons of documentation” doing “ten iterations of documentation with no software.” RUP (Rational Unified Process) is “lighter weight than Waterfall, you can redefine it, but it is still focused on... process and tools and documents.” In RUP, “you can choose between ten different suites of documents and tailor them to your specification.” And in Extreme Programming, “the XP person will say I don’t care [about documentation] it is whatever you want,” so there is “no guidance about documents.” Agile actually has a lot of guidance about documents in terms of what a user story should look like and how it should be used. But user stories tend not to be considered documentation in the same way.
The legacy code was called Whitney for Whitney Houston to denote that it was “all washed up” and the new code was called Ghidrah and was represented by a three-headed dragon figurine who “eats the legacy code” a reversal of saving the damsel in distress from the dragon.
References
Bansler, J. P., & Bødker, K. (1993). A reappraisal of structured analysis: design in an organizational context. ACM Transactions on Information Systems, 11(2), 165–193.
Beck, K. (2000). Extreme programming explained: Embrace change. Boston: Addison-Wesley Professional.
Bertelsen, O. W., & Bødker, S. (2002). Interaction through clusters of artefacts. 11th European Conference on Cognitive Ergonomics.
Boehm, B. (1981). Software engineering economics. Englewood Cliffs: Prentice-Hall.
Bourdieu, P. (1977). Outline of a theory of practice. Cambridge: Cambridge University Press.
Button, G., & Sharrock, W. (1992). The mundane work of writing and reading computer programs. Cambridge: Rank Xerox, EuroPARC.
Button, G., & Sharrock, W. (1994). Occasioned practices in the work of software engineers. In M. Jirotka & J. Goguen (Eds.), Requirements engineering: Social and technical issues. London: Academic Press Professional.
Cohn, M. (2004). User stories applied: For agile software development. Boston: Addison-Wesley Professional.
Dittrich, Y. (2002). Doing empirical research on software development: Finding a path between understanding, intervention, and method development. In Y. Dittrich, C. Floyd, & R. Klischewski (Eds.), Social thinking-software practice. Cambridge: MIT.
Feiler, P. H., & Humphrey, W. S. (1993). Software process development and enactment: Concepts and definitions. In Second International Conference on Continuous Software Process Improvement (pp. 28–40).
Fuggetta, A. (2000). Software process: A roadmap. In Proceedings of the conference on The Future of Software Engineering (pp. 25–34).
Giddens, A. (1979). Chapter 2: Agency, structure. In Central problems in social theory: action, structure, and contradiction in social analysis. University of California Press.
Larman, C., & Basili, V. R. (2003). Iterative and incremental software development. IEEE Software, 36(6), 47–56.
Latour, B. (1986). The powers of association. In Power, action and belief: A new sociology of knowledge (vol. 32, pp. 264–280).
Lee, C. P. (2007). Boundary negotiating artifacts: unbinding the Routine of boundary objects and embracing chaos in collaborative work. Journal of Computer Supported Cooperative Work, 18(3), 307–339.
Lofland, J., Snow, D. A., Anderson, L., & Lofland, L. H. (2005). Analyzing social settings: A guide to qualitative observation and analysis (4th ed.). Belmont: Wadsworth.
Naur, P. (1992). Computing: A human activity. New York: ACM.
Nørbjerg, J., & Kraft, P. (2002). Software practice is social practice. In Y. Dittrich, C. Floyd & R. Klischewski (Eds.), Social thinking—software practice. Cambridge: MIT.
Osterweil, L. (1987). Software processes are software too. In Proceedings of the 9th International Conference on Software Engineering (pp. 2–13).
Parnas, D. L., & Clements, P. C. (1986). A rational design process: how and why to fake it. IEEE Transactions on Software Engineering, 12(2), 251–257.
Pentland, B. T., & Feldman, M. S. (2005). Organizational routines as a unit of analysis. Industrial and Corporate Change, 14, 793–815.
Robinson, H., & Sharp, H. (2003). XP culture: Why the twelve practices both are and are not the most significant thing. Salt Lake City: Agile Development Conference.
Scacchi, W. (2001). Process models in software engineering. In J. Marciniak (Ed.), Encyclopedia of software engineering (2nd ed.). New York: Wiley.
Schwaber, K., & Beedle, M. (2001). Agile software development with SCRUM. Englewood Cliffs: Prentice Hall.
Sim, S. E., Alspaugh, T. A., & Al-Ani, B. (2008). Marginal notes on amethodical requirements engineering: What experts learned from experience. In Proceedings of the 2008 16th IEEE International Requirements Engineering Conference (pp. 105–114).
Star, S. L., & Griesemer, J. R. (1989). Institutional ecology, ‘translations’ and boundary objects: amateurs and professionals in Berkeley’s Museum of Vertebrate Zoology 1907–39. Social Studies of Science, 19, 387–420.
Truex, D., Baskerville, R., & Travis, J. (2000). Amethodical systems development: the deferred meaning of systems development methods. Accounting, Management and Information Technologies, 10(1), 53–79.
van Vliet, H. (2008). Software engineering: Principles and practice (3rd ed.). New York: Wiley.
Acknowledgements
We are indebted to our field sites and the participants who consented to be observed and interviewed. Many, many thanks to Rosalva Gallardo-Valencia who was instrumental in the data collection and transcription. Thanks also to Anahita Fazl who helped with the transcription. Yvonne Dittrich provided, reviewed and guided our research direction. This research has been funded in part by the National Science Foundation (Award IIS-0712994) and the Agile Alliance Academic Research Program.
Author information
Authors and Affiliations
Corresponding author
Rights and permissions
About this article
Cite this article
Cohn, M.L., Sim, S.E. & Lee, C.P. What Counts as Software Process? Negotiating the Boundary of Software Work Through Artifacts and Conversation. Comput Supported Coop Work 18, 401 (2009). https://doi.org/10.1007/s10606-009-9100-4
Received:
Accepted:
Published:
DOI: https://doi.org/10.1007/s10606-009-9100-4