A PRINCE for our times? Getting the best out of Agile development with DSDM

Perhaps one of the most obvious identifiers of a digital attitude to business change is a rapid and Agile approach to systems development. Over the years, ICT has developed a reputation for careful, methodical analysis, specification, and waterfall development of new business requirements. Skilled capture of user requirements, followed by a period of development and then presentation of the wonderful new solution. In certain situations this still makes sense. Infrastructural IT projects especially need the discipline of rigorous project management, critical path analysis, and a work package mentality to ensure complexity and integration are carefully managed. But time has also shown us that although users of systems are mostly best placed to describe their needs, these needs are often most well developed where the user can see a solution evolve, generating further ideas and requirements that can be incorporated. This has led to daily ‘stand-up’ meetings and the concept of a state of constant iterative and incremental development. So is it possible for the public sector to integrate its tried-and-trusted PRINCE2 approach to project management with the very different demands of an Agile development approach? We think it is, and have produced a research report in conjunction with the DSDM Consortium to provide practical advice on how we can bring the two approaches together as one

ADPM (advanced dynamic programme managment) The culture and management framework for business agility : white paper

SIGLEAvailable from British Library Document Supply Centre- DSC:m03/28271 / BLDSC - British Library Document Supply CentreVersion 2.0 finalGBUnited Kingdo

Simpler is better? Analysis of a codesign session with elders

Prototyping plays various roles in software engineering: it can function in an exploratory way in order to gather requirements, or generate an artifact that, through iterative cycles of development, leads to final delivery of the product or system. According to literature (Beaudouin-Lafon, M., and W. Mackay. 2007. “Prototyping Tools and Techniques.” In Human Computer Interaction Handbook: Fundamentals. CRC Press.; Lim, Y. K., E. Stolterman, and J. Tenenberg. 2008. “The anatomy of prototypes: Prototypes as filters, prototypes as manifestations of design ideas.” ACM Transactions on Computer-Human Interaction (TOCHI) 15 (2): 7.), a prototype can be described as an incomplete but flexible communication tool for a design idea, both manifesting and filtering interesting aspects of the original idea. On this basis, we propose a Peircean definition for this tool: a prototype can be considered as a complex set of signs, or better as a text, because each of its features literally “stands for” corresponding features of the final artifact, foreseeing particular aspects or the overall capacity of the outcome. But what happens when stakeholders involved in a project have no or little competence in tools and technologies discussed? Can they correctly interpret a prototype? To answer this question, we propose a Discourse Analysis (Duranti, A. 1997. Linguistic Anthropology. Cambridge, Mass: Cambridge University Press; Potter, J. 2004. “Discourse analysis as a way of analyzing naturally occurring talk.” In Qualitative research: Theory, Method and Practice, edited by D. Silverman, 200–221. SAGE; Schegloff, J. 1989. “Harvey Sacks’ lectures on conversation: an Introduction/memoir.” Human Studies 12: 185–209.) of a co-design session with elders of a daily centre for frail adults in Rome. In this context, we could observe how interactions between the material aspect of the prototype (i.e. the product itself) and its intended meaning (i.e. its significance) can produce distortions, in the form of aberrant interpretations or even a complete lack of comprehension. During this communication breakdown, prototypes lose their connection to the features and behaviors of the product: the relation between representamen and interpretant is lost