|
|
|
|
| |
|
|
| |
|
| Michael Mah, QSM Associates |
|
Change can be painful, but staying stagnant can hurt even more. As a manager, how do you decide what should change and how do you know if your organization is ready? When managers seek to improve by introducing new practices such as agile, CMMI, or others, what roadblocks can cause their organizations and teams to reject change—or even worse, to spiral into dysfunction? Michael Mah presents examples of managers who have successfully overcome problems introducing change, plus a few examples of managers who weren’t so fortunate. Learn how systems theory plays a role in software development and why complex communication and expert thinking are the penultimate challenges facing many software managers. Discover how accurate and reliable metrics are necessary to reveal patterns that will help you find the right path through an improvement program. In the rush to be faster, better, cheaper, or super-innovative, don’t become trapped in organizational and team dysfunction, even to the extent that good medicine won’t work.
|
 |
| Learn more about Michael Mah |
|
|
|
| |
| |
| Alan Shalloway, Net Objectives |
|
Many companies have adopted agile by using Scrum on one or more of their projects. Unfortunately, they may be missing the point that agility should be aimed at the enterprise, not merely at the team. Agile enterprises can respond quickly to changing market conditions, competitive pressures, and changing technical environments, thus bringing their innovations to market faster. However, creating an agile enterprise is much more than simply getting teams to adopt Scrum. Alan Shalloway discusses how to use lean thinking to determine where to start using agile methods as well as how to adopt agile throughout the entire enterprise. Alan discusses six areas required to become a lean-agile enterprise: (1) selecting the right projects, (2) matching resources with these projects, (3) creating agile teams, (4) organizing these teams to work with each other most effectively, (5) achieving the required technical skills, and (6) learning how to learn. Leave with a checklist of what to consider when bringing agility into your organization. |
 |
| Learn more about Alan Shalloway |
|
|
|
| |
| |
|
| Paul Julius, Willowbark Consulting |
|
Joining an agile team can be very challenging—new programming styles, new coding standards, new check-in requirements, new leadership styles, and more. Adding pair programming to the mix can be “the straw that broke the camel's back” or it can be key to team empowerment. Paul Julius has been a dedicated pair programmer since 1999, working on many projects with 100% pairing. Paul has distilled a set of positive and negative patterns that can develop when teams attempt pair programming. He begins by discussing the most frequent objections to pairing and then outlines why pair programmers deliver better applications. Paul demonstrates the techniques and skills you—or members of your team—need to become a successful pair programmer. He invites members of the audience to pair with him using several surefire pairing approaches that will keep developers out of the “Chewie seat.” Take back a checklist of steps to eliminate many anti-pairing environmental factors seen in organizations.
|
 |
| Learn more about Paul Julius |
|
|
|
| |
| |
|
| Lee Copeland, Software Quality Engineering |
|
As testers, we focus our efforts on measuring the quality of our organization�s products. We count defects and list them by severity; we compute defect density; we examine the changes in those metrics over time for trends, and we chart customer satisfaction. While these are important, Lee Copeland suggests that to reach a higher level of testing maturity, we must apply similar measurements to ourselves. He suggests you count the number of defects in your own test cases and the length of time needed to find and fix them; compute test coverage�the measure of how much of the software you have actually exercised under test conditions�and determine Defect Removal Effectiveness�the ratio of the number of defects you actually found divided by the total number you should have found. These and other metrics will help you evaluate and then improve the effectiveness and efficiency of your testing process.
|
 |
| Learn more about Lee Copeland |
|
|
|
| |
| |
|
| Paul Anderson, GrammaTech |
|
Static analysis is a technique for finding defects in code without executing it. Static analysis tools are easy to use because no test cases or manual code reviews are needed. Static analysis technology has advanced significantly in the past few years. Although the use of this technique is increasing, many misconceptions still exist about the capabilities of advanced static analysis tools. Paul Anderson describes the latest breed of static analysis tools, explains how they work, and clarifies their strengths and limitations. He demystifies static analysis jargon—terms such as object-sensitive, context-sensitive, and others. Paul describes how best to use static analysis tools in the software life cycle and how these can make traditional testing activities more effective. Paul presents data from real case studies to demonstrate the usage and effectiveness of these tools in practice. Gain a better understanding of this powerful technology so you can decide when and how to apply it.
|
 |
| Learn more about Paul Anderson |
|
|
|
| |
| |
|
From taking our first steps and saying our first words, through kindergarten, grade school, and college, we are praised, rewarded, and judged on our ability to learn. When we finish formal education and enter the workplace, we discover that we have to start learning all over again. Outside of work, we learn and practice skills in our leisure time—maybe a sport or something artistic, a musical instrument, or beating the monster at the end of level 17. Given the amount of time we spend learning, it is surprising how little we invest in understanding how it’s done. From Dreyfus to De Bono by way of Japanese martial arts, Dan suggests that some of our modern organizational challenges may be due to teachers telling us that copying is cheating and that challenging authority gets you detention. Take away several models of learning and skills acquisition that will help you learn to learn more effectively.
|
 |
