Agile Development

On agile teams, testers can struggle to keep pace with development if they continue employing a waterfall-based verification process—finding bugs after development. Nate Oster challenges you to question waterfall assumptions and replace this legacy verification testing with acceptance test-driven development (ATDD). With ATDD, you “test first” by writing executable specifications for a new feature before development begins.

Although first generation agile methods have a solid track record at the team level, many agile transformations get stuck trying to expand throughout the organization. With a set of principles that can help improve software development quality and productivity, lean thinking provides a method for escaping the trap of local optimization. While agile teams can use lean principles to improve their practices, larger organizations can embrace lean to solve problems that commonly plague company-wide agile endeavors.

Many organizations have achieved agility at the team level only to be unable to achieve it across teams. The Scaled Agile Framework (SAFe) provides both a vision and method for how to achieve this. SAFe is the first documented framework that can be used to scale agile throughout an organization. It is a combination of lean, kanban, and Scrum—lean to provide a context for an organization, kanban to manage the flow of projects, and Scrum to provide agile at the team level. Beginning with an introduction to lean and kanban, Al Shalloway explains why they are required for agile at scale.

Test-driven development (TDD) is a powerful technique for combining software design, unit testing, and coding in a continuous process to increase reliability and produce better code design. Using the TDD approach, developers write programs in very short development cycles. The developer first writes a failing automated test case that defines a new function or improvement, then produces code to pass that test, and finally refactors the new code to acceptable standards. The developer repeats this process many times until the behavior is complete and fully tested.

The business analyst (BA) role seems conspicuously absent from most agile methods. Does agile make the BA role obsolete? Certainly not! But how does a BA exploit the short cycle times and collaborative nature of agile methods? Drawing from the principles of lean product development flow, Steve Adolph introduces five principles for the agile BA—Open the Channels, Chart the Flow, Generate Flow, Lean Out the Flow, and Bridge the Flow. As a communicator, the BA must Open the Channels and Chart the Flow to align all stakeholders.

Agile initiatives always begin with the best of intentions—accelerate delivery, better meet customer needs, or improve software quality. Unfortunately, some agile projects do not deliver. If you want help to ensure the success of your agile project or to get an agile project back on track, this session is for you. Jeff Payne discusses the most common causes of agile project failure and how you can avoid these issues—or mitigate their damaging effects.

Are you an agile practitioner who wants to take agility to the next level? Are you looking to gain real value from agile instead of simply more talk? Even though many are using agile methods, not all are seeing big returns from their investment. David Hussman shares his experiences and describes a short assessment that you can use to identify both strengths and weaknesses in your use of agile methods. Creating an assessment helps you look at the processes you are using, examine why you are using them, and determine whether they provide real value.

Engaged and passionate product owners balance strategic and tactical activities to ensure that the right product is built—and built right. Yet how do these product owners guide planning toward longer-term goals while also ensuring that requirements are sufficiently understood for development and delivery? Join Ellen Gottesdiener as she shares techniques for setting context and collaboratively establishing a shared understanding of requirements. Discover methods to envision the product and identify the stakeholders and their value considerations.