From Alex Sutherland. No more need be said.

Get your papers ready for the January 2013 HICSS conference (in Maui)!  The Agile and Lean Organizations track will be one half day during the 4-day conference. HICSS is a conference with a wide-variety of researchers (not just software) interested in system-science—how things get invented, organized and completed. You'll have many opportunities to socialize with other speakers (barbecues, beaches and good food).  The papers are IEEE published so it's a good opportunity to get your work out to the world.  I hope you can join us.
Location Grand Wailea Maui
January 7-10, 2013 (Monday-Thursday)
Agile and Lean Organizations Mini-Track Agile and lean approaches promote iterative product releases and pull risk-reduction earlier in product development. Characteristics include: cross-functional teams, rapid outcome testing (such as automated testing in software), continuous quality monitoring and deployment, pairing (for software, pair-programming), bias-avoiding estimation, process improvement and short feedback loops. Advocates claim agile development produces greater staff resiliency, better release forecasting, fewer product failures and more sustainable work pace.
Lean product management methods test market hypotheses and rapidly adapt to discoveries.  Characteristics include: set-based design, A-B testing, unmoderated user-experience testing, direct market experimentation, customer validation and pivoting. Advocates claim lean product management produces greater market satisfaction, deeper customer engagement, earlier discovery of hidden market opportunities, higher revenues and more efficient resource utilization.
Advocates believe that sustainably agile/lean organizations must demand technical excellence everywhere (not just in software), promote individual and organizational change, organize knowledge, train employees in agile and lean philosophies, and optimize the whole value chain from concept to cash.
We seek research papers and experience reports that describe how agile development and lean product management affect organizational systems and outcomes. How do agile development and lean product management interact? How do organizations restructure to support these philosophies? When they do not restructure, what happens? How do markets respond to rapid iterations and end-user experimentation?
HICSS conferences are devoted to the most relevant advances in the information, computer, and system sciences, and encompass developments in both theory and practice. Accepted papers may be theoretical, conceptual, tutorial or descriptive in nature. Those selected for presentation will be included in the Conference Proceedings published by the IEEE Computer Society and maintained in the IEEE Digital Library.
How to Submit a Paper Follow Author Instructions posted on the conference web site: http://www.hicss.hawaii.edu/hicss_46/apahome46.htm.

• Select the correct track: “Agile and Lean Organizations” or “Agile/Lean Startup Organizations”
• HICSS papers must contain original material. They may not have been previously published, nor currently submitted elsewhere.  All submissions undergo a double-blind peer review process.
• Abstracts are optional, but strongly recommended. You may contact the Minitrack Chair(s) for guidance or verification of content.
• Submit a paper to only one Minitrack.  If a paper is submitted to more than one minitrack, then either paper may be rejected by either minitrack without consultation with author or other chairs. If you are not sure of the appropriate Minitrack, submit an abstract to the Track Chair(s) – see names and contact information below. for determination, and/or seek informal opinion(s) of Minitrack Chair(s) before submitting.
• Do not author or co-author more than 5 papers.  This means that an individual may be listed as author or co-author on no more than 5 submitted papers.  Track Chairs must approve any names added after submission or acceptance on August 15.

Important 2012 Deadlines for Authors DateDescription June 15Submit full manuscripts for review as instructed. The review is double-blind; therefore, this initial submission must be without author names. Aug 15Review System emails Acceptance Notices to authors. It is very important that at least one author of each accepted paper attend the conference. Therefore, all travel guarantees – including visa or your organization’s fiscal funding procedures – should begin immediately. Make sure your server accepts the review system address https://precisionconference.com/~hicss. Sept 15SUBMIT FINAL PAPER. Add author names to your paper, and submit your Final Paper for Publication to the site provided in your Acceptance Notice.  (This URL is not public  knowledge.) Oct 1Early Registration fee deadline. At least one author of each paper should register by this date in order secure publication in the Proceedings. Fees will increase on Oct 2 and Dec 2. Oct 15Papers without at least one paid-in-full registered author may be deleted from the Proceedings and not scheduled for presentation; authors will be so notified by the Conference Office. Cancellation and Refund Policy   All conference cancellation requests must be in writing.  A fee will be charged for cancellation of registration after Oct 15, at which time the paper is subject to withdrawal from the Proceedings.  There is no registration refund after Dec 1.  Cancellations for accommodations must be handled directly with the hotel.
HICSS-46 TRACK CHAIRS Software Technology
Gul Agha  agha@cs.uiuc.edu
Rick Kazman  kazman@hawaii.edu
Agile and Lean minitrack co-chairs Gabrielle Benefield
Evolve Beyond Limited
gbenefield@evolvebeyond.com

