Conference Presentations

The Psychology of Software Engineers

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.

James McCaffrey, Volt Information Sciences, Inc.
Decision Making Under Extreme Pressure: Lessons Learned from Pilots in Crisis

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.

Lee Copeland, Software Quality Engineering
Bandages or Tombstones? Distinguishing Between Minor Setbacks and Impending Doom

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.

Payson Hall, Catalysis Group Inc
The Give and Take of Design Criticism

Have you ever engaged in a design discussion where people didn't play fair? Do you have trouble giving advice that sticks or accepting criticism of your own work? Do you know when you should take up an argument and when is it better to let things slide? Every software engineer needs skills at giving, absorbing, and reacting appropriately to criticism. We should know when to pick our battles and how to spot and counteract faulty reasoning. We should be able to give advice so that others get it, and if they don't, determine why. Join Rebecca Wirfs-Brock to explore how design teams can engage in more effective conversations while eliciting and exchanging constructive criticism. Rebecca surveys the biases that underlie reactions people commonly have to new information and how to overcome those biases.

Rebecca Wirfs-Brock, Wirfs-Brock Associates
What's the Deal with "Best Practices" - Revisiting the Idea

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.

Dan North, ThoughtWorks
Lessons Learned in Project Management

You've managed projects, but they're never easy. They don't fit into the nice definitions found in project management books. Your schedules are generally off. There are always unkind surprises. Although you're not failing, you feel you could be more successful. There is a solution. Based on her many years of consulting with large and small software teams, Johanna Rothman coaches leaders to take a more pragmatic approach. Employ mini-projects and iterations to explore alternative technologies. Use incremental steps to finish features one at a time when you don't know how far along you are. Make sure stakeholders agree on what "done" really means. Learn how to escape the dreaded trap of "multi-tasking," a management style that drains energy from everyone whenever there is a task switch. One final secret every project manager must discover: There is no "one right way" to manage a project.

Johanna Rothman, Rothman Consulting Group, Inc.
Attacking Waste in Software: Three Practices We Must Embrace Now

One of the seven principles of Lean Thinking is "eliminate waste." Eliminating waste means minimizing the cost of the resources we use to deliver software to our stakeholders. Jean Tabaka proposes three pivotal practices that we must embrace to aggressively attack waste in software delivery—Software as a Service (SaaS), Community, and Fast Feature Throughput. SaaS eliminates waste by deploying software-based services without the cost inherent in traditional software delivery—materials, shipping, time delay, and more. Community involves stakeholders working together to create products rather than competing among themselves for limited resources. Community eliminates waste by democratizing software development to obviate the need for multiple systems with the same functionality. Fast Feature Throughput refers to development methods that embrace change and quickly deliver value to customers.

Jean Tabaka, Rally Software Development
Agile and the Seven Deadly Sins of Project Management

Agile approaches to software development promise many advantages: shorter schedules, more productive teams, products that better meet customer expectations, higher quality, and more. In this talk, Mike will explain how agile teams achieve these goals by avoiding the seven deadly sins of project management. Covered will be sins such as gluttony, sloth, lust, opaqueness, and more. Giving in to one of these temptations can result in a failed or cancelled project. Along the way you'll be introduced to key aspects of agile development and hear stories of agile success and failure.

Mike Cohn, Mountain Goat Software
Managing Contracts for Outsourced Testing

In large outsourced projects, the contractual aspects of testing are often poorly defined even though testing may be half the overall project cost. Why is this? Test activities may be split between the development organization, customer, and test outsourcing partners. When things go wrong, the test process and the contractual obligations relating to testing will come under close scrutiny. Unfortunately, many projects get their contracts wrong with regard to testing. In Paul Gerrard's experience, few organizations’ contract and legal experts know how to structure a contractual testing schedule that is fair, unambiguous, explicit, and comprehensive. As testers, we may need to help our own “experts.” Paul describes the critical aspects of a contract that must be included to ensure supplier obligations for testing are documented and will be met.

Paul Gerrard, Gerrard Consulting
STAREAST 2008: The Hard Truth about Offshore Testing

Test managers often choose solutions to problems without sufficient analysis, resulting in a cover-up of the symptom rather than a solution to the underlying problem. Later, the problem may surface again in a different disguise, and we may mishandle it again, just as we did initially. Alon Linetzki describes a simple process you can use to identify the root causes of problems and create an appropriate solution to eliminate them. Alon shows how he enhanced the classic root cause analysis method to create an approach to finding insidious problems in software and processes. His method includes ways to differentiate symptoms from problems, understand the connection between them, and determine the strength and direction of that connection. Alon illustrates this method with data from two testing projects and shares the lessons learned along the way.

  • Simple, robust method for determining underlying problems
Jim Olsen, Dell Inc

Pages

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.