The practice of continuous integration facilitates early visibility into the development process by regularly incorporating new modules into the build much earlier than the classic “big bang” integration approach. Continuous integration helps reduce the time between when a defect is coded and when it is discovered, thereby making it faster and easier to repair. Software teams see their build process as much more than a simple compile and link process because the build exposes new bugs immediately. In addition, builds can be augmented with a set of “software inspectors” that report on aspects of software quality including code complexity, duplication, dependences, and adherence to standards. Andrew Glover describes the practice of continuous integration and the tools available for both Java and .NET platforms. Learn how to interpret the data provided by software inspectors and how to make improvement actions based on that data.

When some people hear the words “agile planning,” they think it is an oxymoron. While more knowledgeable people think of agile planning as getting ready for one iteration of development, there is more to agile product planning than a single iteration. Although agile teams like to focus on one iteration at a time, what do we say when executive management asks questions like “What will this product actually do?” or “When will it be ready for the customer?” or “How much will it cost?” When the answer “You’ll get it when you get it” just won’t sell, you must perform high-level release planning to address these important questions. Stacia Broderick describes an agile release planning framework under which agile development can be effective. Stacia takes you through the complete process she recommends for release planning and explains, most importantly, why and how the agile release plan can and must remain just that—agile.

The Lean movement, instituted in the 1950s with Toyota’s redefinition of automobile production, has knocked the manufacturing world on its ear. At the core of the Lean movement is the notion of eliminating waste as the key to creating added value. What is not well understood is the role that quality plays in defining many of the core Lean Thinking practices. Practices such as Stop the Line, Zero Defects, and Reduced Inventory all focus teams on quality. These practices not only increase quality but also are the scaffolding for a continuous flow of customer value. Jean Tabaka explores the basics of Lean Thinking and how it relates to software development—how customer value drives product quality, how product quality can drive software development practices, and how software teams create value and deliver quality by attacking the seven wastes in software development.

Service Oriented Architecture (SOA) based on Web Services standards has ushered in a new era of how applications are being designed, developed, and deployed. SOA’s promise to enable the development of applications that are built by combining loosely coupled and interoperable services poses new challenges for testers and everyone involved with the software reliability and security. Among the challenges are dealing with multiple Web Services standards and implementations, legacy applications (of unknown quality) now exposed as Web services, weak or non-existent security controls, and services of possibly diverse origins chained together to create dynamic application implementations. Join Rizwan Mallal to learn concepts, skills, and powerful techniques—WSDL chaining, schema mutation, and automated filtration—needed to meet these challenges. Learn how traditional techniques such as black, gray, and white-box testing are applied to SOA testing to maximize test coverage, reduce effort, and release better products.

Accurately measuring product quality and process capabilities is challenging in any software organization. Most organizations do not attempt any real measurement at all, and the ones that do often fail miserably. In fact, the industry success rate for software measurement programs is terribly low— some say less than 25%. Ian Brown presents ten keys to measurement success, including: having people dedicated to measurement work rather than those assigned part-time, a strong commitment from senior management, measurements directly related to articulated business goals, automated measurement collection tools, integrating measurement into the process rather than tacked on, and more. Based on the successes of Booz Allen Hamilton, learn how to start small and slowly grow your measurement program to build success on top of success. Begin your journey to a better measurement program and take back a set of measurements that are “safe” and non-threatening to individuals.

YOUR CHANCE TO SPEAK AT THE BETTER SOFTWARE CONFERENCE & EXPO!
Lightning Talks are nine five-minute talks in a fifty-minute time period. Lightning Talks represent a much smaller investment of time than track speaking and offer the chance to try conference speaking without the heavy commitment or attendant nerves. Lightning Talks are an opportunity to quickly present your single, biggest, bang-for-the-buck idea. Maybe you just want to ask a question, invite people to help you with your project, boast about something you did, or tell a short cautionary story. These things are all interesting and worth talking about, but there might not be enough to say about them to fill up a full track presentation. Use this as your opportunity to give a first time talk or to present a new topic for the first time.