Dan R. Greening
Evolve Beyond LLC
dgreening@evolvebeyond.com

I have consistently found in my own companies and Openview Venture Partners companies that I coach that carefully prioritized implementation of acceptance tests produces higher quality faster than anything I have seen.

An Open-E in Poland they implemented continuous integration and immediately increased the velocity of over 50 developers by 20%. The next step was to improve the quality of their open source network storage server software so it could be released faster with fewer support problems. The software had to run on 80 different hardware platforms and needed thorough acceptance testing by a quality assurance team after development had completed a release. This acceptance test phase took 4-6 weeks per release.

I told them to proritize the problems encountered by the quality assurance team and implement tests in the build process to prevent these problems from ever appearing again. After 3 weeks of work by one developer there were 130 tests were running in the build process. The next release cycle cut quality assurance to 2 weeks and reduced support calls from the field by 50% saving millions of euros of development time and generating millions of euros in increased sales. Nothing I have seen works better than this.

Google has developed a brilliant automated strategy called "Bug Prediction" which does essentially the same thing. Seems like every team should be doing something like this.

Bug Prediction at Google What's the problem?
Here at Google, we have thousands of engineers working on our code base every day. In fact, as previously noted, 50% of the Google code base changes every month. That’s a lot of code and a lot of people. In order to ensure that our code base stays healthy, Google primarily employs unit testing and code review for all new check-ins. When a piece of code is ready for submission, not only should all the current tests pass, but new tests should also be written for any new functionality. Once the tests are green, the code reviewer swoops in to make sure that the code is doing what it is supposed to, and stamps the legendary “LGTM” (Looks Good To Me) on the submission, and the code can be checked in.

However, Googlers work every day on increasingly more complex problems, providing the features and availability that our users depend on. Some of these problems are necessarily difficult to grapple with, leading to code that is unavoidably difficult. Sometimes, that code works very well, and is deployed without incident. Other times, the code creates issues again and again, as developers try to wrestle with the problem. For the sake of this article, we'll call this second class of code “hot spots”. Perhaps a hot spot is resistant to unit testing, or maybe a very specific set of conditions can lead the code to fail. Usually, our diligent, experienced, and fearless code reviewers are able to spot any issues and resolve them. That said, we're all human, and sneaky bugs are still able to creep in. We found that it can be difficult to realize when someone is changing a hot spot versus generally harmless code. Additionally, as Google's code base and teams increase in size, it becomes more unlikely that the submitter and reviewer will even be aware that they're changing a hot spot.

In order to help identify these hot spots and warn developers, we looked at bug prediction. Bug prediction uses machine-learning and statistical analysis to try to guess whether a piece of code is potentially buggy or not, usually within some confidence range. Source-based metrics that could be used for prediction are how many lines of code, how many dependencies are required and whether those dependencies are cyclic. These can work well, but these metrics are going to flag our necessarily difficult, but otherwise innocuous code, as well as our hot spots. We're only worried about our hot spots, so how do we only find them? Well, we actually have a great, authoritative record of where code has been requiring fixes: our bug tracker and our source control commit log! The research (for example, FixCache) indicates that predicting bugs from the source history works very well, so we decided to deploy it at Google.


For details click here ...

Recently I visited Hank de Velde on his boat that he uses to sail solo around the world with Rini van Solingen, original author of "The Power of Scrum." Hank and I had similar ideas on planning for high risk adventures.

The official publication of "Software in 30 Days" is May 1. The book is a collaboration between the two creators of Scrum, Jeff Sutherland and Ken Schwaber. The goal of Scrum is to actually have working software at then end of each Sprint, which should be 30 days or less. Working software means tested, integrated, and ready to ship if necessary! This book shows you how it's done. It shows you how you can implement Scrum in your company, and how to improve the Agile practices you are already using. From the introduction:

