The talk walks through lessons learned from a specific government project, jumping head-first into agile, open source, and (oh dear) the cloud. In the jet plane metaphor, it's not about the theory of why a plane should fly (as a physicist), but about the big and little forces that will act on it in practice (as a test pilot).

The federal government, and many local governments, have embraced agile. This has been helpful in terms of incremental progress for the "how" of building software.

However, it's not enough.

The next big shift is when government agencies lift their focus from IT project delivery to digital product management - focusing on the "what" should be built and "why" it should be built. Such a shift will move agencies from incremental progress in delivering mission value to a ground-breaking shift in how missions are supported via technology.

Most government agencies are becoming 'agile'. A few are actually diving in to focus on frequent delivery of software that creates business value. This is not about 'agile' the easy way - implementing a few ceremonies, titles, and buying a software package, then declaring victory. This is about agile the hard way - the stubbed toes and small victories that open the door to lasting change.

The talk walks through lessons learned from a specific government project, jumping head-first into agile, open source, and (oh dear) the cloud.

Many professionals get excited about agile. I don't get excited about agile, and I'd argue that you shouldn't either. This agile-first mindset is counterproductive and dilutes the quality of discussion about our craft.

What I get excited about is building great software. Agile literature provides a useful toolbox that can help us do that better.

Listen to me wax curmudgeon for a few minutes, then invite counter-points from the audience. Change my mind - I no doubt lack some context or experience. My opening salvos to spur debate include:

• Agile shouldn't be applied to non-software projects.
• Agile coaching is overrated.
• Projects or job titles should not include the term "agile".
• Don't put certifications in your e-mail signature.

Test automation is hard. Adding test automation to a complex existing application is harder. Worry not, a pragmatic, incremental path to roll out automated testing does indeed exist, despite what some developers will tell you. 

The talk lays out the process to get started small, with working automated tests on day 1, and work from there. We describe and demonstrate the tools, including cucumber, selenium, rspec, and more. We discuss how we start simply, then gradually integrate tests into an automated process, i.e. your CI pipeline.

The talk is mostly practical. A few overview slides provide context of the moving parts. Most of the time is spent on giving you the path to begin testing tomorrow!

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.

Visual artifacts are a great way to engage with users and get feedback. We used to do lots of mockups in tools like Balsamiq. Our teams are now good enough at creating real code prototypes that we tend to work out ideas in real, interactive applications. The talk discusses the tradeoffs and shows real demos of what it takes to quickly make prototypes. Participants walk away with a stack of tools they can use to start making prototypes today.

(This talk was well-received in 2015, so we can do an updated version for 2016)

DevOps as a buzzword is gaining traction, but what does it really mean? Managers, non-techies, and developers-new-to-devops will get a guided demo of development automation. See all the cool tools in action - continuous integration, automated testing, cloud deployment, etc. More importantly, we'll walk through what they do, and why that adds value to a project. 

This talk will...

• Break down the buzzwords and define some key technical practices in plain english.
• Uncover the pain that leads teams to seek greater automation.
• Demonstrate a continuous integration pipeline working in practice via live demo.
• Diminish the knowledge gap between technical practitioners and managers/analysts/coaches.
• Level-up the vocabulary of non-technical attendees.
• Introduce practices to developers who don't yet work in an automated environment.
• Spark "ah-ha" moments to convert skeptics into DevOps believers!

By the way, all of the tools in the demo are some combination of free and/or open source. DevOps doesn't have to cost a lot.

DevOps as a buzzword is gaining traction, but what does it really mean? Managers, non-techies, and developers-new-to-devops will get a guided demo of development automation. See all the cool tools in action - continuous integration, automated testing, cloud deployment, etc. More importantly, we'll walk through what they do, and why that adds value to a project. 

This talk will...

• Break down the buzzwords and define some key technical practices in plain english.
• Uncover the pain that leads teams to seek greater automation.
• Demonstrate a continuous integration pipeline working in practice via live demo.
• Diminish the knowledge gap between technical practitioners and managers/analysts/coaches.
• Level-up the vocabulary of non-technical attendees.
• Introduce practices to developers who don't yet work in an automated environment.
• Spark "ah-ha" moments to convert skeptics into DevOps believers!

By the way, all of the tools in the demo are some combination of free and/or open source. DevOps doesn't have to cost a lot.

In government, it isn’t just culture that hinders agile adoption– the problem is often codified into contracts. Our team is working to bring agile methods to our client under a contract that screams waterfall, with a firm separation between “requirements and design” vs. “build”. Yikes!

 The talk includes:

• Quick background on our contract
• Overview of the “top 5” techniques and tactics that we have employed so far
• Additional audience experiences on what has worked (or not) in solving the same sort of problems