Today’s tools and techniques for software development tend to focus on individual products. However, customer demands require most companies to offer a software product line portfolio—a collection of related products with variations in features and functions—rather than just a single product. This situation has led to the emergence of development methods, tools, and techniques focused specifically on the challenges of software product line development. Charles Krueger explores this latest generation of software development methods that are yielding an order-of-magnitude improvement in time-to-market, engineering cost, product quality, and portfolio scalability. Charles shares the best methods from recent industry case studies, including model-driven, aspect-oriented, minimally-invasive, and agile strategies. Learn innovative, proven software product line development methods, as well as practical approaches for getting started.

With the increasing deployment in agile development methods, many teams and organizations are learning about the practice of refactoring as an integral part of development. Refactoring is the process of changing a software system in such a way that it does not alter its external behavior yet improves its internal structure. Join Alan Shalloway as he discusses that, although refactoring is valuable in and of itself, it can be made even more powerful when complemented with the lessons learned from proven design patterns. Refactoring actually comes in two flavors: improving poor code, and turning good code into better code when requirements change. The dual practices of refining design and improving code will enable your software to retain the vibrancy that is essential to code flexibility and longevity. Understanding refactoring and design patterns enhances agile methods considerably and can be a key practice in non-agile development as well.

Organizations have traditionally relied on project postmortems to assess the performance of product development teams. The irony is that “postmortem” literally means “after death,” implying a discussion of project failures. These reviews, held at the end—either the completion or cancellation—of a project, often do not create a safe environment for team members to express their opinions. Postmortems rarely result in fundamental improvements in the development process as “lessons learned” sessions quickly become “lessons forgotten.” And because they come at the end of the project, they have no chance to positively impact the current project. John Terzakis introduces the concept of retrospectives to address these problems and contrasts these two review methods. John describes the benefits of conducting multiple retrospectives within the product life cycle, the four phases of the retrospective process, and the role of the retrospective facilitator. Implement retrospectives in your current and future projects to lead your organization toward a culture of continuous improvement, increased effectiveness, and improved harmony within the development teams.

Service Oriented Architecture (SOA) is becoming a widely adopted approach for enterprises to attain agility and economy while meeting their Information Technology (IT) needs. Unlike previous attempts at component based software development efforts, development in SOA environments stresses code reuse through development, deployment, and orchestration standards. Frank Cohen explains the major trends currently in play that impact the use of XML in SOA and how a new base of computing technology using composite applications, Registry/Repository, Enterprise Service Bus (ESB,) Master Data Management (MDM), Database, and SOA protocols and practices deliver a solution. Frank begins with the SOA basics, explains their applications, and shares specific metrics that you can use to govern your SOA efforts.

How do you know when a product is ready to ship? QA managers have faced this question for years. Mike Ennis shares a process he uses to take the guessing out of when to ship a product, replacing guessing with key metrics to help you rationally make the right ship decision. Learn how to estimate, predict, and manage your software project as it gets closer to its release date. Mike shows you which metrics to track and how to collect them without undue overhead on the project. Define a ratings scale for each metric you collect and create a spider chart indicating that the product is ready—or not. Mike’s presentation is a must for individuals or organizations that are serious about releasing their software products when they are ready—and not before—and knowing in advance when the software will be ready.

A new strategic project is in the design stages—how much will it cost? Your application requirements are constantly growing—what is the impact? System testing is scheduled soon—how much time and what resources will we need? And how do you get the answers? Measurement. Although software developers are often collecting measures of defects, earned value, variances, etc., the most fundamental measure—how big is the system?—is usually lacking. Lines of code and function points are established sizing measures but both have limitations that have prevented their widespread acceptance. Karen Johns presents testable requirements, an alternative sizing measure that can help you meet these challenges and more. Learn from Karen what testable requirements are and how to use them to size your software systems. Testable requirements, a foundation for your development projects, can also provide your projects with a powerful and intuitive measure of system size.