We, Jeff and Ken, have been in the software industry, collectively, for seventy years. We have been software developers, managers in IT organizations and software product companies, and owners of both product companies and service organizations. More than twenty years ago, we created a process that lets organizations deliver software better. Since then we have helped hundreds of organizations do the same. Our work has spread farther than we have ever imagined possible, being put to use by millions of people. We are humbled by the extent of its adoption, and we are awed by the feats people have used it to accomplish.  This is not the first book we have written on the topic of building software. It is, however, the first book we have written for people who do not themselves build software. This book is instead for leaders within organizations that depend on software for their survival and competitiveness. It is for leaders within organizations that can benefit from developing software rapidly, incrementally, and with the best return on investment possible. It is for leaders who face business and technological complexity that has made the delivery of software difficult. We have written this book so that these leaders can help their organizations achieve these goals, enhance their internal capabilities, improve their product offerings, and more.  This book is for CEOs, executives, and senior managers who need their organizations to deliver better software in less time, with lower cost, with greater predictability, and with lower risk. For this audience, we have a message: You may have had negative experiences with software development in the past, but the industry has turned a corner. The software profession has radically improved its methods and its results. The uncertainty, risk, and waste to which you are accustomed are no longer par for the course. We have worked with many software organizations
that have already turned the corner; we want to help you do so, too.  The book is available at Amazon and Barnes and Noble, in print and e-book versions. The print version is also available at Powell's.

Update: Can't believe I forgot it, if you're in the Netherlands, here's the bol.com link. Also available on Amazon.co.uk and Amazon.co.de. Thanks @scrumnl!

When we first heard about teachers using Scrum in a classroom we had to know more and got in touch with those teachers through Ilja Heitlager at Schuberg Philis in the Netherlands. Here's what they sent in. It's translated into English from the original Dutch.


eduScrum in Dutch education
How it began … Imagine: you are a chemistry teacher at a school for secondary education. Your students work in groups on complex assignments, but you are not completely satisfied about the results of that teamwork. And then your son-in-law becomes a Scrum Master and you hear his enthusiastic stories… That is how it began.
How it continued … Willy Wijnands and Jan van Rossum, chemistry teachers at Ashram College (secondary education in Alphen aan den Rijn, the Netherlands) have been using an educational version of scrum since October 2011: eduScrum. They incorporate scrum into their lessons, to give students the opportunity to study more energetic and more effective. Using eduScrum also stimulates students to develop their strength as a team player.
Team work starts in their lessons with an introduction about confidence and an activity in which students talk about their personal capabilities and soft skills like punctuality, leadership capabilities, planning skills etc. After that, they form groups of four, set up to have additional capabilities. In this way, individual strengths in a team make individual weaknesses less relevant. Subsequently, they work in groups on the assignments of the context-rich chemistry module from a detailed sprint schedule.
Teacher: ‘I have indicated the number of time points per assignment (one point equals 10 minutes) and requested them to make an individual schedule. They have discussed those schedules and processed them into a group schedule. When I pointed out that I also wanted to do some whole-class teaching, they told me there was no time for it and that I should have announced it earlier. Wonderful, that much ownership. But they have to be in for it, because they have to learn to cope with unexpected events in their schedule.’

Group of four students, almost simultaneously: ‘This work is more pleasant in a group rather than individually. It is possible to ask each other questions and divide the tasks, which saves time. We have divided the experiments, because they are a good deal of work. But today we are going to work in groups of four during the entire lesson, because these assignments are very important and everyone should understand them. That is why we work together, it is something we have thought about during planning.’
Every group starts the lesson with a short scrum. This way they know what they have to do and where they stand to each other. A subsequent step is for them to learn to call each other to account, in case a group does not function optimally. The first step in doing this is a short but effective evaluation, executed by the groups themselves. Confidence in each other is the key theme in this evaluation.
Boy: ‘Our group consist of two boys and two girls. A group is useful when the group members co-operate. We’re fine in our group. Everyone takes his or her responsibility.’
Girl from the same group: ‘Everybody is contributing in our group. We have committed ourselves to do the work and we all are living up to it. We do our own tasks, and also work together. We do not study alone, if one of us does not understand, we explain to each other instead of asking the teacher. The information we have found we share with our group.’
From a Scrum perspective this might be trivial, but from a traditional educational perspective (focusing on the individual cognitive training) this is very special.
The plans for the future … Willy Wijnands and Jan van Rossum are working with with Ellen Reehorst, an education designer and trainer, to further develop eduScrum and to hand it over to other teachers later. Use these addresses to find out more:


