Certified ScrumMaster Training (CSM) + PMI-ACP℠ (3-days)Sanjiv Augustine
Software Tester Certification—Foundation Level (3-days)Dale Perry
Fundamentals of Agile Certification—ICAgile (2-days)Jeff Payne
Agile Tester Certification–ICAgile (2-days)Rob Sabourin
Product Owner Certification (2-days)Arlen Bankston
Join Mark Meretzky to learn how to create Android apps using the Eclipse IDE on Mac, PC, or Linux. The apps Mark demonstrates are composed of objects written in Java, plus a screen layout in XML. Find out how the Java code manipulates the XML to present a user interface including buttons, sliders, and other widgets. Draw text and graphics, respond to a touch or keystroke, and recognize a swipe or pinch. Three important design patterns involve views, which are visible areas on the screen. (1) A listener is an object whose methods are called in response to a stimulus.
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.
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.
DevOps is an emerging set of principles, methods, and practices that enables 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.
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. Michael Vizdos shares his experiences with Innovation Games®, collaboration exercises that dramatically improve the way people work together.
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.
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 product backlogs are nothing more than glorified to-do lists. Teams have lost the idea of prioritizing real business value, focusing only on finishing stories and accumulating story points. If this sounds like your team, join David Hussman and Janet Gregory as they drive a stake into the heart of lame backlogs and breathe new life into test-driven thinking that is meaningful to testers, developers, product owners, and others. Using real-world examples, David and Janet combine their shared experiences to teach tools you can use to fuse centered product thinking with end-to-end testing.
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.
The Agile Manifesto makes no mention of management. So does that mean that we don’t need managers? No. We need managers, but what they do changes in an agile organization.
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?
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.
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.
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.
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.
Agile teams deliver “potentially” shippable software at the end of every iteration—typically, one to four weeks but possibly as often as daily. This goal can't be achieved without comprehensive automated tests, a place where many teams struggle. The challenge of automating functional regression tests even frightens many experienced and competent testers. But it doesn’t have to be this way.
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.
In today’s world, multiple project management approaches abound― traditional waterfall, agile using Scrum, and the methodology of the PMBOK® Guide, to name a few.
Line up all the successful people in the world. Take away the pedigreed and the prodigies—you know the people who are going to succeed no matter what. Remove the brown-nosers and right-time-right-place lottery winners. And who do you have left? People who succeeded on purpose. Study these folks carefully, and you’ll find theirs paths to the top have common themes. James Whittaker exposes the career strategies of the ultra-successful and analyzes them in detail.
Identifying, documenting, and communicating 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, use cases, and epics 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.
As the need for testing mobile apps increases, so does the need to understand and apply test practices that cover more than just functional correctness. Randy Rice leads you through techniques for designing the right tests for your mobile applications, whether they are on the device or on a website. Learn how to know which items of functionality are important to test based on relative risk. Randy presents his visual method of how to rank important attributes including usability, compatibility, accessibility, and security, and then how to design tests for them.
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.
Much of the work of moving traditional test teams toward agile methods is focused on the individual tester. Often, the roles of test director, test manager, test team leader, and test-centric project manager are marginalized―but not in this session where we’ll focus on agile testing from the test leader’s perspective.
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.
Transitioning to agile can be difficult—and often downright wrenching—for teams, so 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. Al Shalloway shares eight steps to adopt kanban in your team and organization.
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.
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.
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.
Currently much of agile adoption—coaching, advice, techniques, and training―revolves around the agile teams. Leaders are typically ignored, marginalized, or, in the worst cases, vilified. Bob Galen contends that there is a central and important role for managers and effective leadership within agile environments. In this workshop, we’ll explore the patterns of mature agile managers and leaders—those who understand servant leadership and how to effectively support, grow, coach, and empower their agile teams in ways that increase the teams’ performance, accountability, and engagement.
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.
We have opportunities to coach people all the time. Much of what we think of as coaching is actually undercover training. Real coaching is richer—offering support while exploring options. In this interactive session, Johanna Rothman invites you to experience coaching, regardless of your position in the organization. Teaching is just one type of 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.
Innovation is a word frequently tossed around in organizations today. The standard cliché is “Do more with less.” People and teams want to be innovative but often struggle with how to define, prioritize, implement, and track their innovation efforts. Jennifer Bonine shares the Innovation Types model to give you new tools to evolve and expand your innovation capabilities. Find out if your innovation ideas and efforts match your team and company goals. Learn how to classify your innovation and improvement efforts as core (to the business) or context (essential but non-revenue generating).
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.
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.
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.
Since the dawn of computing, we've invented only two ways to get work done―the web or apps. We hunt for information on the web or we gather functionality from the app store. In each case, users must take the initiative to find the information they need. We've become used to this life of hunting and gathering, but its time is ending. A new era of domesticated information and functionality is dawning. In this new world, the web's information comes to users when and where they need it.
An agile hardware and engineering company of 500 collaborators in twenty countries, Team WIKISPEED uses test-first development practices, is run by Scrum teams, and produces road legal cars, micro-houses, and social-good projects. Joe Justice shares how their 100-MPG road car was created in just three months through object-oriented design, iterative development, and agile project management.
As if releasing a quality software project on time were not difficult enough, poor management of planning, people, and process issues can be deadly to a project. Presenting a series of anti-pattern case studies, Ken Whitaker describes the most common deadly habits—along with ways to avoid them.
In an era where college drop-outs run successful companies and creative entrepreneurs out-earn corporate vice presidents, working smart is clearly the new working hard. James Whittaker turns on their head the career rules that guided past generations and provides a new career manual for working smarter that speaks to the need for creativity, innovation, and insight. James teaches a set of skills designed for the modern era of working for companies, big or small. Learn how to avoid a one-sided relationship with your employer and ensure your passion is working for—and not against—you.
Normal people don't look at data sets just for fun; they analyze them to make business decisions. More and more often, business analysts and product managers find themselves on strategic projects that require turning large, and often highly complex, data sets into meaningful information from which conclusive decisions and actions can be derived. Analysis of big data is a reality today in most IT organizations and will grow in significance as businesses look to gain a better understanding for capturing, structuring, and learning from their data.
Mobile is hard. Mobile at scale is even harder. And automation is your only option for success as you scale. However, many organizations haven’t yet started automating their mobile development efforts. Understanding how to automate your mobile ecosystem puts you ahead of your competition. How do you actually automate the building, testing, and deploying of hundreds of mobile apps across multiple operating systems and multiple app stores? Josh Anderson explains that when compared to the tools supporting the development and deployment of web applications, mobile is in its infancy.
To accomplish anything, you need the help of others. Successful teams are composed of members who are continually improving how they interact and communicate. Collaboration, creativity, and results grow out of an environment that is honest, positive, and affirming. Improvisation is about creating a positive environment where actors take an idea and then collaborate to co-create another great idea. In today’s world, a superstar does not sit in his office and emerge with a great idea. Great ideas evolve through group interaction.
Most app teams aim for 4 stars—not 5. Why? Because delivering and maintaining a high-quality app becomes more challenging every day. Agile engineering and continuous integration put more pressure than ever on testers and quality-focused developers. Add to that the raw complexity of device and platform fragmentation, new sensors, app store processes, star ratings and reviews, increased app competition, mobile automation frameworks that only half work, and users who expect the app to not just work flawlessly, but also to be intuitive and even beautiful and fun.
We all think of ourselves as pretty smart. After all, we sent a man to the moon and can instantly send a message across the world. Unfortunately, we suffer from a nasty little thing known as the Overconfidence Effect, a bias that applies to almost everything we do, including judging our own intelligence. Overconfidence is one of the dozens of documented biases and shortcomings in human judgment and decision making.
Implementing nonfunctional requirements is essential to build the right product. Yet teams often struggle with when and how to discover, specify, and test these requirements. Many teams neglect nonfunctional requirements up front, considering them less important or unrelated to user requirements; other teams specify them incompletely or with untestable and non-measurable attributes.
Organizations now understand that self-organizing teams perform better. Unfortunately, it’s extremely difficult to find the right balance between control and empowerment that works for your teams in your context. Even after your teams begin to self-organize, you are not finished. You should increase the level of self-organization over time as your teams mature. Shawn Button and Chris Farrell present a concise acronym that can help you empower your teams: BEGIN―Boundaries, Empowerment, Goals, Ingredients, and Nurture.
Effective communication is one of the most critical factors for success in the workplace. For software professionals, it is critical to understand how best to present information to your target audience in a way that they will understand and then take the action you want. Jennifer Bonine presents ideas on mastering politics, reading your colleagues and bosses perspective on how they want to receive information, and techniques to use if you’re not getting the action you want from your interactions.
Many free security testing tools are available, but finding ones that meet your needs and work in your environment can involve substantial time and effort. Especially when you are just starting out with security testing, finding reputable tools that do what you need is not easy. And installing them correctly just to evaluate them can be prohibitively time consuming. Kali Linux is a free Linux distribution with hundreds of security testing and auditing tools installed. Gene Gotimer gives an overview of Kali Linux, ways to effectively use it, and a survey of the tools available.
Even the fastest agile teams can struggle when we “test at the end.” As automation efforts fall behind, untested features pile up, and so does the pressure to cut corners. By contrast, Specification by Example “tests first” by writing automated specifications for new features using concrete examples in plain language. This collaboration focuses everyone—from analysts and customers through developers and testers—to the same definition of “done.” Join Nate Oster as he explains his skeptical journey from traditional testing to Specification by Example.
Agile has not only gone mainstream, it’s gone global. Data on agile team performance, time-to-market, and quality have emerged in the past decade. In 2012, a group of Columbus, Ohio, companies—business, IT, and financial services firms—participated in the first ever “Columbus Agile vs. the World” study. They collected velocity, schedule, effort, staffing, and quality data which were compared against QSM’s Software Lifecycle Management (SLIM) database. Analysis revealed delivery was 31 percent faster with 75 percent fewer defects than industry norms. Enter Munich, Germany.
Agile enables teams to deliver software with higher consistency and quality. With more frequent release cycles, it's critically important that everyone in your organization focus on the same customers. Creating personas keeps everyone on the product team―product owners, engineers, support, and marketing―focused on delivering for the same key customers. In agile development, the smallest unit of innovation is the user story, and it begins with a customer, represented by a persona. With each completed user story, your organization makes a contribution to that customer.
With the increased demand of short iterations, less time for formal testing, and increasingly complex applications, your daily testing habits must change. Session-based test management (SBTM) starts with Exploratory Testing and adds some structure to make it more focused, accountable, and reportable. Thread-based test management (TBTM) organizes Exploratory Testing around threads of activity, rather than test sessions or test artifacts. Michael Albrecht has combined SBTM and TBTM into xBTM™ to take full advantage of both.
The question of how much design to do up-front on a project is an engaging conundrum. Too much design often results in excess complexity and wasted effort. Too little design results in a poor architecture or insufficient system structures which require expensive rework and hurt more in the long run. How can we know the right balance of upfront design work and emerging design approaches? Al Shalloway shows how to use design patterns—coupled with agile’s attitude of “don’t build what you don’t need”—to guide your design efforts.
The rate of technology innovation continues to accelerate, creating a demand for businesses to quickly deliver software that keeps pace with customer expectations. From development teams working across multiple locations to numerous tools within IT, releasing software in any enterprise has always been a painful, risky, and time-consuming process. While methodologies like agile and DevOps have reduced the release cycle time, organizations can now combine these methodologies with the cloud to deliver software even faster.
Organizations often build products with minimal customer involvement. Consequently, they often build products that are different from what the customer actually wants or what the customer will pay for. Lean startups take a different approach and involve customers at every stage of product development. Ram Srinivasan describes how to run a business based on the lean startup approach. Ram begins by playing a collaborative game that explores the marketplace. Delegates self-organize into teams and try to run a profitable business making widgets.
“We could not test this because…” Every technology professional has experienced issues during system testing when unit testing was overlooked or cut short. Every project team has hit roadblocks during system testing when dependent systems or complicated data have been unavailable. Service virtualization is a tool that eliminates the waiting and the excuses, making thorough and complete unit and system testing realistic. Done well, service virtualization improves defect detection and resolution in every phase of a project—driving down cost while improving quality.
Do your developers want to try a new approach but are constrained because your customer or project manager isn’t interested in changing? Heather Oppenheimer shares the story of how one company was able to reconcile the development team’s desire to use Scrum with the customer’s requirement for status reporting based on waterfall phases. When they started, the project managers were complaining that they weren’t getting the status information they needed, and the developers were whining that their priorities were being changed daily.
As our systems grow and are composed of numerous new-to-market technologies, testing becomes more complex and difficult. If you feel limited by the traditional ways your team designs tests, you can find out with Jeanne Peng how to animate test design and improve test coverage by using heuristics, mnemonics, and mind maps. Jeanne and her colleagues use these techniques to help them trigger and develop new test ideas, including their in-house Integration Maturity Level and the widely used SFDPOT mnemonic.
Big Data is here to stay and with it comes a deluge of new buzzwords and acronyms. Phrases like NoSQL; Document Database; Velocity, Volume, and Variety; Hadoop; and Map Reduce are now commonplace. To complicate matters further, different people define these phrases slightly differently. Jon Mills explains what Big Data really means and pulls back the curtain on the buzzwords surrounding it. Jon explains the origins of NoSQL, what the various NoSQL databases are, and when each is used.
Healthy conflict helps build stronger teams. This should not come as a big surprise. Yet, leaders are all too familiar with the struggle to get members of teams to appropriately resolve their own conflicts. Tricia Broderick faced this challenge until she stopped taking ownership of the conflict and its resolution. Although conflict situations can be dramatically different, underneath most conflicts is a misalignment between perceptions and intentions.
Technical debt happens, either via strategic decisions or inadvertantly as a project progresses. Debt can slow down a project and represents a risk that is not always apparent to those outside the project. Teams must find ways to work technical debt resolution activities into sprints and get agreement from external management to reduce it. David Croley explores the sources and types of technical debt and discusses the costs associated with ignoring it. David discusses techniques for making technical debt visible and quantifiable, and shows how to reduce it in an agile fashion.
The Mismeasure of Software: The Last Metrics Talk You'll Ever Need to Hear Lee Copeland claims that most organizations have some kind of metrics program—and almost all are ineffective. After explaining the concept of measurement, Lee describes two key reasons for these almost universal metrics program failures. The first major mistake people make is forgetting that the model we are using for measurement is not necessarily reality. The second major blunder is treating ideas as if they were real things and then counting them.
Many teams and organizations have found agile methods help them produce more. Where critical thinking is alive, a more important question arises: Are we producing the right thing? Even though agile tools and processes have helped produce more, they often fail to help us produce the right product, change our focus to product over process, or improve product learning.
Please click here for more information.