CIO / Director

You deal with software requirements all the time. Whether you are a developer in an agile environment, an analyst who identifies and documents requirements for plan-driven development, a software designer who studies requirements as the basis for agile development, a tester who employs or often must discover requirements as the foundation of test cases, or a technical user who describes your needs to development, you need the right approaches and skills to develop and interpret software requirements.

On agile teams, testers can struggle to keep up with the pace of development if they continue employing a waterfall verification process―finding bugs after development. Nate Oster challenges you to question waterfall assumptions and replace a “test last” mentality with “specification by example.” Practice “test first” by writing executable specifications for a new feature before development begins. Learn to switch from tests as verification to tests as specification and guide development with concrete examples written in the language of your business.

Have you ever needed a way to measure your leadership IQ? Or been in a performance review where the majority of time was spent discussing your need to improve as a leader? If you have ever wondered what your core leadership competencies are and how to build on and improve them, Jennifer Bonine shares a toolkit to help you do just that.

Robust configuration management (CM) practices are critical for creating continuous builds to support agile’s integration and testing demands, and for rapidly packaging, releasing, and deploying applications into production. Classic CM—identifying system components, controlling changes, reporting the system’s configuration, and auditing—won’t do the trick anymore.

We know that teams and individuals who take ownership of their work outperform—often by 50 percent—those who don’t. And in agile, team ownership is a key principle. However, leaders often struggle with letting their teams own their work. Leaders are afraid that if they trust, their teams will fail. So leaders must create a culture of trust and help their teams take ownership. But what if the team builds the wrong product? Teams must align with the strategy and purpose of the business as well as with value to the customer. Finally, the organization must deal honestly with ambiguity.

Every large software project is unique—each with its own complex array of challenges. When projects get into trouble, however, they often exhibit similar patterns, and succumb to risks that could have been anticipated and prevented—or detected sooner and managed better. Common responses to the problems—blaming, deferring action, or outright denial—only make things worse.

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: first the developer 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.

Free? Is anything free these days? Based on her experience working with organizational leaders and her research into what drives organizational performance, Pollyanna Pixton shares six ideas—and the keys to their effective implementation—to help assure the success of your agile teams. As a bonus, her suggestions won’t cost you a thing. Pollyanna’s first free idea is how to create a culture of trust—the keystone of open collaboration—within your team and organization. The second free idea is about ownership—how to give it and not take it back.

Ken Pugh takes you beyond thinking of design patterns as “solutions to a problem in a context.” Patterns are really about handling variations in your problem domain while keeping code from becoming complex and difficult to maintain as the system evolves. Ken begins by describing the classic use of patterns. He shows how design patterns implement good coding practices and then explains key design patterns including Strategy, Bridge, Adapter, Façade, and Abstract Factory.

Every hour of every day in every country where business is conducted, the same scene plays out―dozens of well-paid people sitting in a conference room being bored senseless. Death by a thousand slides. This mind numbing, soul crushing, grotesquely expensive experience ends here and now! James Whittaker reveals the secrets to conceiving, building, and delivering a great presentation. Whatever your level of presentation skills, this tutorial will hone them. Learn how to build a compelling story from the ground up. Receive advice on how to remember and recall that story as you deliver it.

Many teams have a relatively easy time adopting the tactical aspects of agile methodologies. Usually a few classes, some tools introduction, and a bit of practice lead teams toward a fairly efficient and effective agile adoption. However, these teams often get “stuck” and begin to regress or simply start going through the motions—neither maximizing their agile performance nor delivering as much value as they could.

Many organizations are childlike. They blithely plan the project as if nothing will go wrong. And then, when something does go wrong, they are shocked and dismayed. Risk management is not just worrying about your project, and it is not about running away from risk. Risk management for software projects is all about when you make decisions and when you take action. How do you deal with uncertainty? When do you decide to deal with a risk while it is still just a risk, and when do you decide to wait to see if the risk does turn into a problem and manage it then?

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 on these expectations. If you want help to ensure the success of your agile project or 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.

One group—customers, users, and business—need a software system to help them work more efficiently or make more money, but they don’t know how to build it. Another group—software developers and testers—know how to build the system, but they don’t know what it is supposed to do. Bridging this gap is where requirements—the work products describing the system accurately and concisely while at the same time not missing important customer and user needs—are essential.

The velocity metric is often misunderstood by teams and misused by management, resulting in increased levels of stress for everyone. Management wants velocity to increase while developers want time to craft the software well. The way a team defines velocity—explicitly or implicitly—can affect its ability to meet delivery commitments. Rob Myers explores the use of velocity as a planning tool, its misuse as a productivity metric, and alternative metrics. Learn effective ways to obtain consistent estimates, evaluate related ways to plan iterations and releases, and track progress.

The Kanban Racing Challenge is an immersive workshop where you learn the basic practices of a Kanban team by building an obstacle course for radio-controlled cars. This fast-paced, competitive learning environment prepares you to immediately apply Kanban on your own software teams. Your racing team starts with a warm-up lap that explains how your Kanban Storyboard creates a “continuous pull system” and natural self-management.

If you are new to agile methods—or trying to improve your estimation and planning skills—this session is for you. David Hussman brings years of experience coaching teams on how to employ XP, lean, Scrum, and kanban. He advises teams to obtain the estimating skills they need from these approaches rather than following a prescribed process. From start to finish, David focuses on learning from estimates as you learn to estimate.