Explore all that the Agile Development Conference and Better Software Conference West has to offer.
From Practitioner to Published Author: A Workshop About Writing About Software (Complimentary Session)Noel Wurst, Software Quality EngineeringSunday, June 2 • 8:30am–5:00pm
In this highly interactive tutorial, Andy Kaufman helps you wrestle with real-world leadership issues we all face—influencing without authority, motivating your team, and dealing with conflict. Explore the difference between leadership and management—and why it matters—and get a clear picture of a leader’s responsibilities, including the balance between short- and long-term focus and the need to deliver results while developing organizational capability.
How do you compare the productivity and quality you achieve with agile practices with that of traditional waterfall projects? Join Michael Mah to learn about both agile and waterfall metrics and how these metrics behave in real projects. Learn how to use your own data to move from sketches on a whiteboard to create agile project trends on productivity, time-to-market, and defect rates. Using recent, real-world case studies, Michael offers a practical, expert view of agile measurement, showing you these metrics in action on retrospectives and release estimation and planning.
Identifying, documenting, and communicating software requirements are key to all successful IT projects. Common problems in requirements engineering are “How do we discover the real requirements?”, “How do we document requirements?”, and “How do user stories fit into requirements?” Erik van Veenendaal answers these questions and more while helping you improve your skills in requirements engineering for both traditional and agile projects. With practical case studies and hands-on exercises, Erik illustrates requirements issues and solutions.
Software projects are known to have challenges with estimation, uncertainty, risk, and commitment—and the most valuable projects often carry the most risk. Other industries also encounter risk and generate value by understanding and managing that risk effectively. Todd Little explores techniques used in a number of risky businesses—product development, oil and gas exploration, investment banking, medicine, weather forecasting, and gambling—and shares what those industries have done to manage uncertainty.
As infants, we begin our lives as problem-solving machines, learning to navigate a strange and complex world in which others communicate in ways we don’t understand. Initially, we hone our problem-solving talents. Then many of us find our explorations thwarted and eventually stop using—and then begin losing—our natural problem-solving ability. It doesn’t have to be that way. Psychologists tell us that people can regain lost skills and learn new ones to become better problem solvers. Payson Hall shares techniques and skills that apply to situations in real life.
On agile teams, testers can struggle to keep up with the pace of 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.
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.
Are you using agile practices but struggling? If so, you are not alone. Experienced agile practitioners know that some practices are more difficult than others, and most need tuning over time. If you are looking for ways to get more value or improve your skills, this session will pass your acceptance tests. David Hussman shares his coaching tools for improving and tuning practices including product planning, roadmapping, story writing, planning sessions, and stand up meetings.
Alan Shalloway 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. Alan 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.
Scrum is a popular and proven project management framework for rapidly changing development projects, especially those with significant technology uncertainty or evolving requirements. Since its inception fifteen years ago, Scrum has grown to be the leading agile methodology, boasting nearly 100,000 Certified ScrumMasters. In this highly interactive (no slides) introductory session, Mitch Lacey serves up the tools you need to get started with Scrum.
In this interactive session, Scott Ambler explores a vitally important, nitty-gritty, down-in-the-weeds aspect of agile—how to take an agile model-driven development (AMDD) approach to enhance and scale your software delivery capabilities. Correctly applied, AMDD enhances your modeling and documentation efforts, streamlines agile development, and reduces false starts and rework.
Robust configuration management (CM) practices are essential 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.
While 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.
Your shrinking project deadlines are increasing the need for automated tests—but, simultaneously, reducing the time available for writing them. The system requirements are continually changing. The implementation is changing. You spend more and more time maintaining old tests, leaving less time to write new ones. The tests take longer and longer to run. And when they fail, the problem is as likely to be in the tests as in the system.
Has this happened to you? You try to implement a change in your organization and it fails. And, to make matters worse, you can't figure out why. It may be that your great idea didn't mesh well with your organization’s culture or a host of other reasons. Jennifer Bonine shares a toolkit to help you determine which ideas will—and will not—work well within your organization.
Are you having trouble getting people in your organization to agree on a path forward? Is collaboration sometimes more like a contest to see who can yell the loudest? Is it difficult to get customers to give you the information you need to create a product charter or unambiguous requirements? Achieving meaningful collaboration with a diverse group of people can be very difficult. Bob Hartman shares his experiences with Innovation Games®, collaboration exercises that dramatically improve the way people work together.
Ken Whitaker shares pragmatic techniques to help project managers and software development leaders put into practice innovative scheduling techniques, make consistent customer-centric decisions, reduce project risk, quickly negotiate with product owners the most important project scope, and transition teams to become more agile. Ken shares revealing statistical data on how waterfall is simply not suited for modern-day adaptive software development projects. With fellow participants, you’ll spend time performing a “Scrum walkabout” to get the idea of just how an agile project really works.
DevOps is an emerging set of principles, methods, and practices that empower teams and organizations to rapidly deploy systems and application updates while maintaining—and even improving—quality. By lowering barriers between development, testing, and operations, DevOps practices can add tremendous business value to software projects and systems. Bob Aiello explains how to prepare for and implement continuous delivery—in both agile and non-agile environments—employing industry standard processes and automated frameworks.
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 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.
To be most effective, test managers must develop and use metrics to help direct the testing effort and make informed recommendations about the software’s release readiness and associated risks. Because one important testing activity is to “measure” the quality of the software, test managers must measure the results of both the development and testing processes. Collecting, analyzing, and using metrics is complicated because many developers and testers are concerned that the metrics will be used against them.
Testability is the degree to which a system can be effectively and efficiently tested. This key software attribute indicates whether testing (and subsequent maintenance) will be easy and cheap—or difficult and expensive. In the worst case, a lack of testability means that some components of the system cannot be tested at all. Testability is not free; it must be explicitly designed into the system through adequate design for testability.
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.
User stories are a powerful technique agile teams used to communicate requirements. Yet all too often, the stories are poorly written or even incomprehensible. Some stories are too big and overlap across delivery cycles. Others are too small and don’t deliver sufficient details for developers. Join Paul Reed to learn the Seven Product Dimensions—the 7 D’s—which yield “just right” stories that users and product owners can write and developers can understand. Explore and experience the Seven Dimensions: user, interface, action, data, control, quality, and environment.
Because transitioning to agile can be difficult—and often wrenching—for teams, many organizations are turning to kanban practices. Kanban, which involves just-in-time software delivery, offers a more gradual evolution to agile and is adaptable to many company cultures and environments. With kanban, developers pull work from a queue—taking care not to exceed a threshold for simultaneous tasks—while making progress visible to all. Alan Shalloway shares eight steps to adopt kanban in your team and organization.
Why bother with measurement and metrics? If you never use the data you collect, this is a valid question—and the answer is “Don’t bother, it’s a waste of time.” In that case, you’ll manage with opinions, personalities, and guesses—or even worse, misconceptions and misunderstandings. Based on his more than forty years of software and systems development experience, Ed Weller describes reasons for measurement, key measures in both traditional and agile environments, decisions enabled by measurement, and lessons learned from successful—and not so successful—measurement programs.
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.
Scaling agile from the team to the program to the portfolio level of the enterprise requires the inclusion of additional roles—product manager and system architect; activities—release planning and program retrospectives; and artifacts—portfolio and program visions and backlogs. Practitioners must constantly increase scale and scope, while keeping both the system and the process lean and agile.
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.
Your organization is doing well with functional, usability, and performance testing. However, you know that software security is a key part of software assurance and compliance strategy for protecting applications and critical data. Left undiscovered, security-related defects can wreak havoc in a system when malicious invaders attack. If you don’t know where to start with security testing and don’t know what you are—or should be—looking for, this tutorial is for you.
You’ve tried and tried to convince people of your position. You’ve laid out your logical arguments on impressive PowerPoint slides—but you are still not able to sway them. Cognitive scientists understand that the approach you are taking is rarely successful. Often you must speak to others’ subconscious motivators rather than their rational, analytic side. Linda Rising shares influence strategies that you can use to more effectively convince others to see things your way.
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.
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.
An organization’s ability to make improvement, whether for greater agility or other goals, involves two components—a technical component and a people component. The technical component is generally logical, linear, and relatively straightforward, and the technical change agents are often skilled at implementing the technology. On the other hand, the people component is never straightforward.
Software Manager’s LabWednesday, June 5, 2013
David Wylie, Solutions IQ
Many organizations have successfully adopted agile on a subset of their projects, while, at the same time, struggled to do so across entire departments. A common challenge is the need to overhaul the IT governance strategy so that it will work with agile teams. This is a serious issue for governance bodies with little or no practical agile experience, particularly when experience shows that traditional governance strategies increase the risk of failure on agile projects. Scott Ambler introduces The Disciplined Agile Delivery framework for managing and monitoring enterprise agile teams.
Being first to market or meeting rapidly changing customer demands compels development teams to build systems while requirements are still being discovered. Developing a relational database design ahead of its requirements can paint you into a corner—with a product that suffers from legacy-like limitations. Jonathan Wiggs shares ideas to solve this problem in an agile way that provides both support for the present and flexibility for the unknown future.
Who is responsible for testing on agile teams? The answer is “Everybody”—and yet this is rarely the case. Often the testers write their test cases in isolation and execute them after development is finished. Developers write their code without talking to the testers except to understand how to reproduce the latest discovered defect. Product owners elaborate requirements in isolation and then hand them off to the team only to check back at the end of the sprint. Business analysts spend their time working on documents that have questionable usefulness.
Even today, to the detriment of agile success, most organizational cultures remain delivery date-driven—resulting in delivery teams that are not focused on creating value for the customer. So how can we redirect stakeholders, the business, and the project team to concentrate on delivering the greatest value rather than simply meeting dates? Pollyanna Pixton describes the tools she has used in collaboration sessions to help participants begin the process of adopting customer-centric agile methods.
Tired of the claims that Scrum, XP, and kanban don’t scale beyond a few teams? Overwhelmed by management’s resistance to the organizational changes needed to really follow agile principles? Concerned with the lack of proven practices required to scale agile methods to the next level? Exploring the Scaled Agile Framework™, Dean Leffingwell dispels these claims and answers these questions—and more.
Vitaliy Istomov, Jamo Solutions
Siva Sundararaman, Tricentis USA
For more information on these ITPs, please click here.
Kent Beck, inventor of eXtreme Programming, defined agile success as delivering more useful functionality with fewer defects. Against that definition, early research revealed mixed success. Many organizations did not know how to measure and thus could not have “fact-based” conversations about productivity and cost. Some teams achieved faster delivery, but quality did not improve. Others found both. What factors made the difference? New benchmark analysis by QSM Associates reveals the latest productivity, time-to-market, quality, and cost patterns.
Want to get a jumpstart on agile adoption in your organization? Begin by leveraging a roadmap that Intuit has used for rolling out enterprise agile to its business units. While there is no single way to bring enterprise agile into your organization, Alan Padula describes a model that has worked repeatedly. The important first step is to create a vision of what full agile adoption looks like. Once a rich vision is created describing what people will be doing and how they will be doing it, create a roadmap, a time-sequenced plan with milestones.
One of software development’s greatest challenges is combining business needs with technical abilities to build products that customers want. Many development methodologies attempt to achieve this, but Nir Szilagyi and Janarthanan Eindhal think that few connect the dots as well as behavior-driven development (BDD), an agile development methodology derived from test-driven development (TDD) and other agile practices. Unlike TDD, which focuses on code design, BDD focuses on the customer.
On traditional projects, testers usually join the project after coding has started—or even later when coding is almost finished. Testers have no role in advising the project team early regarding quality issues but focus only on finding defects. They become accustomed to this style of working and adjust their mental processes accordingly. On agile projects, where testers must collaborate closely with customers and programmers throughout the development lifecycle, their focus changes from finding defects to preventing them.
Sathish Rajamani and Shivakumar Balasubramaniyan, Cognizant
The key impediments that prevent many organizations from ever realizing the promise of agile and lean aren’t rooted in processes or tools. The impediments stem from the organization’s leaders. Sharing an interdisciplinary overview of the most compelling science and research in the aspects of team performance, Michael DePaoli shows that it is largely ignored.
Agile development has evolved into a lifecycle that not only affects the IT department but the overall business as well. Forward-thinking enterprises recognize this and benefit from the software efficiency that agile development delivers. Through real-world examples, Jonathan Thorpe explains how enterprises can improve their agile success. Discover how successful global enterprises are applying the principles of agile development beyond just software development to a level where it affects entire business groups.
There is a common misconception that agile and CMMI cannot work together. CMMI is viewed as a documentation heavy, slow, process-driven model—the polar opposite of agile principles. The cost of documentation for an appraisal is viewed as another drawback. Join Ed Weller to see why a large organization chose to use the practices in the CMMI to complement agile, and a formal appraisal to improve and evaluate their performance.
Until 2009, the Atlassian JIRA team shipped a major release of its software every nine to twelve months. Everything was tested—every story and every bug fix—and everything still contained serious bugs. Story development moved quickly, but after the feature-complete date, several month-long hardening periods were required to make the software actually shippable. Integrating the release into Atlassian’s hosted platform took another three or four months.
A culture is the set of shared attitudes, values, goals, and practices that both describes and shapes a group. The unique challenges of creating software have demanded totally new types of corporate culture. In response, we have created agile, Scrum, and XP. These represent the birth of culture engineering and, although significant, are very primitive compared to what will follow. Jim McCarthy introduces “culture hacking,” a kind of cultural engineering that focuses on protecting personal freedom, extending openness, and embodying rationality.
Is agile—or lean, kanban, lean startup, etc.—starting to follow the path of other management buzzwords in your organization? Is it losing steam, now resembling only a minor change from the old ways? Have you compromised to "make agile work in our organization?” As organizations introduce new paradigms, they often run into roadblocks of inertia. When these are not overcome, the initial excitement and the potential benefits drain away. Treating changes such as agile as merely a software delivery approach typically means disregarding four other key facets of the agile organization.
Introducing agile development into a large enterprise is like creating a bubble of sanity in the midst of bedlam. Unless the sanity spreads, the effort is ultimately frustrating, frustrated—and fails. Jeff Marr describes the web of the enterprise ecosystem and presents strategies to build a common agile and lean vocabulary and set of practices within your organization.
There is no doubt that agile is an accepted development methodology. However, if you work in a regulated industry like health care where you have to comply with its standard operating procedures, heaps of paperwork, and frequent audits, don’t these conflict with agile’s core tenets? Chris Ampenberger describes his operating environment and the applicable regulations that define the constraints for the software development process he can use. He shares how they overcame the incongruity between agile and regulatory requirements.
Agile teams move faster when cycle times are short and code deployments are frequent. To release often, a robust suite of automated tests is a must-have. Tests are the safety net that enables fearless change. Throughout a software system's lifespan, its test suite grows, evolves, and decays. Left unchecked, test execution times increase and non-deterministic failures erode confidence. Ultimately, the test suite that once served as a change-enabler becomes an anchor, grinding progress to a halt. Scaling a test suite is complex and difficult—and vital to successful organizations.
Daily, we are told that adopting agile, PaaS, DevOps, crowdsourced testing, or any of the myriad of current buzzwords will help us deliver better software faster. However, for the majority of software development organizations, naïve agile transformations that don’t look beyond the needs of developers will fail to produce the promised results.
Most management methods in use today have been around for more than fifty years. During that time, the work has changed dramatically and so have the types of workers. The new ways of working that have emerged do not align well with the old ways of managing. In the 21st century, management must change to accommodate these new realities. Radical management involves changing the focus from stakeholders to customers, from controlling to enabling, from coordination to linking, from efficiency to improvement, and from telling to communicating.
Misconceptions abound about the way requirements fit—or don’t fit—into agile projects. Is “agile requirements” an oxymoron—two contradictory terms joined together? How is it possible for requirements to be agile? Do agile projects even need requirements? In reality, requirements are the basis for planning, analyzing, developing, and delivering agile projects. Paul Reed shares the value of requirements analysis on agile projects, the ways requirements form the basis for agile planning, and explains how effective agile teams collaborate to develop requirements.
“Inspect and adapt” is one of the basic tenets of continuous improvement, and agility in general. Holding retrospectives is one of the core processes that allows teams to look back and reflect on their progress. However, over time, teams may focus only on the product work and lose interest in their own improvement as a team.
The Kanban Pizza Game is a hands-on simulation designed to teach the core elements of a kanban system—visualize the workflow, limit your work-in-process (WIP), manage flow, make process policies explicit, and improve collaboratively.
Agile development methods such as Scrum, XP, and kanban have achieved notable success in improving speed to value, reducing waste, and raising customer and team satisfaction. Successful practitioners worldwide have cut development times, improved product quality, and reduced development cost. Underlying these agile methods are timeless lean principles—focus on customer value, respect for people, and continuous improvement. Sanjiv Augustine describes how agile teams are implementing lean management.
Are you a business analyst, wondering how you fit into agile projects? Are you a ScrumMaster who wants to work with business analysts for a stronger project team? Are you a product owner who needs to supercharge your product backlog? Mark Layton introduces you to the critical role of the business analyst on agile projects. Get the essential information business analysts need to know to be successful members of an agile project team. Learn how business analysts can use their product knowledge and requirements translation skills to support product owners and stakeholders.
Organizations are under pressure to release faster with higher quality, while business and technology environments are increasingly becoming more and more complex. How can you deploy great products quickly in such a challenging environment? Intuit, maker of TurboTax, is solving this problem with continuous delivery practices. Continuous delivery is the next stage of agile, allowing organizations to achieve greater velocity, repeatability, and sustainability through a continuous build, test, and deploy process.
A global development organization—in seven cities on three continents—has developers all using agile practices to develop complex applications. In addition to the common problems faced by distributed teams, they must deal with attrition rates in excess of 50 percent, possible loss of intellectual property, and the need to integrate the work of multiple Scrum teams into a single build. James Lynn describes an organizational structure that includes implementation teams, known as “the Factory.” Developers in the Factory often have little in-depth knowledge of the application or customer.
At the 2013 Agile Leadership Summit Kick-Off Reception, join fellow Summit attendees for complimentary food and beverages as you brainstorm agile leadership issues that will become the basis for the Summit's interactive sessions on Friday. Lisa Shoop, Director of Product Development and Agile Coaching at Sabre-Holdings, presents How to Sustain Agile Teams and Organizations and shares her insights on how to determine what's best for the team—and on the flip side, what's best for the enterprise
Agile Leadership Summit—Leading Agile Culture ChangeThursday, June 6 • 6:00pm–8:00pm and Friday, June 7 • 8:30am–3:30pm
(Additional registration is required)
