|
|
Alternative Testing: Do We Have to Test Like We Always Have? Are the “old ways” always the “best ways” to test? Julian Harty shares his thought-provoking ideas on when traditional testing is-and is not-appropriate and poses alternatives for us to consider. For example, what might happen if we choose not to test a product at all? Perhaps the benefits of earlier delivery would outweigh the cost and delay that testing imposes. If a key goal of testing is to provide answers to quality-related questions about a product, are there alternative information sources for answers-say, from live experiments in production? How do you know whether your testing approach is really efficient and effective, especially if you already consider yourself a testing expert? Can your testing knowledge and experience blind you to alternative strategies? One option is to put yourself to the test. For instance, you could more objectively evaluate your skills by working on a crowd-sourced test project.
|
Julian Harty, Consultant
|
|
|
Refactoring: What You Need to Do It Right As certain as evolving requirements lead to code changes, code changes lead to code degradation. Therefore, code refactoring is critical to the long-term viability of all software products. Kevin Sawicki shares tips and tricks for refactoring to help developers identify code that needs refactoring, preserve the correct code history during refactoring sessions, and ensure that appropriate unit tests cover the refactored code. Kevin demonstrates the Eclipse open-source frameworks and Java-based tools, including EMMA for code coverage analysis and JUnit for unit testing. These tools not only make code refactoring less painful, they also empower developers to constantly improve their code through relentless refactoring. Kevin outlines a step-by-step process to find refactoring candidates, perform the refactorings in an isolated code branch, and collaborate with other developers to review the refactored code.
|
Kevin Sawicki, Perforce Software
|
|
|
Security Guidelines for Agile Development Some security experts would have you believe that it is "impossible" to implement secure development practices using agile development methodologies. Admittedly, the use of agile does pose some challenges to traditional security development lifecycle (SDL) processes-challenges such as meteorically short release cycles, infinitely long product lifetimes as in the case of cloud applications, and a general You-Ain't-Gonna-Need-It planning mentality within agile. Despite these challenges, securing systems developed in agile projects is possible. SDL and agile can work well together. In many ways, they can actually work better together than do traditional development approaches. Bryan Sullivan details the process changes that the Microsoft SDL team made to improve the applicability of the SDL to agile development methodologies.
|
Bryan Sullivan, Microsoft
|
|
|
End-to-End Agile Planning: Oxymoron or Powerful Release Planning Method? It's a very common pattern. Agile methods don't seem to specify much in the way of preparation or strategies for project planning-so teams simply dive-in and start iterating toward a solution to their business problems. In some contexts, such as small-scale simple projects, this works just fine. However, what if your project is more complex? How do you determine a budget when you have a distributed or larger-scale project and no real requirements? In many real-world contexts, establishing a consistent and thoughtful baseline project plan can be an incredibly powerful contributor to your ultimate success. The good news is that you can do end-to-end planning and still "be agile." Bob Galen shows how to use the Crystal Clear's Blitz Planning approach, user story mapping, and other end-to-end planning techniques to establish a "proper beginning" and define a holistic map for your agile projects.
|
Bob Galen, iContact
|
|
|
Risk Identification, Analysis, and Mitigation in Agile Environments Although risk identification, analysis, and mitigation are critically important parts of any software project effort, agile projects require non-traditional techniques that are much quicker and easier to use than classical risk techniques. James McCaffrey focuses-not on theory-but on realistic risk analysis methods agile teams can readily implement with lightweight tools. James explains and demonstrates how you can employ taxonomy and storyboarding methods to recognize project meta-risks and identify product risks throughout the development lifecycle. Using “central moment” and “PERIL” techniques, you'll learn to analyze these risks and develop management and mitigation strategies dynamically, while the project is underway.
|
James McCaffrey, Volt VTE
|
|
|
The Battle of Scrum vs. Kanban Over the past ten years, Scrum has become the leading project management approach in agile development. Now, there’s a new kid on the block-Kanban. Devotees of each approach emphasize their fundamental differences, debating pros and cons of one versus the other. Recognizing that their principles and practices are not utterly dissimilar, Jean Tabaka leads an open discussion about Scrum and Kanban approaches. For instance, both approaches create high project visibility and work in smaller increments than traditional development. And yet, each approach emphasizes its principles that influence which practices and measures guide the team and its organization. Scrum uses a Burndown Chart for visibility on progress; Kanban tracks work-in-process (WIP) as one of its tools for progress visibility. Is one better than the other? Or more importantly, when is one better than the other?
|
Jean Tabaka, Rally Software Development
|
|
|
Working with Globally Distributed Agile Teams Miscommunications, misunderstandings, and interpersonal conflicts often thrive in the typical distributed team. Distributed agile teams, especially globally distributed teams, are more likely to face these issues than those employing traditional development methods. Global agile teams are not only geographically dispersed, but they're also separated by time zones, language barriers, nationality, and organizational culture. Ken Pugh describes the challenges he’s seen globally distributed agile teams face and shares ways you can anticipate and address these challenges. He discusses the different tokens teams can use in their communication and how to create a common understanding among all team members. Ken emphasizes building trust and developing a sense of “us” among the distributed team members.
|
Ken Pugh, Net Objectives
|
|
|
Agile vs. Agility: Doing vs. Being To be agile or not to be agile … that is not the question anymore; agile adoption is on the rise and there seems no turning back. The real question is whether we are focused on boiling agile down to a list of prescribed practices or are we dedicated to embracing and internalizing the core values and principles of agility. Ahmed Sidky explores why “doing” agile over “being” agile could be the reason some organizations do not produce hyper-performing agile teams. He challenges the current thinking of many agile proponents and suggests a solution to the problem. Ahmed offers a value-based roadmap for agile adoption consisting of five steps-collaborative, evolutionary, integrated, adaptive, and encompassing-to help teams and organizations embrace principles over practices. Ahmed helps you crystallize your thinking about the issue of agile vs.
|
Ahmed Sidky, Santeon
|
|
|
Boundary, Authority, Role and Task (BART) Analysis If your Scrum practices-or any agile processes-aren't working as effectively as they might, this class may be just what you need! When teams have trouble executing their work processes, the root cause is often ambiguous definitions of boundary, authority, role, or task-what Dan Mezick calls BART definitions. Although the Scrum framework, effectively implemented, provides excellent BART definitions and structure, sometimes theory and practice don't match. Dan describes how agile teams can employ BART analysis to uncover organizational problems that impact group performance. With a detailed BART analysis, you can identify and isolate effective ground rules for interactions among group members. These ground rules positively impact behavior and foster cultural improvements. In a lively discussion format, Dan introduces the fundamentals of BART analysis and applies it to Scrum.
|
Dan Mezick, New Technology Solutions
|
|
|
Making Agile Work in Highly Regulated Environments Highly regulated industries-avionics suppliers, medical device companies, and pharmaceutical manufacturers-must meet rigorous quality standards to ensure their products are not a danger to the general public. Although compliance has traditionally been achieved with heavyweight waterfall or V-model development methodologies, you can implement agile-or lean-agile-development practices that adhere to standards-based regulations while reducing the risk and improving software quality and reliability. Colin Doyle identifies the constraints that agile and lean-agile software development approaches must address: traceability to clearly defined requirements, formal risk analysis and mitigation, and separation of roles between development and validation.
|
Colin Doyle, MKS, Inc.
|
