What’s the Deal with “Best Practices”—Revisiting the Idea
Dan North, Thoughtworks

We talk about “best practices” as though they exist—an ideal way to manage a team, develop software, and test applications. All we have to do is discover what best practices are. At best, this is naive, and at worst it’s an irresponsible way to approach anything, especially software development. Learning theory—specifically the Dreyfus model of skills acquisition—provides the missing context for practices in general and best practices in particular. Dan North describes how people really learn and acquire skills and helps you discover where and how to use the ideas offered by best practices. See how the arbitrary imposition of best practices is inherently risky and can have a detrimental effect on productivity and morale. Dan explains why the term “best practices” is flawed and suggests more useful ways of sharing experience and evolving what we do.

Flow, Pull, Innovate: The Secrets to Agile Adoption
Jean Tabaka, Rally Software Development

Jean Tabaka provides straightforward guidance on how teams can begin their agile journey and learn to mature and scale into more and more discipline. The five-step approach emphasizes a path based on the principles of Lean Thinking—Flow, Pull, and Innovate. Each of the five steps outlines specific practices for growth as well as pitfalls and roadblocks to navigate and avoid. Step 1: The team learns to work in a continuous flow. Step 2: The team matures by pulling ready items from the backlog. Step 3: A group of teams adopts and scales up the individual team practices. Step 4: The scaling continues to cover multiple projects. Step 5: The practices are adopted throughout the entire organization.

You can apply the disciplines discussed in this class to a single co-located team, a team of teams, or an entire organization eager to take advantage of both agile and lean approaches. Join Jean and learn to achieve the greatest innovations with a much lower risk of failure.

Agile in the Non-Agile Enterprise: Hurdling Obstacles
Michele Sliger, Sliger Consulting

Agile is entering the mainstream as a software development practice and leading wider organizational change in many companies. However, in large organizations, it’s not practical just to “flip a switch” and have your entire software department “go agile” all at once. In that situation, agile and non-agile teams must work together during the transition. Agile teams must continue to interface with their company’s business processes, while management must streamline traditional processes and activities. Agile teams face many obstacles in their quest for cooperative development—resistance to change; differing culture and value systems; changes to measurement, evaluation, and reward systems; and new contracting terms. Join Michele Sliger as she explains how to clear these and other common hurdles facing agile teams working in a traditional organization. Michele discusses the organizational issues that you must address as part of an enterprise-wide agile rollout.

More than the Process Police: CMMI® Process and Product Quality Assurance
Will McKnight, Next Level Consultants 

For organizations to succeed in process improvement efforts, they must determine whether newly introduced processes are, in fact, being adopted by managers and practitioners. The Capability Maturity Model Integrated (CMMI®) identifies this verification activity as Process and Product Quality Assurance (PPQA). If you think PPQA is simply “process police,” you’re not getting all that you should out of your CMMI® practices. Done right, PPQA can be a driving agent for change in your organization. Unfortunately, all too often PPQA ends up little more than a post-mortem review of what was done wrong. That approach, which offers little opportunity to change behavior, not only lowers the value of the process, but also hampers change management efforts. Will McKnight demonstrates the potential of an efficient PPQA process. Take back a full functional PPQA process to help transform your process police into valuable, proactive change agents.

Lessons Learned in Programmer Testing
James Newkirk, Microsoft

It has been more than six years since the first release of NUnit 2.0, an open source unit testing tool. In that time, literally millions of tests have been written using the tool. Many of these tests have become and continue to be invaluable resources for their teams. Unfortunately, many other NUnit-based tests have not been maintained and are now viewed as having been a waste of effort from the beginning. What separates tests that are used, maintained, and highly valued from tests that are quickly discarded? James Newkirk describes seven key ideas that are proven to increase the readability of NUnit tests and make them much easier to maintain. Learn about the impact of test fixture size and dependency injection on unit testing. James demonstrates how to use the attributes [ExpectedException], [Setup], and [TearDown] to make tests more readable. Incorporating these and the other lessons can make the difference between tests that become a burden to the team and tests that become practical, growing resources.

Bandages or Tombstones? Distinguishing Between Minor Setback and Impending Doom
Payson Hall, Catalysis Group, Inc.

Are the challenges confronting your project normal and treatable setbacks or signs of something more serious? Can we treat them with a Band-Aid® and a kiss? Should we call the ambulance? The undertaker? Payson Hall shares patterns he’s observed while consulting on dozens of large software development and systems integration projects—executive sponsors distancing themselves from your project, ebbing morale, aggressive schedules, and more. Although good project teams react to adversity and try to get the job done in spite of troubles, their adaptive behavior can lead to a loss of perspective. Sometimes, teams become desensitized to the warning signs of degrading project health and are slow to respond to significant issues. Learn the symptoms of project problems and regain perspective as you identify the causes and find the remedies.

Pragmatic Agility: Principles, Not Dogma
Andy Hunt, The Pragmatic Programmers