Scrum is best defined as an agile, lightweight process used to manage software and product development using iterative, incremental practices. Rob Myers gives a brief explanation of the philosophy behind Scrum, the Scrum method, and the roles and responsibilities of the players in a Scrum project. Scrum can be wrapped around different software engineering methodologies, including Extreme Programming (XP), Rational Unified Process (RUP), spiral development, and others. Scrum practices enhance the benefits of agile development with a simple project management process. Scrum significantly increases productivity and reduces development time while facilitating adaptive systems development based on empirical data. Join Rob to learn how Scrum works, why it works, and why Scrum is becoming such a popular project management method.

Knowledge of agile development processes is spreading through publications, training, and experience. And now organizations are taking on larger projects using agile methods. However, as more teams are involved in agile practices, organizations often stumble over what information is created and used during the various stages of an agile project and who is responsible for developing and reporting this information. Hubert Smits shares a model that describes the information created and consumed throughout the iterations, and describes the rhythms of an agile project(release, iteration, and day). The process Hubert describes focuses on creating the right artifacts at the right time, and with an accuracy—or acceptable level of inaccuracy—that enables project stakeholders to make good decisions. Through this model Hubert shows that agile is not anti-documentation but rather is about investing in the appropriate level of documentation at the right times.

Performance measurements have now become a mainstream management practice in many, often large, development organizations. Equally important to establishing strategic goals and objectives is identifying an appropriate set of measures to provide quantitative evidence that those goals and objectives are being achieved. David Garmus describes a project performance baseline that can be implemented throughout your organization or at the department level across multiple projects. These measurements must be matched to the business needs of stakeholders, not to the technical aspects of the project and process. For increased learning, measurements must be compared among projects, departments, divisions, or the entire organization. While quantitative measures are preferred, qualitative measures can also be very useful. Finally, the results of all process improvement initiatives must be measured to determine if those initiatives achieved their business and financial goals.

There is no longer any question that—when appropriately used—quantitative measurement and management of software projects works. As with any tool, the phrase “appropriately used” tells the tale. Drawing on his experiences using quantitative and statistical measurement, Ed Weller provides insights into the key phrase “appropriate use.” Ed offers cases of useful—and not so useful—attempts to use the “high maturity” concepts in the Capability Maturity Model Integration® (CMMI®) to illustrate how you can either achieve a high return on your investment in these methods or fail miserably. After an introduction to the theory of statistical measurement, Ed presents examples of the successful use of statistical measures and discusses the traps and pitfalls of their incorrect implementation. Don’t be mesmerized by fancy measurements that purport to manage for us; rather, look upon them as tools for us to use appropriately to improve our business.
CMMI® is a registered trademark of Carnegie Mellon University.

Letting good estimates made by smart people be overwhelmed by the strong desires of powerful people is a cardinal sin of project management. Accurate estimates are the foundation of all the critical project decisions regarding staffing, functionality, delivery date, and budget. How do we properly estimate in a world where tradition declares that the deadline is set before the requirements are even known? Tim Lister offers practical advice on dealing with this thorny issue. He presents strategies and tactics for project estimating and describes his favorite estimating metric, the Estimating Quality Factor(EQF). By thinking of your project this way—goals are important and so are good estimates—you will be on the road to better quality and better projects. If you can learn to start the project and estimate continuously as events unfold, your goals and estimates will eventually converge.

In recent years, psychologists have come to a nearly unanimous consensus on the number and nature of human personality dimensions. A recent large scale study involving several hundred software engineers and “regular” people (non-engineers) revealed that the personalities of developers, testers, and managers tend to be different from each other and from the general population as a whole. So, how can you use this information in your job? Rather than administering a personality assessment as part of the hiring process, it is much more effective to use it to understand your existing team members and to help then maximize their productivity and value to the business. James McCaffrey demonstrates how to quickly and easily create, administer, and interpret personality profiles of your team members. At the end of this presentation you will be able to take the personality assessment used in the study and see how your personality compares with other software professionals.