www.eduscrum.nl
info@eduscrum.nl
@eduscrum on twitter

The Agile Manifesto is one of those documents that at one level is simple, but actually holds a lot of meaning:

Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan
Recently Microsoft asked Jeff to write about the principles and values behind the Agile Manifesto, and how they can be translated into real action.

Here's the section on Individuals and Interactions: Signers of the Agile Manifesto
Individuals and interactions are essential to high-performing teams. Studies of "communication saturation" during one project showed that, when no communication problems exist, teams can perform 50 times better than the industry average. To facilitate communication, agile methods rely on frequent inspect-and-adapt cycles. These cycles can range from every few minutes with pair programming, to every few hours with continuous integration, to every day with a daily standup meeting, to every iteration with a review and retrospective.

Just increasing the frequency of feedback and communication, however, is not enough to eliminate communication problems. These inspect-and-adapt cycles work well only when team members exhibit several key behaviors:

• respect for the worth of every person
• truth in every communication
• transparency of all data, actions, and decisions
• trust that each person will support the team
• commitment to the team and to the team’s goals

To foster these types of behavior, agile management must provide a supportive environment, team coaches must facilitate their inclusion, and team members must exhibit them. Only then can teams achieve their full 
potential.

Moving toward these types of behavior is more difficult than it might appear. Most teams avoid truth, transparency, and trust because of cultural norms or past negative experiences from conflict that was generated by honest communications. To combat these tendencies, leadership and team members must facilitate positive conflict. Doing so not only helps create productive behavior but also has several other benefits:

• Process improvement depends on the team to generate a list of impediments or problems in the organization, to face them squarely, and then to systematically eliminate them in priority order.
• Innovation occurs only with the free interchange of conflicting ideas, a phenomenon that was studied and documented by Takeuchi and Nonaka, the godfathers of Scrum.
• Aligning the team toward a common goal requires the team to surface and resolve conflicting agendas.
• Commitment to work together happens only when people agree on common goals and then struggle to improve both personally and as a team.

This last bullet, about commitment, is especially important. It is only when individuals and teams are committed that they feel accountable for delivering high value, which is the bottom line for software development teams. Agile methodologies facilitate commitment by encouraging teams to pull from a prioritized work list, manage their own work, and focus on improving their work practices. This practice is the basis of self-organization, which is the driving force for achieving results in an agile team.
To create high-performing teams, agile methodologies value individuals and interactions over processes and tools. Practically speaking, all of the agile methodologies seek to increase communication and collaboration through frequent inspect-and-adapt cycles. However, these cycles work only when agile leaders encourage the positive conflict that is needed to build a solid foundation of truth, transparency, trust, respect, and commitment on their agile teams.
You can go to Microsoft's site to read the whole thing.

Steve Denning has written a great post over at Forbes addressing some of the traditional management arguments against Scrum. His key point, I think.
"What’s wrong here is the corporate culture, not Agile. Surviving in today’s marketplace requires individual and team freedom. It translates into cross-functional work that is constantly adapting, with roles switching as needed. It also means adjusting processes continuously to reflect the current situation. In Agile, processes are secondary to the requirements of the work. Bureaucracy is the opposite: the requirements of the work—and the customer—are secondary to the bureaucracy. Not surprisingly, firms in this mode do a poor job of meeting customers’ needs. When the culture doesn’t fit Agile, the solution is not to reject Agile. The solution is to change the organizational culture. One doesn’t even have to look at the business results of firms using hierarchical bureaucracy to know that they are fatally ill. In today’s marketplace, they will need to change their culture or they will die. They need to become Agile." Steve has a lot more to say, go read the whole thing. More and more we're finding that traditional managers have to make the transition to Agile and Scrum...if they don't they'll be left behind. At Scrum Inc. we're addressing it in two ways. First, Jeff has completely re-invented the Certified Scrum Product Owner course, this one is based on legendary fighter pilot John Boyd's OODA loop. He's teaching it for just the second time in Boston at the end of May. And we've developed leadership workshops that focus directly on executive teams.


