Agile

Conference Presentations

Software Security Testing: It's Not Just for Functions Anymore

What makes security testing different from classical software testing? Part of the answer lies in expertise, experience, and attitude. Security testing comes in two flavors and involves standard functional security testing (making sure that the security apparatus works as advertised), as well as risk-based testing (malicious testing that simulates attacks). Risk-based security testing should be driven by architectural risk analysis, abuse and misuse cases, and attack patterns. Unfortunately,
first generation "application security" testing misses the mark on all fronts. That's because canned black-box probes-at best-can show you that things are broken, but say very little about the total security posture. Join Gary McGraw to learn what software security testing should look like, what kinds of knowledge testers must have to carry out such testing, and what the results may say about security.
Gary McGraw, Cigital Inc
Agile Offshore Development: An Oxymoron?

Companies that master Agile development in a multi-shore environment can benefit from reduced calendar time to implement new features, early development feedback to make course corrections, and increased development team responsiveness to changing market requirements. Multi-shore Agile development teams face unique challenges compared with co-located teams-large time zone differences, lack of proximity, cultural differences, and more. With experience driving multi-shore Agile development with several enterprise software companies, Roger Nessier describes ways that he has addressed these challenges. He discusses sprint planning with distributed teams, how to structure and assign work, and tools for communicating in real-time to create an Agile global development environment. Learn about the benefits and limitations of using Scrum management practices for offshore development and what it takes to be successful.
Roger Nessier, Symphony Services
Process Improvement - Can I Make a Difference?

Although some organizations already have formal processes in place, many do not. Most process improvement begins with one person or one department deciding to do something rather than accepting the status quo. With the right attitude, some simple tools, and a proven method for improvement, you can make a difference for yourself, your department, and ultimately, your organization. Stephanie Penland has helped numerous small and large organizations with process improvement. Sharing her experiences-both successes and failures-Stephanie describes her real-world approach for process improvement. Find new ways to overcome obstacles and obtain buy-in from the top down. Learn what it takes to get a process improvement program off the ground. Take back with you a sample of a successful process improvement plan.

  • The benefits of process improvement and ways to measure success
Stephanie Penland, SAS Institute Inc
Even the Best Get Stuck: Transitioning to Agile Developement

For some organizations Agile methodologies like XP, Scrum, and Crystal work well off-the-shelf. However, many companies struggle with these practices and find that lightweight methodologies leave them without support for key aspects of their business. Most end up adopting a hybrid of multiple methodologies mixed in with some old practices. This is risky business. Cherry-picking your favorite parts of Agile methodologies can leave you without enough process and in danger of a code-and-fix mentality that relies on heroics to ship software. Alex Pukinskis looks at different paths taken by organizations as they transition to Agile. He discusses key "process smells" that indicate that a project has gone past agility and is slipping into chaos. Alex offers suggestions to get your foundering Agile transition back on track.

  • Patterns for adopting Agile practices
Alex Pukinskis, Rally Software Development
Better Software Conference 2006: Agile Development and Its Impact on Productivity

Agile development projects are different. Sure, they still have high-level business requirements, but they usually lack system descriptions, technical design documents, and system architectures. The projects tend to be smaller than those employing more traditional methods, and much of the testing occurs concurrently with development. The teams tend to be very small and often in one room, more like a group of friends than a typical development team. How do these and other differences affect productivity and the resulting products? Based on his research and personal experiences, David Garmus discusses the differences between Agile and traditional methodologies and offers specific ways to measure these differences to help you decide: Is Agile development right for your next project?

  • The quantitative and qualitative differences between Agile and more traditional projects
David Garmus, The David Consulting Group
Leadership - The Forgotten Element of Agile Development

We often hear about the difficulties and failures surrounding Agile methodologies. Articles describe everything from team and execution issues to the inadequacy of Agile methods on large projects and failures in large organizations. The root cause of these issues is often not a flaw in Agile methodologies but rather a lack of Agile leadership. A commonly held belief is that Agile teams are self-motivated and that leadership is almost evil. Quite the opposite is true. To succeed, Agile methodologies demand greater leadership skills at all levels. Learn from Michael Portwood about the differences between traditional and Agile leadership skills. Take away an Agile leadership model for team members, managers, and executives and proven techniques to foster and grow leadership skills development in your Agile organization.

  • Why leadership and management are diametrically opposed
Michael Portwood, Spectra Intelligent Marketing, Inc
Building Secure Software with New Web Technologies

The latest generation of Web technologies-AJAX, improved client-side scripting, support for extensive DOM manipulation in browsers, content syndication, Web service APIs, and simple interchange formats such as JSON-are all driving new, powerful Web applications. Based on his work on real world "Web 2.0" applications, Ivan Krstic discusses the security implications of these new technologies. Ivan describes specific attacks such as Web-based worms, XSS, CSRF, and HTTP response splitting and offers advice on mitigating security risks during the engineering process. Learn how standard security guidelines such as The Confidentiality-Integrity-Availability (CIA) model apply to the modern Web and about the role of cryptography and crypto-engineering in Web security.
Ivan Krstic, Harvard University
Fishing for Requirements in an Agile Project

When you go fishing, you want to use the right lures, catch lots of fish, and avoid falling out of the boat. Developing requirements for an Agile project is similar-you need to use the right process, get the requirements you need with minimum effort, and introduce minimal risk and rework. Because every Agile project has different needs, goals, and constraints, a "one size fits all" requirements process does not work in every Agile project. In this interactive session, Jennitta Andrea shows you how to fine tune the requirements process based on a unique set of project characteristics. Learn to visualize the distinctive characteristics of a project to determine what work products to produce, how much detail to include, and which tools will provide a payback to the project.

  • Strategies for shaping your Agile requirements process
  • How much documentation you really need
Jennitta Andrea, Clearstream Consulting, Inc.
Risk Managment on an Agile Project

Plan-driven software project management is very specific on how to identify and manage risks. When moving to Agile software development practices, what happens to all the risk management activities that project managers used to oversee? Contrary to what many expect, there are Agile risk management practices that reduce risk by providing opportunities for the team to identify, monitor, and control risk events. For each of the traditional risk management areas-identification, analysis, response planning, and monitoring and controlling-you will learn the corresponding Agile approach. In keeping with Agile's strengths, team involvement and collaboration are key inputs into the risk management process. Michele Sliger explains how and when to involve the team in identifying risks, analyzing the opportunities and threats, mitigating as appropriate, and monitoring these risks throughout the lifetime of the Agile project.
Michele Sliger, Rally Software Development
Introduction to the Capability Maturity Model® Integration (CMMI®)

Many organizations have achieved success in using the SEI Capability Maturity Model Integrated (CMMI®) as a framework for their process improvement program. Steven Lett describes the structure and contents of the CMMI®, including the continuous and staged versions of the model. He discusses each of the five maturity levels and their process areas, the specific and generic practices that exist within each process area, and the typical process documentation and work products required for each. Learn an effective approach that companies take in driving change across their software engineering organizations. Find out how the model is meant to be interpreted and take back examples of the successes that companies have experienced in using both CMMI® and the earlier Capability Maturity Model (CMM®). Capability Maturity Model® and CMMI® are registered trademarks of Carnegie Mellon University.
Steven Lett, The David Consulting Group

Pages

StickyMinds is a TechWell community.

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