Not every continuous delivery initiative starts with someone saying "drop everything. Let's do DevOps." Sometimes you have grow your practice incrementally. And sometimes, you don’t set out to grow a practice at all-- you are just fixing problems with your process, trying to make things better.

I'll walk through a case study of how our team worked on an exemplar project for the Department of Defense to show that agile could work in a decidedly waterfall culture. I’ll also discuss techniques and tools we used to bring a DevOps mindset and continuous delivery practices into an environment that wasn't already Agile.

I'll talk about how we were able to start in development, where we had the most control, with a "let's starting being Agile" initiative and working on "why is continuous integration important?" From there, we tackled one problem after another, each time making the release a little easier and a little less risky. We incrementally brought our practices through other environments until the project was confidently delivering working, QA-tested, security-tested releases that were ready for production every two weeks. I’ll discuss the journey we took and the tools we used to get to build quality into our product, our releases, and our release process.

Developing a delivery pipeline means more than just adding automated deploys to the development cycle. To be successful, tests of all types must be incorporated throughout the process in order to be sure that problems aren’t slipping through. Most pipelines include unit tests, functional tests, and acceptance tests, but those aren’t always enough. I’ll present some types of testing you might not have considered, or at least might not have considered the importance of. Some types will address code quality, others code security, and some the health and security of the pipeline itself.

I’ll talk about specific tools we used to supplement our pipeline testing. I won’t get into how to use each tool-- this is more of a series of teasers to encourage people to look into the tools, and even letting them know what types of tools and testing opportunities are out there.

Our roadmaps and backlogs are usually littered with pet projects, squeaky wheels, and recent ad hoc items that gain priority simply because they are the latest shot across our bow. Impact mapping is a powerful practice that helps us identify and align our work to the most valuable business goals and mission objectives and avoid many of the common challenges that arise from an unfocused set of work priorities.

Impact maps help us visualize quantifiable benefits that deliverables should produce towards our business objectives. They allow us to focus our work on those deliverables that move the needle the most, not just deliver features. The practice is a great way to communicate assumptions, create plans, and align stakeholders as well as aid in strategic planning, roadmap management, and defining measures of success and quality.

This workshop will provide an appreciation for the power of impact mapping by walking you through building your own impact maps and the facilitation process for doing so in your own organization. You will leave the workshop having participated in a tangible example of the technique, and having gained an understanding of best-practices for facilitation with a focus on an impact map’s outputs and how they lead into the creation of actionable user stories when completed. Hands-on collaboration with your fellow attendees will help encourage your own application of this technique in your real world road-mapping and backlog refinement activities.

Everyone wants to know which Agile metrics really count, and why. But a lot comes down to context: who's asking, what decisions are on the horizon, how you communicate, and so forth. Add scale, and you've got a major challenge.

David Bujard, Dante Vilardi and Nate Conroy have spent the last few years trying to figure how to make agility measurement effective at a big federal program. In this talk they will discuss lessons learned from numerous experiments -- those that produced results, and those that didn't.

David and Dante are Agile coaches who support a transformation program at USCIS.

Agile practices have done a magnificent job of speeding up the software development process. Unfortunately, simply applying agile practices to testing isn't enough to keep testers at the same pace. Test automation is necessary to support agile delivery. Max Saperstone explores popular test automation frameworks and shares the benefits of applying these frameworks, their implementation strategies, and best usage practices. Focusing on the pros and cons of each type of framework, Max discusses data-driven, keyword-driven, and action-driven approaches. Find out which framework and automation strategy are most beneficial for specific situations.

Other than using specific frameworks as examples, the presentation is framework agnostic, really focusing on capabilities of different types of framework, and how those might or might-not fit your company's/software's needs. In the talk, 5 different types of frameworks will be discussed: Record/Playback (Linear), Modular/Structured, Data Driven, Keyword Driven, Action Based, and of course the combination of these as Hybrids.

At the end of the talk, depending on questions, and how much time we have left, a slide with a long list of specific testing frameworks is displayed, and an open discussion of who has used what, and what has/hasn't worked for them is had.

If you are new to test automation or trying to optimize your current automation strategy, this session is for you.

Most organizations are embracing the desire to be lean, at least espousing the desire.  But what does lean mean in different contexts? Is embracing lean as a startup different than lean delivery as a midsize company or a large organization or a government agency? 

This talk will explore what it means to be lean in various sized organizations, what is the same and what is different about lean implementations based on the size of the organization.

Over the course of the last two and one-half years, Fannie Mae has worked aggressively to transform itself from a heavily silo’d and firmly entrenched command and control culture, following a gated workflow, with long release cycles, to an Agile organization.  Today, Fannie Mae is a more dynamic value oriented organization that is responsive to stakeholders, focused on achieving greater efficiency by enabling fast-feedback loops, as well as using empirical data to optimize mature and persistent agile values and practices.  