What's become really clear is that management no longer has the luxury of saying that Agile is for others. The science speaks pretty loudly, waterfall projects fail at such a greater rate than agile products, over and over again, that if businesses that don't make that switch aren't going to be around in the end. As Steve puts it, companies have to "change their culture, or they will die."

 
Yesterday, OpenView Venture Partners videotaped the Scrum metrics presentation that Scott Downey and I presented at Agile 2010. It consists of an animated slide presentation and an Excel spreadsheet that supports RoboCoach, the automated tool for generating a retrospective on your Scrum.
In the presentation, we fine tune the backlog and the Scrum meetings to help create a culture of hyperproductivity. It turns out that high performing teams are constantly removing impediments. As they go faster and faster the impediments become smaller and smaller, yet constant attention to removing them is critical. Failure to do this is similar to failure of the flight control computer in a high performance jet aircraft. It is always making slight adjustments to keep the aircraft stable. If the computer fails, the plane will spin out of control.
The metrics here are simple to collect and detailed in their capability to assess the stability of a team. For the first time we have comparable metrics across Scrum teams which are useful for identifying opportunities for coaching and improvement.
Videos of the Agile 2010 presentation can be found here. The latest RoboCoach spreadsheet can always be found on rapidscrum.com. The version of the presentation prepared for Openview can be downloaded here.

With waterfall failure after failure, even the government has decided to make Agile development a priority. Some people have a hard time believing this but I just want to take you through what happened in one department, the biggest one there is, the Department of Defense. Back in 2009 someone inserted this section into the 2010 Defense Acquisition Bill. These are the rules that the Department must follow when purchasing anything. Here’s the relevant section 804: IMPLEMENTATION OF NEW ACQUISITION PROCESS FOR INFORMATION TECHNOLOGY SYSTEMS.

The key language is this: (2) be designed to include— (A) early and continual involvement of the user; (B) multiple, rapidly executed increments or releases of capability; (C) early, successive prototyping to support an evolutionary approach; and (D) a modular, open-systems approach. Basically, for the DoD at least, Agile became the law. Here's the report the DoD returned to congress on how they would go about it:
The language here certainly sounds Agile to me:
•    Deliver Early and Often: This principle is aimed at changing the culture from one that is focused typically on a single delivery to a new model that comprises multiple deliveries to establish an environment that supports deployed capabilities every 12 to 18 months. •    Incremental and Iterative Development and Testing: This principle embraces the concept that incremental and iterative development and testing, including the use of prototyping, yield better outcomes than trying to deploy large complex IT network systems in one "Big Bang." •    Rationalized Requirements: User involvement is critical to the ultimate success of any IT  implementation, and user needs must be met. However, this principle also recognizes the need for users and requirements developers to embrace an enterprise focus across a portfolio of capabilities with established standards and open modular platforms vice customized solutions to ensure interoperability and seamless integration. •    Flexible/Tailored Processes: The Department's IT needs range from modernizing nuclear command and control systems to updating word processing systems on office computers. This principle acknowledges  unique types of IT acquisition and embraces flexible and tailored-and risk-appropriate-IT paths based on the characteristics of the proposed IT acquisition.
And while I don’t know exactly how Agile the DOD has become, this is the language their CIO is using on their modernization plans. The DoD CIO's 10 Point Plan for IT Modernization targets the most pressing, near-term challenges and presents approaches to efficiently and effectively deliver agile, secure, integrated, and responsive IT capabilities. This plan will enable the DoD to reduce costs and deliver faster, more responsive capabilities, while improving interoperability, user satisfaction, cyber security, and, ultimately, mission success. The primary goal is to enable agile, secure, efficient and effective IT for DoD. And if that doesn't convince you, here's an interesting bullet from a slide deck by the White House CIO, Steven VanRoekel on the administrations 2013 IT budget priorities:
Entrepreneurs in Residence
– Introduce and cultivate innovative best practices and technologies into
the Government
– Assemble agile teams to solve problems using rapid cycle, lean engineering principles There are other government agencies that have used Scrum to great effect, I know the FBI used it to rescue their Sentinel program from a complete waterfall failure, and I’m sure there are more. Anyone else know of any?

