Sunday, June 26, 2011

Reviewers needed for HICSS-45 Agile research papers

HICSS is one of the top conferences in paper citation index rankings. This means papers will be seen and used by researchers worldwide more than papers from other conferences. All HICSS papers are published in the IEEE Digital Library and are FREE to download, so accepted papers are accessible to everyone at any time, even by your grandchildren. No other conference can give you the same distribution of your concepts and ideas.

HICSS-45 REVIEWERS NEEDED - reviews due by 1 Aug 2011
January 4-7, 2012
The Grand Hyatt Kauai Resort and Spa
Kaloa, Kauai, Hawaii

Contact if you would like to review one or more of the four papers below. Please create an account at before emailing me with the numbers of the papers you would like to review.

Improving Trust in Information Systems Development Using Agile and Formal Practices (411)

Abstract: This paper posits that implementing a balanced portfolio of Agile and formal project practices will strongly support the cognitive trust-building processes and promote good development and O&M decision making for information systems, programs, and projects. The mechanisms enhance decision making by moderating the potentially negative effects of executive, managerial, development team, and end user distrust. Research has shown that establishing and maintaining an environment of trust can be improved by using well regarded effective trust supporting and trust building practices in appropriate situations that avoid a “Cargo Cult” mentality.
This paper argues for employing a set of trust building practices and processes from both formal and Agile methodologies that vary depending upon three factors; the need to develop a new or full replacement system, the experience of the user/purchasing organization with the development team, and the O&M status/working capabilities of the solution in use by the target organization. 

Evaluating and Improving Software Scalability (774)

Abstract: Scalability is an important but under-researched topic. Many organizations developing for the Web face the problem of measuring and predicting the scalability of the software systems they develop. Though the scalability problem seems quite prevalent, there is no widely accepted definition of software scalability in the current literature. There is also a lack of an accepted method to evaluate the scalability of a piece of software based on software bottlenecks. In this paper we first review the existing definitions of software scalability, analyse why they only partially match the scalability problem for software, and make an attempt to get at a definition of what is meant by software scalability. We use this definition of scalability to propose an approach to evaluate the software scalability of a Web application. We then test this evaluation approach in a case study of a software development organization.

Effect of Task Mental Models on Software Developer’s Performance: An Experimental Investigation (1195)

Abstract: This study provides some preliminary results on the efficacy of mental models in software development. Specifically, based on results from a controlled laboratory experiment, it shows that a software developer’s mental model quality is a determinant of software quality performance, regardless of whether the task is performed individually or in pairs. Further, this effect is found to be consistent across software tasks of varying complexity.

Investigating the Long-Term Acceptance of Agile Methodologies: An Empirical Study of Developer Perceptions in Scrum Projects (1327)

Abstract: Agile software development methodologies have gained huge interest in research and practice. However, since they set a polar opposite to traditional methodologies, their introduction hugely affects the working habits of developers. As agile methodologies postulate flat hierarchies and self-organizing teams, the long-term commitment of developers becomes a critical success factor. Yet, current studies primarily measure the success of agile methodologies in the short-term. In order to evaluate the use of agile methodologies in the long-term, we conducted a study at a world-leading insurance company which introduced Scrum back in 2007. Using qualitative research methods and the Diffusion of Innovations Theory as an analytical lens, we gained in-depth insights into the long-term use of Scrum. In particular, we were able to identify numerous factors which developers perceived as relative advantages or more compatible to their working processes. However, we also found factors regarding the complexity of Scrum which were perceived as drawbacks by developers.

Background on HICSS:

Now in its 45th year, the Hawaii International Conference on System Sciences (HICSS) is one of the longest-standing continuously running scientific conferences. This conference brings together researchers in an aloha-friendly atmosphere conducive to free exchange of scientific ideas. Unique characteristics of the conference include:
  • A matrix structure of tracks and themes that enables research on a rich mixture of computer-based applications and technologies.
  • Three days of research paper presentations and discussions in a workshop setting that promotes interaction leading to additional research.
  • A full day of Symposia, Workshops, and Tutorials. See Program Components for additional detail.
  • A truly international experience with participants usually from over 40 countries, (approximately 50% non-US).
  • Papers published in the Proceedings by the IEEE Computer Society Press and carried in the IEEE digital library Xplore. Access to HICSS papers is in the top 2% of IEEE Conferences.
  • Paper presentations and discussions which frequently lead to revised and extended papers that are published in journals, books, and special issues.
  • A keynote address and distinguished lecture which explore particularly relevant topics and concepts.
  • Best Paper Awards in each track which recognize superior research performance.