| Learn more about Dan North |
|
|
|
| |
| |
|
| Chris Sterling, SolutionsIQ |
|
In Scrum, the product backlog is used to prioritize feature implementation based on business value. The product owner manages the product backlog to direct implementation for the greatest possible business value. However, product backlogs that list only system features do not consider the decay of software over time. The resulting “software debt” can eventually sink a project or even an entire product or organization. Chris Sterling explains ways to manage software debt with an eye on the long-term vision and success of the product. Unfortunately, many teams ignore key concepts regarding debt and fall into a “get it done” mentality. They either ignore, or are unaware of, the negative effects of these seemingly small decisions on their future success. Learn about the different types of debt—technical, quality, configuration management, design, and platform experience—and how to manage them so you continue to deliver high value as your systems evolve and age.
|
 |
| Learn more about Chris Sterling |
|
|
|
| |
| |
|
| Johanna Rothman, Rothman Consulting Group, Inc. |
|
Wouldn’t it be nice to know what your staff is doing without looking like a micromanager? Have you wondered how to treat people fairly while still giving them what they need? Would you like to spend a week out of the office, but you’re worried your staff won't be able to manage while you're gone? Johanna Rothman explores questions that face software managers every day. Gain new insights through the mistakes she made and the lessons she learned after she became a manager and then a consultant after years of hard-core technical work. Johanna describes seventeen technical management tips and tricks she has learned through trial and error, including the dangers of extended overtime, the value of one-on-one meetings, ways to build trust, and many others. Learn about a manager’s job, how to create an effective work environment, and how you can help people do their best work.
|
 |
| Learn more about Johanna Rothman |
|
|
|
|
| |
| |
|
PMOs usually think they are out of business when agile rolls into town. But the reality is that the PMO can play a pivotal role in successful agile adoption in large organizations. Jean Tabaka shares her knowledge about how to engage your PMO for agile adoption by using three primary Lean Principles: "Eliminate Waste," "See the Whole," and "Amplify Learning." Jean gives examples of how PMO members can act as the "systems thinkers" for their organizations, pulling successes from the engineering group and instilling them into the entire enterprise. Learn the role of the PMO within agile—how the PMO pulls standards versus pushing them; how the PMO provides product backlog prioritization guidance regarding architecture and governance; how the PMO serves its agile community by facilitating release planning across teams; and how the PMO creates and maintains product councils.
|
.jpg) |
| Learn more about Jean Tabaka |
|
|
|
|
| |
| |
|
| Rob Myers, Agile Institute |
|
Test-Driven Development (TDD) is the practice of writing a test before writing code that implements the tested behavior, thus finding defects earlier. Rob Myers explains the two basic types of TDD: the original unit-level approach used mostly by developers, and the agile-inspired Acceptance-Test Driven Development (ATDD) which involves the entire team. Rob has experienced various difficulties in adopting TDD: developers who don’t spend a few extra moments to look for and clean up a new bit of code duplication; inexperienced coaches who confuse the developer-style TDD with the team ATDD; and waffling over the use of TDD, which limits its effectiveness. The resistance (overt or subtle) to these practices that can help developers’ succeed is deeply rooted in our brains and our cultures. Rob gives practical advice on overcoming that resistance and developing an “enjoyable development discipline” for a sustainable and practical TDD practice. With Rob’s practical advice, you may also discover how to lose weight and pay off your debts (seriously!). The success factors are identical.
|
.jpg) |
| Learn more about Rob Myers |
|
|
|
|
| |
| |
|
| Nicole Bryan, Borland Software Corporation |
|
In many organizations, developing and delivering software has long been described as a “black box”—requests go in and many months later something comes out. But is it what was needed? Did it provide value to the organization? Was it a quality product? In many software projects, managers are flying blind and have very little in terms of meaningful or accurate data to guide their work. Nicole Bryan introduces the software delivery cockpit and explores the practical and pragmatic instruments and indicators—metrics and measurements—that it should include. She focuses on both leading and lagging metrics and indicators that apply regardless of the development methodology you use. Nicole introduces a core set of metrics focused on the critical aspects of software delivery: code integrity compliance, product quality, business alignment, and efficiency. Leave with a blueprint for a software delivery cockpit, the key metrics you should begin tracking, and steps to build your very own digital cockpit.
|
 |