Within the larger context of the transformation to enterprise agility, this Experience Report will focus on the case for change, Fannie Mae’s journey and the corresponding challenges, benefits and key learnings realized.  Our conclusion, while it is important to build bridges with business stakeholders, mature agile teams, leverage automation and embrace the values and principles of the agile manifesto… a successful and longstanding transformation is dependent upon the unrelenting focus on changing the ecosystem supporting the organization’s change at the outset.

Have you heard about BDD and want to start using it, but don't know what BDD is and which tool you should use? In this presentation I address both of those concerns -- I start by providing an overview of BDD and then compare five tools that can be used for BDD testing. I conclude by discussing the pros/cons and popularity of these tools so that you can make an informed decision as to which tool would work best within your organization.

Wonder how you can make your testing more efficient? Join Glenn Buckholz as he explores Docker, a technology that allows rapid development and deployment via containers. First, he explains exactly what composes a container, and discusses the differences between a container and an image. Once this is clear, Glenn demonstrates how Docker solves the problem of what he calls the state capture problem. When a test case produces a failure, the developer and testers often expend significant effort reproducing the issue so the developer can see the issue and fix it. Glenn demonstrates how Docker enables succinct, accurate, and quick communication between testers and developers, helping mitigate the state capture problem. In addition, testers can use Docker to load data, efficiently insert testing tools into a running system, set system state, and aid in test reproducibility. After you look at the inner workings of Docker and run through a few practical examples, you’ll find that Docker will hold an important place in your testing toolbox.

W. Edwards Deming noted that “people with targets and jobs dependent upon meeting them will probably meet the targets – even if they have to destroy the enterprise to do it.” While metrics can be a great tool for evaluating performance and software quality, becoming beholden to reaching metrics goals, especially the wrong ones, can be detrimental to the project. Each team needs to take care and understand what targets are appropriate for their project. They also need to consider the current and desired states of the source code and product and the capabilities and constraints of the team.

As one of the lead architects working with a huge codebase on a government project, I often have the opportunity to influence the teams around me into watching or ignoring various metrics. I will walk through some measures that are available to most projects and discuss what they really mean, various misconceptions about their meaning, the tools that can be used to collect them, and how you can use them to help your team. I’ll discuss experiences and lessons learned (often the hard way) about using the wrong metrics and the damage they can do.

Mobile application development has been on the rise lately because of the convenience mobile apps have to offer. Despite the recent occurrence of security breaches on mobile devices, security testing is not as emphasized as other forms of testing such as user acceptance or functional testing. An application can consist of the greatest features but will be considered unusable if hackers can exploit it. The exponential rise in the use of mobile applications for different purposes puts mobile devices in significant danger of being hacked or compromised. In today’s world, mobile applications are used for various purposes and store Personally Identifiable Information (PII) and financial information. Due to the sensitivity of customer data, mobile applications should be built and tested with security in mind. Strategies that cover how to properly test mobile apps for security issues will be discussed.

Housing and Urban Development (HUD), a federal agency committed to creating affordable homes for all Americans, has a history of systems development steeped in waterfall practices, a history of failed IT programs, and a culture that ran in direct opposition to Agile/DevOps. It often took weeks to provision a virtual machine and years for an application to get into Production.

In a little over a year, a small team of DevOps engineers has helped modernize the agency’s legacy infrastructure in an effort to prove Agile and DevOps can work across the organization. I will present a case study that discusses how we were able to bring 10 new applications into Production in a few months time using the Cloud and DevOps. I will discuss the challenges we encountered along the way and walk through how we were able to create a culture of shared code, infrastructure and shared purpose across multiple programs and contractor teams. In addition, I will explain how to leverage Jenkins, Chef and Azure to create a repeatable, iterable DevOps pipeline that made this transformation possible.

A large part of the success of agile adoptions is due to the automated testing approach used in agile projects. Because many of these techniques were pioneered in the development of web applications it can be hard to see how these techniques can be leveraged for a project where the software being built is for an embedded application. Discover ways to leverage agile testing techniques for embedded systems. Whether you are building a medical device, embedded controller, or Internet of Things device learn how to leverage these testing practices to create fully automated tests that fit into a DevOps build pipeline and help your team create higher quality, more reliable software. Test automation is the best way to maintain and execute a comprehensive suite of regression tests that allows you to take back control of your testing process while increasing test coverage. Learn how to be in control of your test process by stepping up your test automation to the next level.

