Twenty years of traditional processes produced valuable applications at Integrated Research (IR). However, making changes to software was slow and often introduced quality problems that took months to resolve. When one of their customers offered a great new opportunity, IR had to move with speed they did not possess and achieve a quality level that their old ways would not permit. Tony Young shares how his organization introduced agile methodologies on that critical project, giving immediate benefits of speed, focus, visibility, and quality. He describes how Scrum and Kanban practices-daily scrums, pair programming, short sprints, test-driven development, backlogs, and continuous integration-were rolled out across several agile teams. Learn how IR got CEO support for agile, convinced developers to adopt agile practices, evaluated their progress with metrics, and maintained a unified system architecture using a Scrum-of-Scrums.
Mature agile teams work together to ensure sufficient requirement information is ready when an iteration starts. However, on many teams, developers lack this support and may receive overly detailed-and often ambiguous-requirements that are “thrown over the wall.” Drawing on recent industry research and successes of companies with which he’s worked, Chris Duro shares stories from three companies that evolved an agile adoption requirements readiness assessment framework. They used this framework to quantify the requirements problems, obtain management visibility, and win improvements in their requirements process. Chris answers key questions about the framework: How is readiness defined and measured? What is the tester’s role in agile requirements development? How can agile teams check thousands of requirement document pages automatically?
Although success stories from individual agile teams on single projects abound, agile adoptions encounter significant challenges scaling to multiple teams on multiple projects. The Project Management Office (PMO), which often remains poorly defined in agile environments, offers the perfect place to oversee and adapt to govern your agile adoption. Sanjiv Augustine shares success stories from industry-leading organizations that are scaling agile to large projects and across many smaller projects. These organizations have developed PMO managers who bring lean discipline to project prioritization, track and monitor the value delivery across projects, support stable teams for higher productivity, and enable mature process adoption. Rather than focusing more on process compliance than business results, they help teams carefully and adaptively apply metrics, tools, and high-level standardization to their agile teams.
In FDA regulated industries, audits are high-stakes, fact-finding exercises required to verify compliance to regulations and an organization’s internal procedures. Although exploratory testing has emerged as a powerful test approach within regulated industries, an audit is the impact point where exploratory testing and regulatory worlds collide. Griffin Jones describes a heuristic model-Congruence, Honesty, Competence, Appropriate Process Model, Willingness, Control, and Evidence-his team used to survive an audit. You can use this model to prepare for an audit or to baseline your current practices for an improvement program. Griffin highlights the common misconceptions and traps to avoid with exploratory testing in your regulated industry. Avoid mutual misunderstandings that can trigger episodes of incongruous behavior and an unsuccessful audit.
Open source development combines distributed teams, resource constraints, and an overload of end user input. Despite these challenges, the velocity of many popular open source projects is measurably higher than that of their enterprise counterparts. The time has come to take the lessons learned from open source and adapt them to enterprise agile. Mik Kersten begins with an examination of successful open source projects and their approaches to agile delivery. Then he reviews the overlap of open source approaches and agile methods, identifying ten great practices that agile practitioners can apply to improve their collaboration and productivity. Each practice is grounded in empirical data that Mik collected from public open source websites. To provide an intuitive appreciation for the open style of agile delivery, Mik illustrates with graphics and visual aids how open source collaboration evolves and grows over time.
Agile developers often face the difficult task of defining user stories from business rules for complex applications-medical, embedded, insurance, banking applications, etc. In his consulting practice, Rob Sabourin helps teams elicit and describe stories for thorny business rules, multi-path conditions, time/event triggered activities, awkward dynamics, special cases, unusual constraints, exceptions, and non-functional characteristics. Using the popular board game MONOPOLY as a metaphor, Rob shows you how to develop user stories that focus development in different business contexts. He models MONOPOLY stories around personas-the little token players move around the board. If you land on Boardwalk’s hotel after rolling a third double, you Go to Jail rent free. Rent is not owed unless requested and is exempt if the landlord procrastinates.
Every day more agile practices and styles emerge, overlap, and complete. This proliferation challenges you to choose from among XP, Scrum, Lean, Kanban or the ways of the Lean Start Up crowd. Instead of stumbling onto one path or another, come to this session where David Hussman teaches tools for assessing and designing an agile process or set of practices which speaks to your needs and constraints. David covers selecting product planning tools like user stories, iterative delivery tools like kanban boards, tracking tools like burn up and more. If you want to clear the fog surrounding what will really help you, stop in and ask your questions. You will find answers.
As a tester on an agile team, are you still creating lots of scripted test cases the old way? Are you still caught in the classic waterfall-always behind-while the rest of the team is doing Scrum and looking forward? Then, change course and work with your team to become a test specialist, coordinating testing rather than only doing testing. Henrik Andersson describes his experiences on a Scrum team and their transition to his test specialist role. To orchestrate such a change, they needed new tools and approaches. So, Henrik gives a short introduction to behavior-driven development. For developing automated unit tests, he describes how their team learned to write tests in English-like Gherkin notation. Then, he demonstrates Developers’ Exploratory Testing, in which the entire team tests together and shares joint responsibility for the quality of the software.
Relentless automation is the sign that your software team has discovered how valuable their time is and how much of their day can be wasted performing trivial tasks. Using Jenkins, an open source tool as an example, Jared Richardson demonstrates how to get started with continuous integration, a powerful automation technique that binds your team together and help ensures that your project runs smoothly and efficiently. The concept is simple-after every code check in, code is compiled and comprehensive automated tests are run. However, like so many great techniques, it’s easy to describe but difficult to master. Jared explains how continuous integration, implemented with the appropriate tools, forces frequent developer integrations, thus eliminating a large amount of uncertainty and project jitter.
Unlike traditional requirements-formal specification documents produced mostly up front-agile requirements are elicited and recorded in smaller units-called stories or user stories that are generated quickly with a just-in-time approach. Through the INVEST approach-Independent, Negotiable, Valuable, Estimable, Small, and Testable-Ken Pugh shows agile teams how to produce stories that offer the most value with the least effort. He explains the relationship between stories and traditional requirements models, such as use cases and state-event-response tables, and describes how to develop more details for stories only on an as-needed basis. Ken demonstrates ways to break large stories down into smaller, easier-to-estimate ones that address the needs of business analysts and developers.