The responsibility for building effective software teams is more than just a management task. Indeed, in some situations, management could easily rationalize that there is limited business value in improving team effectiveness. Our current reliance on processes, methodologies, and tools is misguided in that it largely looks outward rather than inward for solutions. There is a better way! Jim Brosseau examines the challenges and barriers we face with typical approaches when attempting to build effective teams. He explains how each of us can take responsibility for personal and team success and describes a meaningful progression of steps to achieve this goal. In doing so, Jim helps you look beyond the traditional team building approaches to explore personal motives, attitudes, skills, and interpersonal relationships—all fair game as potential opportunities for improvement.

Project managers generally run a project based on the development methodology used by their company. If a product is developed in a traditional, more waterfall manner, project managers will slip into management techniques of heavy documentation, weekly status meetings and reports, and a “tell them what to do” mentality. On the other hand, if a product is being developed in an agile manner, then minimal documentation, daily stand-up meetings, and team-based direction will be more the norm. Brian Watson describes how his organization has incorporated many agile management techniques into all projects regardless of methodology required by the client or sponsor. They have successfully adapted their internal agile methodologies for clients that demand waterfall or spiral project reporting. The client sees the facade of a waterfall project, while the project is managed in an agile manner behind the scenes. Join Brian as he describes how this technique provides the benefits of agile yet meets the expectations of their clients and project sponsors.

The SOA revolution is already underway in many IT organizations. SOA creates new cultural, organizational, and technological challenges that must be met to ensure success. Merely implementing web services and enterprise service buses will not address the key issues in building organizational support and standardized adoption throughout the organization. Without the proper organizational process infrastructure, you will be left with SOA program chaos and SOA infrastructure shelf ware. David Butler asks, “Do your SOA initiatives have processes and policies in place to enable visibility, trust, and control and most importantly, to ensure your desired business outcomes with SOA?” David will describe how to enable collaboration across the organization while reducing duplication of effort, how to create corporate standards for interoperability, architecture, and lifecycles, and the importance of creating and then meeting SOA service level standards.

Can a group of software developers, located in Mexico, achieve CMMI® certification and set the standard for their larger U.S. parent company to follow? A software branch of Freescale Semiconductors Inc., located in Guadalajara, did exactly that. Developing the CMMI® processes and procedures that made business sense for a remote software group was tricky, but not as tricky as assuring that they aligned their practices with the parent company’s processes and requirements. The months of work that led to this achievement were filled with high points—and big challenges. Jeff Fiebrich discusses the planning, budgeting, and implementation that contributed to their ultimately successful CMMI® certification. He addresses the collaboration between their parent company and the local government that was an essential part of this effort. And, most importantly, Jeff reveals the immediate impact of their certification on the entire company.
CMMI® is a registered trademark of Carnegie Mellon University.

All measurement numbers begin their life with the objective of being good and useful tools. Often a combination of mistakes, misunderstandings, organizational politics, and poor usage intersect to make these “Good Numbers Go Bad.” Valuable measurements act as a nexus that focuses the members of an organization on its goals. Such measurements are relevant to the organization, predictive in that they provide foreknowledge of events, and broad enough to be useful in more than one situation. Whether you are a software manager, project manager, or a measurement guru, one of your roles is to act as the keeper of the numbers and the steward of useful information. Thomas Cagley illustrates the unfortunate realities of how good numbers can go bad and offers suggestions on how to make measurement a positive force in your development organization.

Software development methodologies try to improve quality by promoting the tactic of testing "early and often." When a defect is detected, a report is filed, the developer tries to reproduce and repair the problem, and then testing must verify that the modification corrected the problem and did not create any new problems. Because it doesn't prevent the same types of errors from recurring, this approach is time consuming, costly, and inefficient. Errors are introduced into the product at various stages— requirements definition, design, and coding. If we focus our efforts on eliminating defects at the points of error introduction, we can reduce the time spent on error detection and correction. Shankar Krishnamoorthy discusses the best practices for error prevention that Aspire Systems has discovered in their experience of developing almost three hundred products.