Also, if anyone knows of anybody who wants to take the next step in their career and get trained as a Scrum Master, there are still a few seats left for my Apr. 26-27 course in Boston.

California Scraps Massive Courts Software Project By Chris Kanaracus, IDG News California's Judicial Council has put the brakes on a long-running, massive software project that was supposed to modernize the state's trial courts case-management systems, saying the software is viable but that there's simply no money to continue installing it. An independent audit found that it would cost US$343 million to deploy and support CCMS version four to 11 courts through fiscal year 2020-2021, according to the Judicial Council. Some $333.3 million has been spent so far on the third and fourth versions of CCMS, it said."What we do best in the judicial branch is to weigh the evidence and make reasoned and deliberate decisions," Chief Justice Tani G. Cantil-Sakauye said in a statement. "The council's decision to stop deployment of CCMS was responsible and prudent in view of our budget situation and the facts we gathered on the actual costs of deployment. CCMS works. Unfortunately, we don't have the resources to deploy it." Earlier versions of CCMS are already implemented at a number of trial courts. But they aren't as advanced as version four, which can "handle all case types, provide for data exchange, and provide public access to cases across the state," according to a statement. The Judicial Council voted on Tuesday to continue supporting those earlier implementations. Now, the CCMS Internal Committee will make recommendations to the council for "other ways" to use the CCMS technology and the state's investment in it "as well as develop new strategies to assist courts with failing case management systems," according to a statement. The system's total cost had been estimated to be roughly $2 billion. More ... --------- Gartner is now recommending that waterfall be abandoned. You need to be a subscriber to get: Gartner - Technical Professional Advice 2012 Planning Guide: Application Delivery Strategies
Key points:

• Business users are losing patience with old-school IT culture. Relationships are tense and resentful. Legacy systems and practices impede agility. Bottom line - GET AGILE
• Adopt a product perspective.
• Say goodbye to waterfall.
• Improve cross-competency collaboration.
• Launch a deep usability discipline.
• Start a technical debt management program.

Why We Have to Go Back to a 40-Hour Work Week to Keep Our Sanity - Alternet by Sara Robinson One hundred fifty years of research proves that shorter work hours actually raise productivity and profits -- and overtime destroys them. So why do we still do this? March 13, 2012  |  
Photo Credit: gfpeck  If you’re lucky enough to have a job right now, you’re probably doing everything possible to hold onto it. If the boss asks you to work 50 hours, you work 55. If she asks for 60, you give up weeknights and Saturdays, and work 65.   Odds are that you’ve been doing this for months, if not years, probably at the expense of your family life, your exercise routine, your diet, your stress levels, and your sanity. You’re burned out, tired, achy, and utterly forgotten by your spouse, kids and dog. But you push on anyway, because everybody knows that working crazy hours is what it takes to prove that you’re “passionate” and “productive” and “a team player” — the kind of person who might just have a chance to survive the next round of layoffs. Read more ...

Why We Have to Go Back to a 40-Hour Work Week to Keep Our Sanity - Alternet by Sara Robinson One hundred fifty years of research proves that shorter work hours actually raise productivity and profits -- and overtime destroys them. So why do we still do this? March 13, 2012  |     Photo Credit: gfpeck  If you’re lucky enough to have a job right now, you’re probably doing everything possible to hold onto it. If the boss asks you to work 50 hours, you work 55. If she asks for 60, you give up weeknights and Saturdays, and work 65.   Odds are that you’ve been doing this for months, if not years, probably at the expense of your family life, your exercise routine, your diet, your stress levels, and your sanity. You’re burned out, tired, achy, and utterly forgotten by your spouse, kids and dog. But you push on anyway, because everybody knows that working crazy hours is what it takes to prove that you’re “passionate” and “productive” and “a team player” — the kind of person who might just have a chance to survive the next round of layoffs. Read more ...