Speed.

It's been a driver in our industry before it was even an industry. The more Agile becomes more mainstream, the more we think it's part of the package. Books are out promising that certain frameworks can deliver twice as much in half the time. And yet, teams still struggle delivering what's expected of them.

Once I started asking people of all levels of leadership what they thought speed would give them, it allowed me to develop some experiments around those expectations.

Please join me for a case study where we discuss the need for speed, the origins of that desire, and the ways it manifests itself into deliverables. My desire is for the audience to take away some powerful learning into their places of work. Only by understanding the expectations around speed can we reset them into an environment built around trust and support for motivated individuals.

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.

Good retrospectives (you know, the ones that actually lead to real change?) rest on three pillars:

1. people,
2. process, and
3. follow-through

What makes retrospectives so difficult is that if any of these three pillars starts to crack, it's next to impossible to succeed. Ultimately, getting the right people in the room, utilizing a good process to facilitate the conversation, and following-through on the learning outcomes depend on having an organizational culture that encourages learning, transparency, feedback loops, and continuous improvement.

If this sounds like your company already, then great! This talk is not for you. For everyone else, join us to explore the current trends of employee engagement, how they overlap with agile retrospectives, and the true opportunity each team member has to improve the quality, speed, and outcome of their work. 

Unlike most government agencies, the Consumer Financial Protection Bureau (CFPB) uses open source to develop their public website.  They have evolved a set of best practices to help manage the mostly remote contributors over the 5 years of developing the site.

This talk will focus on what works and what other agencies can do to emulate their success. It will also talk about current pain points and ideas for mitigating these

Retrospectives are one of the events in Scrum which give opportunities to a Scrum Team to inspect itself and create a plan for improvement. However, very often, this event tends to become boring and get away from the answers to three basic questions, What Went Good, What Went Bad and What To Improve. For that matter, at times team may not have food for thought and hence they disengage from these questions. So, what needs to be done or in fact, what can be done in such scenarios? Well, Retrospectives are all about figuring out what needs to be done. But, how do you know what to do, if you do not know what you did. For starters, measuring a team’s progress on Sprint by Sprint basis might be a solution. Having such data might not solve many problems, but, it could certainly expose them. There are three basic metrics, which have been found to be beneficial for teams’ progress and also thought triggers in Retrospectives. As Mike Cohn once said, measure only what can be measured. Metrics can be misleading, hence it is up to us to measure what makes sense and use it to improve the team.

Every developer has used a boolean flag to solve a problem with their code.

This is wrong and it should stop