Recent research that shows HICSS ranked second in citation ranking among 18 Information Systems (IS) conferences[1], ranked third in value to the MIS field among 13 Management Information Systems (MIS) conferences[2], and ranked second in conference rating among 11 IS conferences[3]. See References.

The Australian Government's Excellence in Research project (ERA) has given HICSS an "A" rating, one of 32 Information Systems conferences so honored out of 241 (46-B and 146-C ratings). Data supplied by the Australian Research Council, December 2009. See

Sunday, June 12, 2011

Why a Good Product Owner Will Increase Revenue at Least 20%

Maurits Rijk did a Monte Carlo simulation of a project where implementation is not prioritized (blue) versus prioritized by return on investment (green). Value delivered is the region under the curve.

Interestingly, prioritizing only by business value (orange) and not accounting for cost lowers earned value but not as much as having an unprioritized backlog. Also doing the easiest stories first (red) delivers more value faster, even better than return on investment in this analysis. Whether a customer would like this strategy is open to question.

If you have a $100M company, a good product owner team can increase your revenue by over 20%. With 20M dollars you can afford the best product owner team on the planet.

We knew this previously from data published in the book "Software by Numbers" yet more than half the Scrum teams in the world have poor user stories - i.e bad product owners. Why do managers leave so much money on the table?

Maritz helped us do the analysis on a study of hyperproductive distributed/outsourced teams where each team is half onshore and half offshore. The simulation reflects a typical situation for his high performing teams.

Tuesday, June 07, 2011

What is Preventing your Retrospectives from having an Impact?

Guest blog by Scott Maxwell, OpenView Partners.
Scott is the managing partner of OpenView and has introduced Scrum everywhere in the venture group and the portfolio companies. See Take no Prisoners: How a Venture Capital Group Does Scrum.

Ret­ro­spec­tives, and their close cousin After Action Reviews (AARs), are sim­ple prac­tices that offer you a quick, easy, and efficient way to con­tin­u­ously improve. They can be for­mal or infor­mal, can take place after any action/project/initiative or on a reg­u­lar sched­ule, and can be eas­ily adapted to meet the needs of your organization.
Lack of buy-in and/or com­mit­ment from the top, which will make your employ­ees believe that it is not a pri­or­ity. Com­mu­ni­cate to employ­ees why you are doing this and the ben­e­fits you expect to achieve. Allot the proper time for ret­ro­spec­tives. Ensure that teams are stay­ing dis­ci­plined with the prac­tice and not rush­ing through the process.
Peo­ple may per­ceive that reflec­tions are about indi­vid­ual per­for­mance and assign­ing blame, and there­fore become overly self pro­tec­tive. Rein­force that ret­ro­spec­tives are about team per­for­mance, not indi­vid­ual per­for­mance, and about find­ing ways to improve. A key ben­e­fit is that when done right, reflec­tions make teams stronger, not the reverse.
For many dif­fer­ent rea­sons – some cul­tural, some man­age­r­ial, some inter­per­sonal – peo­ple won’t say what is truly on their minds. It takes time to build a cli­mate of trust. But if the team mem­bers fail to speak the truth, the improve­ments will never be as good as they could be. If there are cer­tain peo­ple you know are not being hon­est, take them aside to talk in pri­vate about their concerns.
The meet­ings get off track. The facil­i­ta­tor should set and enforce ground rules. The meet­ings should be struc­tured to pre­vent team mem­bers from ram­bling and going off topic. Facil­i­ta­tion is both a skill and an art; facil­i­ta­tors need train­ing, but they also should have a nat­ural gift for communicating.
No ideas for improve­ment are offered. At Toy­ota, even if a project is suc­cess­ful, a hansei-kai (reflec­tion meet­ing) still takes place. They have a say­ing that “no prob­lem is a prob­lem,” and believe that no mat­ter how good some­thing is, there is always some­thing that can be improved. If the team is stuck, the facil­i­ta­tor can uncover prob­lems by ask­ing “why” many times over while dis­cussing how a project or process unfolded.
Ideas for improve­ment are given, but are not spe­cific enough. The facil­i­ta­tor should get the team mem­bers to make spe­cific state­ments. For exam­ple, a gen­eral state­ment such as “we need faster ser­vice from our proof­reader,” could be reframed as “our proof­reader needs to e-mail the marked up proofs to John within 24 hours.”
Too many ideas for improve­ment are offered. Team mem­bers should choose 3 areas to focus on and imme­di­ately imple­ment. The facil­i­ta­tor should put the addi­tional ideas into an idea back­log for fur­ther dis­cus­sion at the next retrospective.

See also the OpenView ebook on retrospectives.