| Learn more about Nicole Bryan |
|
|
|
|
| |
| |
|
| Mike Hryekewicz, Standard Insurance Company |
|
Although organizations have vastly increased their efforts to secure operating systems and networks from attackers, most have neglected the security of their applications—making them the weakest link in their overall security chain. By some industry estimates, 75 percent of security attacks now focus on the application layer. All too often, the departmental responsibility for verifying application security is not defined, and security within the SDLC is either addressed too late or not at all. Based on his experience in a Fortune 1000 company, Mike Hryekewicz describes a step-wise strategy for extending the QA department’s role to include security as a quality attribute to verify prior to an application going into production. Learn how to deploy a security testing capability within your QA department and how to extend its coverage and activities as the process gains acceptance. Mike recommends specific security testing activities and describes the supporting skills, tools, training, and reference resources to ensure a successful rollout.
|
 |
| Learn more about Mike Hryekewicz |
|
|
|
|
| |
| |
|
| Linda Rising, Independent Consultant |
|
Some interpreters of history believe that the Industrial Age could not have happened without coffee and tea. That daily jolt of caffeine enabled workers to be more in control of their waking hours—not to mention killing the nasties in the drinking water. While the Industrial Age was all about staying awake and working long hours, cognitive psychologists tell us that working short cycles with frequent breaks is not only healthier but also more productive for knowledge workers. Linda Rising describes the costs of force fitting Industrial Age—read “plan-driven”— living into our now knowledge-based—read “agile”—world. Although choices at the personal level are best made by individuals, Linda offers specific suggestions for working in short cycles and the proper place for caffeine, naps, short breaks, and sleep. We have seen the benefits of agile processes in our organizations. Now it's time for a truly agile personal approach for living and working.
|
 |
| Learn more about Linda Rising |
|
|
|
|
| |
| |
|
| Scott Plewes, Macadamian Technologies |
|
Today’s users are savvier than ever—you can’t hide poor design behind fancy features. A good user experience isn’t optional anymore—it’s mandatory. But if you ask four users how to improve a product, you’ll get four different answers, and you’ll be lucky if one of those is helpful. When designing the user experience of your products, the challenge is to understand the difference between how customers say they will use a product and how they will actually use it. To accomplish this, we must research our users and gather information. Scott Plewes shares useful techniques for collecting user feedback, including field research, interviews, focus groups, and usability testing, and explains how to get the most from them. Great research isn’t about pie charts, graphs, and massive reports. It’s about discovering those few key aspects of your users’ needs and behaviors that will differentiate your product from your competitors. Learn how to use these techniques, discover useful information, and use it to your competitive advantage.
|
 |
| Learn more about Scott Plewes |
|
|
|
|
| |
| |
|
| Jason Bryant, Schlumberger Information Solutions |
|
Many managers look to formal techniques—requirements reviews, code inspection, and testing—to improve the quality of their software. While these techniques are valuable, they only evaluate the state of quality rather than improve it. The key is to create quality software in the first place. This can only be achieved by a change in management style. Jason Bryant proposes a set of simple and effective principles you can employ to produce high quality software. First, you must foster a culture where people are given the freedom, time, and resources to do the job correctly the first time. By embracing user centered and incremental development practices, you will go a long way toward ensuring accurate and timely software delivery. Focus on training your staff to become masters of their craft and invest equally in architecture, new features, and maintenance. Develop a shared definition of quality that includes meeting the users’ needs and providing them with an enjoyable product experience. Quality–it’s not about catching it, it’s about creating it!
|
 |
| Learn more about Jason Bryant |
|
|
|
|
| |
| |
| Ahmed Sidky, X2A Consulting |
|
As more and more organizations are experimenting with and adopting agile development, questions about agile readiness often arise. Are we ready for agile? Which agile practices are we really ready for now? Before trying new agile practices, teams should make sure that they “have what it takes” for this paradigm shift. Ahmed Sidky discusses agile readiness assessments and how they can save your team from frustration and lost productivity during the transition to agile practices. Ahmed explores how to conduct agile readiness assessments using a practice-based approach. To address the issue of measuring agility from a more holistic perspective, Ahmed presents the rationale and process behind the five-level Sidky Agile Measurement Index (SAMI). He describes each of the levels—Collaborative, Evolutionary, Integrated, Adaptive, and Encompassing—and explains how to tailor SAMI and use it to conduct value-based agility assessments within your organization. Take back a process model to identify the agile practices you are ready to adopt and the prerequisites you need to make immediate improvements. |
 |