You've got questions. Andy Hunt has answers. What is agile software development all about? Why the sudden popularity of agile? Why is it fundamentally different from other approaches? Will it work for my organization and me? Join Andy, one of the seventeen original signatories of the Agile Manifesto and a founder of the Agile Alliance, for his pragmatic take on the answers to these and your other questions. Look at the foundations of agile software development and see what problems agility seeks to address. Don’t be distracted by dogma as you take some time to explore the core aspects of agile development. Andy presents a brief overview of the major agile methodologies and walks you through a typical day in the life of an agile developer. Find out what's really important about the agile approach and take back new ideas to help you transition to agile while avoiding common stumbling blocks. Join Andy to find out how to make agility work for you.

A Kanban System for Software Engineering
David J. Anderson, Modus Cooperandi

Ideas from Lean Thinking have been growing in popularity with the Agile software development community. Over the past year, the use of kanban (literally signal cards) popular in manufacturing has been seen as the significant innovation in managing agile work and is growing in adoption at firms such as Yahoo! David Anderson introduced the first electronic kanban system at Microsoft in 2004 and has since extended the technique through his work at Corbis. Kanban acts to limit work-in-progress and focus the team on achieving a continuous flow of value to the customer.  Kanban innovates on accepted agile management practice by providing an iteration-less process with a regular release cadence. It helps achieve a balance of demand against capacity on the team and eliminate multi-tasking. David will present a brief history of the technique through case study reports from teams at Microsoft and Corbis. The kanban system enables David to deliver on his Recipe for Success: focus on quality; reduce work-in-progress; balance demand against throughput; and prioritize.

You Just Don’t Understand Me: Interdisciplinary Awareness to the Rescue
Mike Tholfsen, Microsoft

Different disciplines and departments in an organization often have the same goals, but often misunderstand one another. We have all heard someone say about another group, “Those people are clueless.” The irony is that “those people” are saying the same thing back under their breath. Within the software disciplines, poor understanding, lack of communication, and unfortunate stereotyping are often commonplace. Presenting a new concept and team exercise called Interdisciplinary Awareness, Mike Tholfsen helps us focus on the importance of team dynamics in building good software. With case studies from both Microsoft Office and Windows teams, Mike shows how they built stronger trust within and between teams. Incorporate this exercise in your group and discover how interdisciplinary awareness can lead to greater understanding and appreciation, a stronger sense of team, and a higher degree of trust.

Early Defect Detection for Software Analysis and Design
Vladimir Pavlov, International Software and Productivity Engineering Institute

For large software development projects, the most important decisions—and the most expensive mistakes—are made at the beginning of the project. At the same time, the initial quality assurance activity is minimal but grows as development moves forward. This results in costly rework (often hidden) in the later stages of the project. Vladimir Pavlov explains how to reduce delays between bug insertions and bug fixes by allocating quality activities over the entire project in proportion to the importance of potential errors. Vladimir describes practical techniques to discover and fix critical analysis and design mistakes almost immediately after their introduction—not in the late phases where they are the most expensive to resolve. He also explains how to integrate these techniques into software development lifecycles including, Rational Unified Process, Open Unified Process, and Microsoft Solutions Framework. To increase quality and lower total project costs, establish early defect detection procedures for your projects.

Answer the Call: Help Product Owners Define and Prioritize Requirements
Kent McDonald, Knowledge Bridge Partners

Numerous software development methodologies are available to provide project teams excellent guidance on how to build systems right. But how do we know that we are building the right systems? We often ask product owners to define and prioritize their requirements—without offering them a great deal of guidance on how to do so. Understanding what the software needs to do and the value that it will add to the organization will help them decide the importance of each requirement.  Kent McDonald explains how you can employ a value model based on the project’s purpose, costs, benefits, considerations, and its relation to the organization’s overall strategies to help product owners define and quantify the value delivered by a project. He will also show how you can use a regular reevaluation of this value model to decide what requirements should be completed and in what order. More importantly, you can empower product owners to determine what requirements should be changed or dropped as the project proceeds.
 

Decision Making Under Extreme Pressure: Lessons Learned from Pilots in Crisis
Lee Copeland, Software Quality Engineering


Controlled Flight Into Terrain is an interesting book containing case studies of poor decisions made by pilots under extreme pressure. CFIT is an accident in which an otherwise serviceable aircraft, under the control of the crew, is flown (unintentionally) into terrain, obstacles, or water, with no prior awareness on the part of the crew of the impending collision. Based on three CFIT case studies, Lee examines what mistakes the crew made, why their decisions seemed correct at the time, and the forces operating on the decision making process. Then he takes those discoveries and applies them to our world of software development. Some learnings include consider entering a holding pattern, have a Plan B ready, beware of the loss of situational awareness, trust your co-workers but not too much, be aware of time dilation, and other key ideas.

The Psychology of Software Engineers
James McCaffrey, Volt Information Sciences, Inc.

The personality traits of software engineers tend to be quite different from those of the general population. 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 personalities of the general population as a whole. So, how can you use this information? Although administering a personality assessment as part of a hiring process may be legal, it is problematic at best. A much better use of a personality assessment is to gauge the profile of your existing team members to maximize their productivity. Join James McCaffrey as he describes how you can quickly and easily create, administer, and interpret a personality profile of your team. At the conclusion of the session, you will have the opportunity to take the personality assessment used in the study and see how your personality compares with other software professionals.
 

