From Practitioner to Published Author: A Workshop About Writing About Software (Complimentary Session)Beth Romanik & Jonathan Vanian, Software Quality EngineeringSunday, November 10 • 12:30pm–4:30pm
Certified ScrumMaster Training (CSM) + PMI-ACP℠ (3-days)David Bulkin
Software Tester Certification—Foundation Level (3-days)Dale Perry
Fundamentals of Agile Certification (2-days)Jeff Payne
Agile Tester Certification - ICAgile (2-days)Rob Sabourin
Product Owner Certification (2-days)Arlen Bankston
Software Tester Certification—Foundation Level (3-days)Dawn Haynes
Fundamentals of Agile Certification (2-days)Jeff PayneAgile Tester Certification - ICAgile (2-days)Rob SabourinProduct Owner Certification (2-days)Arlen Bankston
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.
When you think of program management, do you think of big lumbering organizational beasts that add little value, and people demanding “When will you be done?” or “Can we add this feature before the desired release date?” Agile program management encourages small-world networks of collaborative teams that can solve problems and deliver features fast. That requires the entire program be agile and lean—using small batch sizes, integrating continuously, having short iterations, and tracking cycle time so you can coordinate across the organization.
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. But 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.
Because systems are now more complex and competition is extreme, testing for usability is critical for ensuring our products not only stand out from the crowd but even exceed our customer’s expectations. As testers, we often encounter requirements such as “The system must be user-friendly.” What does this mean? And, more importantly, how do we test against this vague notion? Join Julie Gardiner as she presents usability testing techniques to help evaluate system efficiency, effectiveness, and user satisfaction.
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.
Unfortunately, those of us who struggle with complex problems for a living don't have time to keep up with the enormous amount of cognitive science research that could help us become better thinkers, better problem solvers, and better decision makers. Having devoted more than ten years to researching the fast-moving fields that almost daily reveal new information, Linda shares what she has uncovered—some of it surprising, some even counterintuitive. She summarizes the research and provides concrete tips for improving your individual, team, and organizational abilities.
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. In hands-on exercises, learn how to replicate these techniques to make your own comparisons for time, cost, and quality. Working in pairs, calculate productivity metrics using the templates Michael employs in his consulting practice. You can leverage these new metrics to make the case for changing to more agile practices and creating realistic project commitments in your organization. Take back new ways for communicating to key decision makers the value of implementing agile development practices.
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.
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 change, reporting the system’s configuration, and auditing—won’t do the trick anymore.
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, Ken Pugh explains why they are required for agile at scale.
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 and Michael Vizdos shares their experiences with Innovation Games®, collaboration exercises that dramatically improve the way people work together.
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.
We have opportunities to coach people all the time. Much of what we see as coaching is actually undercover training. Real coaching is richer—offering support while explaining options. In this interactive session, Johanna Rothman invites you to explore how to coach, regardless of your position in the organization. Teaching is just one option for coaching. You have many other options, depending on your coaching stance. You may select a counselor’s stance if you are managing up or a partner’s stance if you are a peer.
Going far beyond the limits of a team approach to agile, Scott Ambler explores a disciplined, full-lifecycle methodology for agile software delivery. In this interactive hands-on session, learn how to initiate a large-scale agile project, exploring ways to extend Scrum's value-driven development approach to include both value and risk in the equation. Discover project governance practices that will increase your team's chance of success.
Formula 1 drivers don’t just drive faster than you—they drive differently. Accelerated Agile uses different rules, based on the core principles of agile but taken to another level, to deliver in hours and days what regular teams can only achieve in weeks or months. Accelerated Agile is for experienced agile practitioners who are frustrated with the pseudo-science of agile planning and estimation, the social pressure to automate where it doesn’t add value, the artificial commitment of sprints, and the unwelcome surprises that still derail projects.
DevOps is an emerging set of principles, methods, and practices that enable the rapid deployment of software systems. DevOps focuses on lowering barriers between development, testing, security, and operations in support of rapid iterative development and deployment. Many organizations struggle when implementing DevOps because of its inherent technical, process, and cultural challenges. Bob Aiello shares DevOps best practices starting with its role early in the application lifecycle and bridging the gap with testing, security, and operations.
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.
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.
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.
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.
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. Ken Pugh shares eight steps to adopt kanban in your team and organization.
Are you an agile practitioner wanting to take your 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 identifies both strengths and weaknesses in your use of agile methods. Creating an assessment helps you examine the processes you are using, why you are using them, and if they are providing real value.
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.
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.
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.
Planning is a tool and, like all tools, can be used for good or ill. Too much planning can be wasteful; too little planning can breed chaos. Successful teams gravitate toward “just enough planning.” Building on his years of coaching XP, Scrum, kanban, and lean, David Hussman pragmatically describes planning that promotes early and continuous learning. He details how to collaboratively create plans that allow teams to continuously measure, learn, and pivot.
Transforming an organization to become agile requires more than just changing the development process; it requires a complete culture shift. Yet, the focus of most agile transformations is on changing the process aspect of work. Sustainable, effective agile transformation affects all elements of culture—leadership style, values, organizational structures, reward systems, processes, and work habits.
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.
A lot of talk goes on in agile about how collaboration among team members helps drive a shared responsibility for quality—and more. However, most teams don't do much more than just hold stand-up meetings and have programmers and testers sit together. Although these practices improve communications, they are not collaboration! Most teams simply don't understand how to collaborate. Janet Gregory and Matt Barcomb guide you through hands-on activities that illustrate collaboration patterns for programmers and testers, working together.
Agile is now mainstream, but many companies continue to struggle. When agile is adopted, common issues occur in every organization: getting people to try agile, selling agile to management, learning how to do efficient standup meetings, fitting planning into a short window, and running effective retrospectives. When you add in scaling issues, different development styles, and outsourcing, your simple agile adoption just gets more difficult.
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 all stakeholders and team members begin the process of adopting customer-centric agile methods.
Understanding the dynamics of how teams work and how to make them work better is one of the most difficult problems in software delivery. Adopting agile methods compounds this problem by breaking up groups who used to sit together and forming new cross-functional teams, adding stand-ups, and initiating retrospectives and other new social interactions.
Developers and testers are, by their very nature, curious creatures. But when facing deadlines, they often become fixated on solving today's problem and miss the bigger picture. Over time and under pressure, they lose their motivation to learn new information and acquire new skills. Without a plan encouraging learning can be costly—and can backfire. A professional development plan should incorporate practical strategies and techniques for the entire team and managers.
Although many organizations are successfully using agile practices to develop higher quality, customer-satisfying solutions faster and cheaper, an increasing number of companies are using the same practices to develop the wrong solutions—faster and with a higher level of quality, too. Why is that? Even though most people know that assumptions are the mother of all things that go badly wrong, many “agile” adopting organizations still invest time, money, and resources developing “solutions” based solely on assumptions, opinions, and guesses.
Jim Trentadue describes the first year his organization used the cloud for its non-production needs: development, testing, training, and production support. Jim begins by describing the components of a cloud environment and how it differs from a traditional physical server structure. To prove the cloud concept, he used a risk-based model for determining which servers would be migrated. The result was a win for the organization from a time-to-market and cost savings perspective. Jim shares his do’s and don’ts for moving to the cloud.
Is a project’s fate preordained? Does a project’s past suggest its likely future? Can anything be done to influence that future when the current signs aren’t promising? Payson Hall has participated in and reviewed many projects during his thirty-year career in software development. Without claiming mystical or magical powers, Payson shares problem symptoms he has observed and discusses strategies for isolating and correcting them. He helps you learn to identify “problem seeds” that can grow into larger issues over time.
According to studies, 64 percent of features in systems are rarely—or never—used. How does this happen? Today, the work of eliciting the customers' true needs, which often remains elusive, can be enhanced using data-driven requirements techniques. Brandon Carlson describes why traditional requirements analysis is so difficult and presents a set of seven data collection approaches and analysis techniques you can employ on your projects right away. Learn how to instrument existing applications and develop new requirements based on operational profiles of the current system.
The past few years have seen a rapid increase in business efficiency through Web-based applications. Unfortunately, a dramatic increase in the number of web application vulnerabilities has followed. Insecure web applications can be disastrous for mission critical businesses and users' sensitive data. More than 70 percent of security vulnerabilities are due to flaws in the application rather than firewall breaches. Bennie Paul explains how security testing has become an indispensable part of the SDLC for businesses operating online today.
With so many technologies branded as “cloud” products, it can be difficult to distinguish good technology from good marketing. The resulting confusion complicates the work of software development teams who are trying not only to architect software effectively but also trying to accelerate building, testing, and delivering software. To cut through this confusion, Bill Wilder defines key cloud terms, compares the different types of clouds, and drills into concrete examples of specific cloud services.
Scrum has become very popular in agile development shops, but most organizations that adopt Scrum run into challenges when they expand beyond a few teams. Ken Paugh believes that you can overcome the challenging patterns of scaling Scrum by focusing on lean-flow (removing delays between the steps of a development organization’s workflow). Ken begins by discussing how cross-functional teams are a manifestation of the lean mantra of removing delays. He discusses ways to manage projects spanning multiple teams, including creating teams that don’t meet the definition of classic Scrum.
As agile practices become mainstream, compelling patterns are being revealed about defect rates, time-to-market, and effort/staffing. Industry data from QSM Associates reveals that many companies grapple with collocation, pair programming, offshoring, and combining agile with waterfall methods. Some of the best teams find significant schedule and quality implications that are literally redefining the economics of software; others are not. What factors make a meaningful difference?
Agile discussions often focus on stories, backlogs, development, and testing. At Experian they also brought product strategy management and strategy into the agile fold to ensure their teams were in lock-step with customer requirements and priorities. That resulted in the delivery of Experian’s first big data project—without adding a single new person or “big data expert.” How did they do it? Product guru Jeff Hassemer shares his (not-so) kumbaya moments of how he learned about the principles of agile within big data projects—in action.
Have you ever watched a medical drama with scenes featuring doctors making split second, life-or-death decisions? As software professional, there may be less at stake when it comes to your decisions, yet you often need to act under time pressure, limited information, and conditions of uncertainty. How do you decide whether a particular course of action will help or harm your project? Are you rational: Do you identify, weigh and compare your options? Or are your decisions more intuitive: Do you size up the situation quickly and simply “know” how to act?
Agile methods have proven their ability to improve project success rates. However, when agile methods are applied to complex projects, we need to further explore the area of effective customer involvement. According to the agile philosophy, the users must be part of the development team. But, Stefano Rizzo asks: What if there are thousands of users with good ideas dispersed around the globe and around the clock? Can a Product Owner really represent all their interests?
More than two decades ago, Richard P. Gabriel proposed the idea that “Worse Is Better” to explain why some things that are designed to be pure and perfect are eclipsed by solutions that are compromised and imperfect. This is not simply an observation that things should be better but are not, or that flawed and ill-considered solutions sometimes win out over those created with intention. Rather, many solutions that are narrow and incomplete work out better than those seen as comprehensive and complete.
When the World Trade Center collapsed, the telephone switching systems in the basement correctly diagnosed which lines were still working and continued to connect calls for several days using backup power. One factor contributing to this remarkable product reliability was the AT&T/Bell Labs practice of early systems architecture reviews. Michael Dedolph shares an architecture review method based on the Bell Labs Systems Architecture Review Board (SARB) process and discusses how that method was institutionalized and managed.
A major concern when developing new software features is that another part of the code will be affected in unexpected ways. With a typical development processes, testers often do not run a full set of product regression tests until late in the release when it is much more costly to fix and retest the product. Continuous automated regression testing to the rescue! Brenda Kise describes the team, project, and organization value and benefits of continuously performing automated regression tests throughout the development process.
To be most effective when managing a large program, the component projects should limit their batch size, create networks of people, and report status in a way that works for the entire program. For those of you who are not quite ready for agile, Johanna Rothman explains how to use staged delivery, release trains, or RUP as lean(er) alternatives to waterfall and agile. Johanna explains how to encourage project teams to create communities of practice using their social networks—start with the existing rumor mill and build on it more formally.
Managers want teams to be empowered but often don’t want to give up their decision-making authority. Teams want to be empowered but may not know how to act on the power they already have. Executives want to drive engagement and action but see only half-hearted compliance. These are examples of power dynamics at play. Esther Derby explains that words won’t matter until people acknowledge power. Once people acknowledge the fact of power, it’s possible to look at how it is affecting people and actions.
When she was little, Iris Classon was told that if you plan to go from 0 to 100 in a short period of time, you need a very good plan. So Iris made grand plans, but they all failed to deliver on her dreams and aspirations. So, when she decided to make a drastic career change from clinical nutritionist to computer programmer without ever having seen a line of code, she decided not having a plan would be her plan—embracing unpredictability and uncertainty instead of fighting it.
Unfortunately, many people focus solely on their jobs and day-to-day task delivery rather than building their career. This often results in careers that happen by accident, rather than by design. How can you build a personal brand that you can refer to when making conscious choices about your next career move? How can you build your dream career while delivering the greatest value to your organization? Jennifer Bonine describes the tools she uses in leadership sessions to help people begin the process of defining their own personal brand.
How do you properly compare the quality of two or more software deliverables without an accurate normalizing metric? The answer: You can’t. Example: If project A has one-hundred defects and project B has fifty defects, do you automatically assume project B is a higher quality deliverable? Although the number of defects is often the end user’s quality perception, defect counts may not be the right measure. An effective normalizing metric allows you to accurately measure and compare quality levels across software deliverables.
How do you know if you have too much process, too little, or just the right amount? If you ignore process completely, unpredictability and chaos can follow. If you define the process to the nth degree and follow it religiously, the work grinds to a halt. Janet Gregory shares her experiences about how to find the tastiest balance of process and creativity for your projects and organization. She proposes that a formally defined process is sometimes necessary, but that it should be the exception.
The question of how much design to do up-front on a project is an engaging one. Too much design often results in overkill, complexity, and wasted effort. Too little design results in insufficient system structures that require later rework, additional complexity, and wasted effort. How can we know what the right balance is? Ken Pugh shows how to use advice taken from Design Patterns, coupled with the attitude of not building what you don’t need from agile.
Organizations invest high levels of effort setting up elaborate employee performance tracking systems. In fact, these costly and onerous processes may even drive the wrong behaviors if inappropriate metrics are selected or employees learn to game the system. However, a simpler and more effective approach to personnel development is right in front of us. Bob Payne describes the Lean A3 problem solving and communication tool that can be used to improve processes and create a learning culture.
What is the best way to learn a new programming language or improve coding skills with the language you already use? Cory Foy has developed a new method for learning—and teaching—new programming languages and improving programmer expertise on their current languages. His approach focuses on preparing the learner to listen to what the code is saying and, thereby, changing how we approach the language. To learn a natural language, we would not start by studying prepositions, nouns, and verbs.
Companies often go to great lengths to collect metrics. However, even the most rigorously collected data tends to be ignored, despite the findings and potential for improving practices. Today, one metric that cannot be ignored is customer satisfaction. Customers are more than willing to share their thoughts in a manner that can impact your bottom line. Social media gives consumers a stronger voice than ever, and damage to your brand is only one tweet away. The question is: Are you listening to your customers?
Learning organizations seem like a great idea to just about everyone. But how do you actually create them? In many organizations, attempting to promote learning can seem daunting at best and impossible at worst—especially when you don't feel particularly empowered to do so. Matt Barcomb focuses on what you can do from multiple perspectives. He first discusses what a learning organization is and why the concept is important for the future of many organizations. Next, Matt shares approaches and considerations for growing learning environments, including common organizational pitfalls.
At the 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.
Additional registration for the Agile Leadership Summit is required to attend this event.
Agile Leadership Summit—Leading Agile Culture ChangeThursday, November 14 • 6:00pm–8:00pm and Friday, November 15 • 8:30am–3:30pm
(Additional registration is required)
