HICSS 42 Call for Papers due 15 June 2008

It's time for you to get your most scintillating Agile theories
together, write a kick-ass paper that could get published in the IEEE
library and spend a week in beautiful Hawaii next January. Sound good?
Then get writing!

HICSS-42 CALL FOR PAPERS - due 15 June 2008
http://www.hicss.hawaii.edu/hicss_42/minitracks/st-asd.htm
January 5-8, 2009
Hilton Waikoloa Village Resort
Waikoloa, Big Island, Hawaii

HICSS-42 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.

Software Technology Minitrack
Agile Software Development: Lean, Distributed, and Scalable
(Jeff Sutherland and Gabrielle Benefield)

Agile software development processes have been influenced by best
practices in Japanese industry, particularly by lean product
development principles implemented at companies like Honda and Toyota,
and knowledge management strategies developed by Takeuchi and Nonaka, now at the Hitotsubashi Business School in Japan, and Peter Senge at
MIT. This Minitrack will focus on advancing the state of the art or
presenting innovative ideas related to agile methods, individual
practices and tools.

Accepted papers will potentially enrich the body of knowledge and
influence the framework of thought in the field by investigating Agile
methods in a rigorous fashion.

We are open to research papers on multiple aspects of agile methods,
particularly those that bring best practices in knowledge management
and lean development to scalable, distributed, and outsourced Scrum,
eXtreme Programming (XP), and other agile practices. Topics include:

1. Research on existing or new methodologies and approaches: informal
modeling techniques and practices, adapting/trimming existing methods,
and new product/project planning techniques
2. Research on existing or new techniques or practices: pairing,
war-rooms, test-first design, paper-based prototyping, early
acceptance test driven development, exploratory testing, refactoring,
or others.
3. Research on special topics or tools: configuration and resource
management, testing, project steering, user involvement, design for
agility, virtual teams or others.
4. Research on integrating ideas from other fields, e.g. interaction
design, requirements engineering, cognitive science, organizational
psychology, usability testing, software security, into agile processes.
5. Research studies of development teams using ethnographic or social
6. Research on agile software engineering economics.
7. Quantitative and qualitative studies of agile methods, practices,
and tools.
8. Research on agile compliance and cost benefits within CMMI, ISO
9000, and FDA certified development projects.

Papers are particularly relevant when agile process implementations
are shown to produce quantitative and qualitative benefits on
distributed, outsourced, large, or standards compliant software
development projects which have been previously been viewed
(erroneously) as unsuited for agile development.

To submit papers and read more about the conference please go to:
http://www.hicss.hawaii.edu/hicss_42/minitracks/st-asd.htm

Jeff Sutherland
Scrum, Inc.
332 Congress St., 3rd Floor
Boston, MA 02210

Gabrielle Benefield
Scrum Training Institute
Mountain View,
CA 94040
Email: gabriellebenefield@yahoo.com

Agility and Organizational Patterns

In the early days of what we now know as Agile processes, Mike Beedle was influenced by the online description of Scrum, implemented the process in his own company, and led the effort to drive Scrum through the Pattern Languages of Programming Design conferences. This made Scrum the first (and only) formal organizational pattern that describes a complete Agile process. One of the patterns books contains the Scrum pattern:

M. Beedle, M. Devos, Y. Sharon, K. Schwaber, and J. Sutherland, "Scrum: A Pattern Language for Hyperproductive Software Development," in Pattern Languages of Program Design. vol. 4, N. Harrison, Ed. Boston: Addison-Wesley, 1999, pp. 637-651.

Recent work by Jim Coplien shows that Scrum is deceptively simply while compressing a complex array of organizational patterns in his book, "Organizational Patterns in Agile Software Development." Jim was surprised when he found that Scrum compresses at least 33 patterns from his book into a concept that can be explained in 2 minutes. It takes over 60 pages of rather dense text to describe these patterns.

One of Scrum's design goals was to encapsulate best practices from 40 years of software development into a process that was simple enough for the average IT worker to use for development in less than 2 days of startup time. Jim's research shows that we did a good job of accomplishing that goal. You can download a copy of the complete Scrum pattern as it is part of a draft of "The Scrum Papers."

Click here for Jim's presentation on Scrum as a set of patterns.

Agile Software Development: Lean, Distributed, and Scalable

HICSS 2008 Agile MiniTrack
Co-Chairs: Jeff Sutherland and Hubert Smits
HICSS 41, January 7-10, 2008 - Hilton Waikoloa Village Resort
Waikoloa, Big Island, Hawaii

If you are in Hawaii now, congratulations! If not, eat your heart out ...

ST 1 Thursday; Kona 3; 8:00 – 9:30

This session has three papers. Authors will have 15 minutes for presentation and 15 minutes for discussion. Papers will be presented in the following order.

Bridge Methods: Complementary Steps Integrating Agile Development Tools and Methods with Formal Process Methodologies
Stephen J. Cohen and William H. Money
Rolling Out Agile in a Large Enterprise
Gabrielle Benefield
Great Scrums Need Great Product Owners: Unbounded Collaboration and Collective Product Ownership (in competition for best paper)
Ken H. Judy and Ilio Krumins-Beens

ST 2 Thursday; Kona 3; 10:00 – 11:30'

This session has four papers. Authors will have 15 minutes for presentation and 10 minutes for discussion.