Agile Leadership: Coaching Great Teams
Robert Galen, Robert Galen Consulting Group

When adopting agile methods, many project managers find it difficult to move from a traditional, control-based model to a servant-leader based model. This paradigm challenges managers to their core because agility demands a coaching-driven mindset rather than the classic “I’m-in-charge” view. Explore the core aspects of agile leadership and team coaching with Bob Galen as you look at leadership from an agile perspective. Bob discusses “coaching up” the team as part of an agile adoption strategy and offers a conversation framework you can immediately use at work—and at home. Learn the fundamental coaching patterns and anti-patterns as you find out when to step in to help and when to be patient. You’ll have the opportunity to practice a conversation or two and hone your new coaching skills.
 

Agile Software Testing Strategies
Jared Richardson, 6th Sense Analytics

Test automation is like exercise. We know both are great ideas, but most of us don’t do enough of either. Although we know that creating a solid automated test suite is critical to any agile testing strategy, we are often just told to “Do it” without much support—money or people. Jared Richardson examines the infrastructure and tools needed for your automated testing to succeed and prosper. Jared examines three strategies—test-driven development, defect-driven testing, and blitzkrieg testing—you can use to ensure great test coverage on your projects. You’ll gain an understanding of how to leverage your testing investments by employing continuous integration practices in your development projects. With real-life scenarios as a backdrop, Jared discusses appropriate testing strategies for your current project or the next one down the road. Jared will get you moving toward automated testing, whether you're starting fresh or trying to clean up an existing project.
 

Successful Process Improvement—The Agile Way
Nelson Perez, Sierra’s Edge, Inc.

Using agile techniques to develop and implement new processes—whether for use in agile environments or not—will increase stakeholder involvement and buy-in, lower cultural resistance, reduce process development cycle time, and encourage continuous process improvement. Join Nelson Perez as he explains how to translate the core principles of the Agile Manifesto into a context that you can apply to any process development and improvement program. Use the Agile Manifesto values and principles to speed up your process improvement initiatives and ensure its success. Based on his experience in a company with a highly resistive culture, Nelson realized that process improvement approaches must be tailored to each situation—what works consistently in one organizational culture may not be useful in another culture down the street, across town, or in another country. The agile paradigm works in process improvement programs because it is a universal approach for encouraging adaptive change. Learn new ways to encourage continuous process improvement and build stronger teams within your development group and throughout the enterprise.

Ten Principles of an Agile Tester
Lisa Crispin, ePlan Services, Inc.

Everyone on an agile team does testing. If that’s true, what’s so special about an agile tester? If I define myself as a tester on an agile team, what does that really mean? Do agile testers need skill sets different from testers on traditional teams? What guides agile testers in their daily activities? Lisa Crispin believes that when it comes to agile testers, skills are important—but attitude is everything. The best agile testers have a results-oriented, customer-focused, collaborative, and creative mindset that makes them successful in an agile development environment. Lisa explains how you can apply ten agile principles to add value on agile teams, or on any software development team for that matter. The ten principles of an agile tester include areas such as feedback, communication, simplicity, continuous improvement, and responding to change. At the end of this session, you’ll have gained some practical advice for your own self-improvement process.

 

Who Are Your Project Stakeholders?
Linda Westfall, The Westfall Team

It’s easy to list all the stakeholders and identify different types of users for your software project—WRONG! Although it may be obvious who holds the checkbook for your project and who the “average” users will be, many other people and user roles are not so obvious. Unaccounted for stakeholders and users result in missed requirements and often leave important conflicts unresolved. Even worse, you can lose support—and the whole project can fail—if important people are left out of the process. As Linda Westfall demonstrates unique “brain writing” techniques in a facilitated, interactive requirements workshop, you will learn ways to identify a complete list of the important project stakeholders and user roles. After pruning the stakeholder list to eliminate duplicates, Linda demonstrates how to define a requirements elicitation strategy to select appropriate techniques for each stakeholder. Practice techniques for resolving stakeholder conflicts and take back a stakeholder identification checklist to ensure that you consider a broad range of stakeholder categories for your projects.
 

Eight Steps to a Virtualized Development Environment
John Janakiraman, Skytap

Virtualized software test environments deliver quantifiable benefits—lower lab costs, faster test cycles, and lower IT support overhead. New capabilities in virtualization and virtual test lab solutions are being brought to market by vendors such as VMWare, Surgient, VM Logix, and illumita. These tools promise compelling productivity improvements: richer test scope, tighter lab integration with test tools and processes, and on-demand test infrastructure. John Janakiraman describes capabilities and benefits of virtual test lab environments, offers guidance in adopting a virtual test lab, and shares lessons learned from real-world implementations. John walks you through eight important steps to adopting a virtualized environment in your test lab. As John shares the lessons he’s learned implementing virtual test labs, find out if a virtualized lab environment is right for your organization.