HICSS 2010 Papers: Need Reviewers!

HICSS-43 PAPER SUBMISSIONS - Need reviewers with review deadline 14 Aug
Track: Software Technology
Minitrack: Agile Software Development: Lean, Distributed, and Scalable
Co-Chairs: Jeff Sutherland and Gabrielle Benefield
January 5-8, 2010
The Grand Hyatt Kauai Resort & Spa, Kaloa, Kauai, Hawaii

HICSS-43 offers a unique, highly interactive and professionally challenging environment that attendees find "very helpful -- lots of different perspectives and ideas as a result of discussion." HICSS sessions are comprised primarily of refereed paper presentations; the conference does not host vendor presentations. All papers are peer reviewed and accepted papers are published in the IEEE Digital Library.

Reviewers

1. You must have or create an account on the review site at: https://precisionconference.com/~hicss43

2. Then send an email to jeff at scruminc.com with the numbers of the papers below that you would like to review.

3. Reviews are easy and short using the form at the HICSS review site.

4. We like to get as many reviewers as possible for each paper to determine its usefulness to the agile community as well as its technical excellence.

Submitted Papers

Paper 468
Software Entropy in Agile Product Evolution
Abstract: As agile software development principles and methods are being adopted by large software product organizations it is extremely important to understand the role of software entropy. That is, how the maintainability of a system may degrade over time due to continuous change. It is important to understand how this, on one side affects the ability to act agile in planning and development, and how agile processes, on the other side, may affect growth of entropy. We report from a case study of a successful software product organization that has adopted the agile development method Evo. We explain how the agile process is negatively affected by a serious case of software entropy and, on the other hand how the agile process actually enforces this problem. Based on a thorough overview of relevant research we discuss how this situation can be resolved to release the full potential of agile software product evolution. 

Paper 696
Embodied Scrum
Abstract: In the same way it is not necessary for an ant to understand complex system theory to be a good ant, a
scrum master need only understand the rules of being a scrum “agent.” But unlike the ant, the scrum team member has an emergent sense of free will and agency that can make it difficult to embrace the simple and seemingly arbitrary rules of the scrum process. One approach to fostering an embrace of the bottom-up nature of scrum is to teach scrum masters the basic principles of complex systems theory, illustrating the power and ubiquity of self-organization, emergence, and adaptation. This paper represents one possible presentation of complex systems theory in accessible language, targeted to scrum masters. Additionally, a case is made for the relevance of first-person embodied practices for developing high quality sensory signal interpretation, i.e. radical empiricism.

Paper 465
Enterprise Scrum: Scaling Scrum to the Executive Level 
Abstract: Our company manages 25 teams across 6 products using a single top-down Enterprise Scrum. We know of no other company doing this, yet it provides extreme visibility and control at the CXO level. It promotes agile thinking enterprise-wide, driving non-engineering departments to adopt Scrum. We believe it is making us more profitable. We estimate effort in team months, run quarterly Sprints, assign whole teams to stories, meet in weekly stand-ups, etc. We start, postpone or cancel whole projects. When priorities compete, we often decide by comparing project profit margins, e.g., net-present-value over effort. Our President is the ultimate product owner. On the individual project level, we still use 2-4 week Sprints and all the trappings of the classic Scrum process. New challenges arise: Moving teams between projects requires rapid build environment setup. Architects must justify infrastructure projects with net-present-value. Our process became more “lean” to adapt mid-quarter.

Paper 849
Managing Breakdowns in Constructive Research: Method Re-configuration in Agile Systems Development
Abstract: A different set of skills and practices is needed in constructive research than in many other types of research. Often the actual construction and refinement of a certain IT-artifact often lies outside the scope of the core competency of the researcher(s). In order to realize constructive research involving the study of the construction of, as well as the use of, new artifacts need to be constituted by collaboration between diverse actors having different interests. In this paper the need for an increased understanding of how system developers should work in order to contribute successfully in constructive research is addressed. Due to the fact that such research aims to develop knowledge by creating something that does not exist, the need for flexibility and taking incremental steps in such development processes become essential. Based on a project involving researchers and system developers, ways to overcome breakdowns in such collaborative processes are developed.

Paper 959
Seven Dimensions of Agile Maturity in the Global Enterprise: A Case Study
Abstract: Agile rollouts often struggle to succeed in large complex organizations. This is often due to a misunderstanding of the complexity of interdependencies of vast disparate teams that often exist, resulting in limited local optimizations. Understanding and mapping the maturity of practices for interdependent teams and units provides a method to discover and remove bottlenecks between groups that enable the organization to continuously improve. Maturity mapped to a superset of XP-style technical and Agile program management practices appears to provide a powerful model for improving efficiency and alignment of cross-organizational engineering teams. This is a case study of the model developed by BT Design, the IT division of the telecommunications provider BT, which has been implemented across development streams comprising of hundreds of teams and components to improve organizational agility.

Paper 971
CAKE: A Knowledge Management Solution for Agile Teams
Abstract: Agile software development is based on a culture of abundance that does not always describe the organizations into which it is introduced. This paper addresses information paucity by describing a recent project to map data across tiers, systems, and organizational domains by developing a wiki-based tool and its supporting social processes. The entire system of people, tools, and information was named CAKE for “Community Authored Knowledge Exchange” and was built on principles of stabilization by weak links. These principles valued sustainability over optimization, participation over control, and openness over closure, but never lost sight of the contribution each side made to the final solution. Because these principles underlie the same weak links that stabilize agile teams, I believe the CAKE package of social processes, tools, and information can add real value to agile organizations.

Paper 1278
Rigorous Support for Flexible Planning of Product Releases — A Stakeholder-Centric Approach and its Initial Evaluation
Abstract: This paper addresses the problem of product release planning in iterative product development. We propose a method which combines decision, process, and tool support. The method, which is called SCERP, facilitates the active involvement of stakeholders in the different stages of the planning process. SCERP is flexible in the number of stakeholders involved, in the planning horizon, in the number and definition of planning criteria, and in the selection of the best plan out of a set of optimized alternatives. A proof-of-concept of the method is given by a case study of release planning for a tool called Agilefant, which is developed with a process partially based on Scrum. The benefits of the method as demonstrated by the case study are: (i) better decisions by the product owner by relying on more objective information, (ii) more transparency of release decisions, and (iii) efficient tool support accompanying the whole process.

Paper 1277
Towards Lightweight Requirements Documentation
Abstract: Most existing requirements management processes and associated tools are designed for document-driven software development and, thus, are unlikely to be adopted for the needs of an agile software development team. In this paper we discuss how and what can make traditional requirements documentation a lightweight and less heavy process, suitable for users requirements elicitation and feedback. Further, we propose a reference model for the requirements documentation phase and analyze what kind of requirements documentation tools are needed to support an agile software development process. We also present Vixtory, a tool derived and used for the documentation of lightweight requirements in agile web application development projects.

Paper 1397
Exploring the Transient Nature of Agile Project Management Practices
Abstract: Two large software projects provided background to this research. One investigated agile processes for development of innovative smart urban services targeting usability and user feedback, in a dozen of geographically dispersed city organizations (mostly in Europe) of various expertise and size, to be sharing a considerable part of the product and process technology. The other looked for agile management practices for big distributed projects with very short time to market. In both cases it was obvious that choosing project management practices should depend on context and system properties such as usability, time to market, feedback. The emergent practices were not final. The paper reports on our exploration of the transient nature of agile project management practices.