Effects of Agile Methods on Website Quality for Electronic Commerce
David F. Rico
A Case Study: Introducing eXtreme Programming in a US Government System Development Project
Ann Fruhling, Patrick McDonald, and Christopher Dunbar
Retrofitting Cyber Physical Systems for Survivability through External Coordination
Kun Xiao, Shangping Ren, and Kevin Kwiat
Scrum and CMMI Level 5: The Magic Potion for Code Warriors
Jeff Sutherland, Carsten Ruseng Jakobsen, and Kent Johnson

Douglas Crockford on The State of Ajax

In a recent Yahoo YUI video, Yahoo's Douglas Crockford gives an overview of the state of Ajax application development on the Web, and points to ways in which the Web can improve. Advertisement

Douglas Crockford, inventor of the JSON data exchange format, and Yahoo's chief DHTML evangelist, presents an overview of the State of Ajax and client-side Web development. Among the topics he discusses are Java, the flaws and benefits of JavaScript, why CSS should be replaced, why mashups are significant, and what can be done about Web technologies, such as HTML and JavaScript, that saw their last major updates in 1999.

Kleiner Perkins gets real on global warming

John Doerr gave a great talk on climate change at the recent TED conference. Check out "Seeking salvation and profit in greentech."

-----
John Doerr, a partner in famed VC firm Kleiner Perkins Caufield & Byers, made upwards of $1 billion picking dot-com stars like Amazon, Google, Compaq and Netscape. (He also picked some flops, like Go Corporation and the scandal-ridden MyCFO.com.) He was famously quoted saying, "The Internet is the greatest legal creation of wealth in history," right before the dot-com crash.

But now he's back, warning that carbon-dioxide-sputtering, gas-powered capitalism will destroy us all, and that going green may be the "biggest economic opportunity of the 21st century." So Kleiner Perkins has invested $200 million in so-called greentech, a combination of startups that are pioneering alternative energy, waste remediation and other schemes to prevent the coming environmental calamity. But Doerr is afraid that it might be too little, too late.

"[John Doerr] is, by all accounts, the most influential venture capitalist of his generation." Fast Company

Why Time Sheets are Lame ...

Programmer time vs. Quality Software Score. Totally uncorrelated!

Actually time sheets are worse than lame:
* they demotivate developers
* 10-15% loss of productivity is the minimum
* developers have to fake the time to fill them out properly
* erroneous data is used for reporting and management makes bad decisions
* customers are deceived
* they have nothing to do with quality code production
* they focus the whole organization on phony data instead of production

Nevertheless, this is not enough for many managers to give up time sheets. Just like the waterfall process, there is a psychological dependency so strong, it is as if they are on drugs.

However, the situation is even worse. Most management has completely wrong information in their head and thus continually make bad decisions. One of my students recently said to me, "You mean everything my manager told me is wrong!"

Yes, Jose, everything your manager ever told you is wrong:
* there is no correlation between developer time and software production
* there is no correlation between time spent and quality of code
* there is no relationship between "quality people" and code production

The only correlation between developer time and quality production code is the quality story points measured as a deliverable for a specific team.

Research over many years at Yale University provides some of the best data on this topic - see Joel on Software
:
* for a single project worst/best coding times are 1/10
* across many projects worst/best coding times are 1/25
* the ratios above are the same for the worst and best Yale students
* the quality of the code produced is completely independent of time spent

For some reason, many development managers makes decisions without any data at all on this issue and their assumptions are completely out of reality.

Tom Poppendieck told me recently a competent manager actually did some research on his XP teams to see what number of hours per week produced the maximum amount of quality production code. After trying shorter weeks and overtime weeks, the best number of hours for teams to produce the most quality code was a 16 hour work week!

Trust me, you need to dump those lame time sheets and get focused on real software production before an Agile competitor puts you out of business!

Scrum and CMMI Level 5: A Magic Potion for Code Warriors

An earlier blog item commented on the dramatic advantages of using Scrum with CMMI, particularly with a CMMI Level 5 company. See Scrum supports CMMI Level 5.

At the Agile 2007 Conference in Washington, D.C., an experience report was presented on the results of introducing Scrum into a CMMI Level 5 environment to replace waterfall projects for large defense and healthcare contracts. See Scrum and CMMI Level 5: A Magic Potion for Code Warriors. The paper was written by:

Jeff Sutherland, Ph.D. - Co-Creator of Scrum
Carsten Jakobsen - Systematic Software Engineering Process Leader
Kent Johnson - CMMI Level 5 Auditor

Systematic Software Engineering is a company which executes the waterfall process better than almost all companies in the world, with an ontime, on budget delivery rate of over 95% with estimates within 10% of actuals. The Scrum results were extraordinary, similar to introducing a team of Toyota consultants into a manufacturing plant. This was the result of driving the Scrum implemenation by lean principles which assured a disciplined and measured introduction of Agile practice.

- Productivity doubled in less than six months reducing total project costs by 50%.
- Defects were reduced by 40% in all Scrum projects (despite the fact this company already had one of the lowest defect rates in the world.)
- Planning costs were reduced by about 80%.
- User satisfaction and developer satifaction were much higher than comparable waterfall implementations.
- Projects were linearly scalable, something never seen before. The productivity of individual developers remains the same as the project increases in size.

The data in this study is some of the best in the industry and puts to rest the argument about whether the waterfall is preferable in some cases. The waterfall will always be less productive with higher defects on any project compared to a well executed Scrum.

Systematic Software engineering has revised its standard processes to use Scrum everywhere. See Scrum and CMMI Level 5: A Magic Potion for Code Warriors.