| Learn more about Ahmed Sidky |
|
|
|
|
| |
| |
|
| Jeffrey Fredrick, Independent Consultant, and Paul Julius, Willowbark Consulting |
|
A major challenge for software organizations is to create software that can continue to adapt and change over time—a codebase the team can live with “forever.” Jeffrey Fredrick and Paul Julius review the concepts and features of CruiseControl, a popular continuous integration tool that provides an architecture for habitable code. CruiseControl is an open source success story, contributed to by more than 200 different developers and downloaded more than 400,000 times. For developers who are tired of brittle code that often must be discarded and rewritten instead of reused, CruiseControl provides valuable lessons and a design that encourages reuse. Jeffrey and Paul discuss inversion of control, dependency injection, separation of concerns, and the role of a project architect in creating habitable code. Although the code examples will be in Java, the principles are language independent. Learn about a toolkit full of practices that help you create habitable code. Take back a checklist that will help remediate your team’s code from fragile to firm.
|
 .jpg) |
Learn more about Jeffrey Fredrick
Learn more about Paul Julius |
|
|
|
|
| |
| |
|
| Terry Vogt, Booz Allen Hamilton |
|
Measurement data is supposed to help you make better decisions; yet, the information provided under the term “metrics” is often confusing, obscure, or irrelevant to those who need it most. Those providing measurement data frequently produce charts, graphs, and reports that fail to illuminate significant conditions and leave decision makers clueless. The solution to the problem is understanding essential models of decision making and recognizing the need to communicate in the language of the decision maker—not in technological lingo. Terry Vogt explains how to anticipate the informational needs of the measurement user and how to translate those needs into meaningful, actionable measurement information. He illustrates his discussion with examples of both good and poor measurement information. Join Terry to gain new insights in how to: see things from the user’s viewpoint, design effective measurement systems and outputs, and provide insight and understanding that motivate effective decision-making.
|
 |
| Learn more about Terry Vogt |
|
|
|
|
| |
| |
|
| Douglas Hoffman, Software Quality Methods, LLC |
|
Five common fallacies about test automation can leave even the most experienced test and development teams severely ill. If allowed to go unchallenged, these beliefs will almost guarantee the death of an automation effort. The five fallacies are: (1) Automated tests find many bugs—they don’t. (2) Manual tests make good automated tests—they don’t. (3) You know what the expected results are—often you don’t. (4) Checking actual against expected is simple—it isn’t. (5) More automated regression tests are always better—they aren’t. Join Doug Hoffman to explore these fallacies—why we believe them, how to avoid them, and what to do now if you’ve based your automation efforts on them. Take back a set of antidotes to each of these fallacies and build a successful test automation framework or repair the sick one you are living with now.
|
 |
| Learn more about Douglas Hoffman |
|
|
|
|
| |
| |
|
How Others See You: Seeking Personal Feedback
| Johanna Rothman, Rothman Consulting Group |
|
Has this ever happened to you? You’ve just finished an important presentation. As you return to your seat, a colleague leans over and whispers, “You’ve got spinach in your teeth.” Even if you haven’t had this experience, you’ve probably lived through something similar in which you’re the last to know something that is obvious to everyone else. Unfortunately, we never exactly see ourselves as others see us. Gaining insight into how we affect others and how they view us provides us with new awareness and greater choices about how we act. Johanna Rothman shares a feedback model that focuses on describing behavior and the impact of behavior—not evaluation and blame. She discusses different ways for you to seek information that helps you improve your personal effectiveness. When someone gives feedback that, at first, feels like an attack, learn to ask questions that will elicit useful information. Create your own personal continuous improvement plan and be the best you can be every day.
|
|
| Learn more about Johnanna Rothman |
|
|
|
|
| |
| |
|
| Ibrahim El Far and Venkat Narayanan, Microsoft |
|
Many familiar products, including email, instant messaging, search, and e-commerce sites, are actually implemented as services rather than PC-installed software. The shift to services now extends to everything from office productivity tools to utilities like storage, authentication, manageability, and application hosting. Engineers who want to build highly available services with a positive user experience face unique design, testing, and operational challenges. Ibrahim El Far and Venkat Narayanan discuss aspects of configurability, including the ability to turn off features quickly or redirect traffic that minimizes the impact of defects on the user experience. They discuss the importance of fault testing and explain why testing a service must happen everywhere from the workstation to the live site. Learn best practices in operations, including automated deployment, monitoring services, and service repairs. Discover how managers must rethink design and testing, how the reliability of scale changes defect prioritization, and what to watch for during capacity planning.
|
  |
Learn more about Ibrahim El Far
Learn more about Venkat Narayanan |
|
|
|
|
|
|
|
Top of Page
| | |
 |
Software Quality Engineering • 330 Corporate Way, Suite
300 • Orange Park, FL 32073
Phone: 904.278.0524 • Toll-free: 888.268.8770 • Fax:
904.278.4380 • Email:
[email protected]
© 2009 Software Quality Engineering, All rights reserved. |
| | |
|