Embedded development and Internet of Things development is often done on platforms that lack modern software development and test automation tools. The more esoteric or the smaller the target audience, the less likely tool vendors are to create products that directly support the deployment environment. This can make getting started with test automation using older tools that are not as actively supported by vendors can be a challenge that has to be overcome by a team that wants to move toward a Continuous Deployment process.

This session is aimed at people that are trying to adopt agile and continuous delivery with embedded technology, but might be worried that it can’t work in their particular environment due to their industry, technology stack, culture, or regulatory environment.

Zephyr is a tool for managing manually-executed test cases, and Behave is a Python framework for writing BDD-style automated test cases. Is it possible to leverage the benefits of both Zephyr and Behave? This presentation will describe how a bio-medical device company, as part of their Agile adoption, underwent the following evolution in their test management practice:

• Managing test cases with monolithic Word documents.
• Managing those same test cases in Zephyr.
• Writing those same test cases using the Behave framework.
• Maintaining a master copy of the test cases in Zephyr while storing the implementation of each test step in version control.

This presentation will also discuss a tool that was used to generate Behave feature files from Zephyr test cases and how that tool was integrated into both testers' workflows and the CI/CD pipeline.

If you haven't heard of The 12 Factor App, you probably will soon. Think of it as "the agile manifesto for DevOps." This talk helps you quickly become familiar with the basics of the 12 Factors that make applications cloud ready or "cloud native."

This talk allows you to trade 10 minutes of your time in order to get a bit smarter. Learn *just* enough to be dangerous, and use that knowledge to impress developers by spewing buzzwords like persistence, disposability, statelessness, and port binding. At least be able to push back intelligently when someone is telling you the app can't be put on the cloud. Learn what is meant by "livestock, not pets" and where to find out more if the talk sparks your imagination.

All companies tell lies. All executives endorse lies. And all employees live lies.

We must pretend we are amazing, and brag to our peers about how much farther ahead we are, than they are. We change the narrative to suit our lies. We have reports to prove our lies.

This happens at EVERY company.

When you look at Facebook feeds – all you see is pictures of vacations. Smiling kids. BBQs. Clean pools. You never see the miserable couple, the dirty laundry, or the crying kids.

Enter Facebook Agile.

We are conditioned to hide the bad $#!t that is going on around us. There’s no reason anyone has to know what’s really going on (even though most people know what’s going on).

Our leaders are afraid of what other peers might think. Or worse, what other “senior management” might perceive or judge. So they choose not to be leaders, despite the obvious need for leadership.

This session will provide an experience report on what leaders can do to embrace transparency, trust, and courage. Building a culture of continuous improvement starts with embracing the things that aren't working, instead of hiding them to avoid overhead.

The latest version of the OWASP Top 10 Vulnerabilities is about to be finalized. This talk discusses how to use these guidelines, both old and new, to perform security testing. In too many instances, security is the last phase of the SDLC. Using the OWASP Top 10 list, developers and testers can become more aware of potential vulnerabilities. This will improve their coding and testing skills, allowing them to build more robust code.

This presentation discusses each of the latest vulnerabilities defined in the 2017 version of the OWASP Top 10. It includes testing strategies or failure scenarios which lead to exploitation. Best practices are discussed, all within the condensed time frame of a 10 minute firetalk.

I have interviewed 14 of the 17 Agile Manifesto authors for a special podcast project. Originally the intent was to capture the intent of authors and to chronicle the manifesto story. What emerged was much more. The story of why the event was needed, what the vision was, and what we have ruined in agile we all artifacts of the project. One beautiful outcome was the emergence of 3 themes in all 14 conversations. This talk covers the real story behind the rise and fall of Business Agile in industry and what we can do to reclaim it.

In the 1040 environment of strict compliance, frequent audits and heavy penalties, the IRS has been pursuing the adoption of agile practices in order to realize faster project delivery that also result in better quality products. We now have bright spots throughout the enterprise, but getting here was a journey in which we had to adapt the traditional teachings of Scrum to the IRS culture. In this presentation, we will discuss the agile transformation journey of the IRS and provide the audience with a transformation framework that accounts for our lessons learned in a bureaucratic organization. The IRS is by no means the pinnacle of Scrum, we have a lot to learn. We hope that by sharing our challenges, other agencies undergoing transformation efforts will be able to avoid our missteps and learn from our actions.

TSA Agile Services (TAS) began on January 4th, 2017 after extensive collaboration with contracting officials, various bids, and the Agile community. Come hear the aspects that have enabled successful delivery within a government agency. TAS encompasses over 65 applications supported by a team of 80+ people. Also - because transparency is a large key to our success - we will cover the failures we have experienced and the struggles we are still working on. Lastly - it is important for contractors and government to work closely together - this presentation will be co-presented by two Agile Coaches: one is a federal employee and the other a contractor.