In this lightning talk, we explore the 5 attributes to look for in a ScrumMaster:

• Knowledge - Deep knowledge in Agile and Scrum
• Experience - Deep experience with Scrum teams and in Agile environments
• Coaching - Deep understanding of Coaching concepts and techniques
• Facilitation - Deep understanding of Facilitation concepts and techniques
• Servant Leadership - Deep understanding and desire to enable success for the teams and the organization

From there we look at the ScrumMaster's progression for removing impediments and addressing issues:

• Did we talk about it in the Retrospective?
• Did we discuss the impact?
• Did we identify root causes?
• Did we come up with solutions?
• Have we tried the solutions?
• What were the initial results?
• What are next steps from here?

We use the steps above to ensure:

• Our teams are not making the same mistakes time time after time
• Our teams are not having the same issues arise time and time again
• Our teams are not stagnating but rather are getting better over time

This session will arm session attendees with what to look for in a ScrumMaster and discuss how the SM uses the impediment progression to ensure we have a continuously improving team.

Think of a time when multiple contributors were all working in the same area of code at once. Ever wish there was an easy way to resolve those inevitable merge conflicts? This certainly happened for us while contributing to the pgAdmin 4 open source project. As evangelists from Pivotal, Matt Kleiman and team contributed all of their patches to pgAdmin 4 using test-driven development. Attend his talk to learn the virtues of testing and the story of trying to bring test-driven development to an existing open source community. He will walk through an example of how Pivotal extracted existing, untested code and wrapped them in tests in order to benefit the entire community.

I spent January in Antarctica hanging out with penguins, whales, and seals. It was about as different from my day-to-day work as can be. And yet, on my long flight home, I couldn’t help but reflect on how well my trip aligned with one specific value of the Agile Manifesto: “Responding to change over following a plan.”

Antarctica is a place that truly drives home why we need both planning AND, even more importantly, the ability to respond to change. This trip helped me fully appreciate how true this value is - and not just in software development. And after being stuck in Antarctica six days longer than planned, it also built up my empathy for team members struggling with dynamic situations!

Did you know that your brain tells you stories all day long, and that if they are good stories, you believe them? Come to this entertaining interactive session to experience some "cognitive illusions" for yourself, and learn what they demonstrate about how our brains' work. Cognitive science and behavioral psychology offer important insights for agilists, insights that can help us work more effectively with our co-workers and clients. You will learn how awareness of our brains' tendencies is a powerful tool to overcome our own innate cognitive bias, and the cognitive bias of others. This newfound awareness can open you to more varied perspectives in order to tell yourself a story that is both richer and more nuanced -- and closer to being "a true story."

Retrospectives are not just about making you feel bad for missing your commitments, pointing fingers at your colleagues, and hearing your talkative team members go on and on. They are supposed to help your team become great. This workshop is for anyone that participates in retrospectives, doesn’t always feel they are useful and wants to learn a better way to accomplish the intended goal.

We will explore several different topics to help revive retros such as:

• Understanding people's perspectives to retros
• The psychology of blame
• Looking for what is working in the team
• Problem solving strategies
• Getting the team's feelings out on the table
• Understand team perceptions
• Using data to determine the way forward
• Improving team interactions in a remote environment

In 2001, a group of software developers got together in Snowbird, UT, and created the Agile Manifesto. The Manifesto was a statement of core value and principles. The core values are:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

These four values are supplemented by 12 principles of agile software. The original 17 signatories were joined by thousands of additional people with the ability to sign cut off in 2016.

These principles are the foundation of much of the work in agile that has occurred in agile development, but have been mostly frozen as practices and agile has evolved.

Modern Agile has been created recently to update the underlying foundational values and to provide a focus beyond software delivery. Those four values are:

• Make People Awesome
• Deliver Value Continuously
• Make Safety a Prerequisite
• Experience and Learn Rapidly

This talk will walk through this reimagining of the agile values and what they mean for delivery within a government context. We will take each value and look at government cultural and technical challenges and opportunities to advance modern development practices.

Want to help your data and analytics teams embrace Agile but don’t know where to start? Wondering why your data team seems to struggle with creating manageable yet valuable stories? Curious why we think Agile for data teams is a distinct challenge?

Data work is often structured more like a pyramid than the familiar “layer cake” metaphor due to the state of data infrastructure technology, common industry practices, and the heavy lift to integrate data before it can be analyzed and visualized. Prevailing Agile wisdom of cutting work into “vertical slices” thus presents significant challenges for Agilists working on data teams! Typical full-stack vertical stories in this environment can easily become too complex, interdependent, and unwieldy to fit into fixed-length sprints. Technical stories can encapsulate smaller work increments but risk becoming too abstracted from the customer’s core problems and trap the team in infrastructure work for too long. An additional impediment to traditional user stories is the highly exploratory nature of advanced analytics and data science projects where in many cases end users lack awareness of what kind of problems can even be solved and technical experts can’t initially predict which solutions will actually be possible.

This session presents successes and lessons learned from applying alternative story decomposition and writing techniques on several data products across multiple teams. Returning to one of the fundamentals of what makes Agile valuable, namely to obtain feedback on feasibility and end user value as quickly and systematically as possible, our approaches strive to ensure teams have small, independent stories while still maintaining a value focus. We discuss ways to decouple the technical stack through stubbing and gradual tightening of the Definition of Done. This technique accommodates the necessary foundational work in the background while also obtaining early feedback about the value of the eventual product delivery options. A second approach incorporates Lean Startup concepts and centers on replacing traditional user stories with testable hypothesis statements that allow for explicit experimentation and risk trade-offs towards relevant milestones such as model quality, performance, predictive reliability, etc. in the context of extreme uncertainty.

Join us as we discuss some of the friction Agilists can encounter on data teams, as well as some validated ideas for meaningful solutions.

Agile at the team level fosters self-organization by leveraging constraints. Timeboxes, Work in Progress (WIP) Limits, and clear operational definitions are excellent examples of the kinds of constraints teams regularly employ to deliver reliably. Are you familiar and comfortable with these ideas, but uncertain how to apply them at larger scales? Are you looking for techniques that will allow you to harness the creativity of your teams to enable self-organization at scale? If so, this session is for you.

I’m passionate about applying concepts from Complex Systems Theory (as developed by Dave Snowden, Alicia Juarrero, Bob Artigiani, etc.) to the work of software teams. My colleagues and I at Excella have been exploiting these ideas by using a variety of patterns borrowed from different theories and frameworks to allow our teams to grow like healthy plants in a garden. From Large-Scale Scrum (LeSS) we leverage the concepts of a single product backlog and a shared cadence. Kanban principles of visualizing the work and limiting WIP help align the teams and foster greater collaboration. Dave Snowden’s emphasis on Homo Narrans—the human as storyteller—has provided a framework for clarifying and promulgating common values, which are essential for decentralized decision-making. Collectively, these mental models created an environment that helped us scale one of our engagements from three teams to eight over the course of a single year.

Not all programmers are comfortable with coding alone for 10 hours a day. Matt Kleiman spent years programming inefficiently in a cubicle. His Attention Deficit Disorder (ADD) and other learning disabilities deterred his success on traditional development teams. Seeking out an environment that would nourish his strengths, he found Pivotal Labs. Pivotal's Extreme Programming practices empowered Matt. Attend his talk to learn how pair programming and test-driven development transforms ADD into an asset in the workplace.

Does your Scrum team start all its stories on Day 1 of the Sprint? Do stories sometime carry over into the next Sprint? Or perhaps testing always gets crammed in on the last day of the Sprint? If any of these sound familiar, your team may benefit from improving its flow.

Flow metrics are common with Kanban, but can provide tremendous value to any team, including those using Scrum. In this session, we’ll start by exploring the value of achieving a smooth flow of work (versus simply achieving maximum utilization) and give simple ways for your team to measure its flow. We’ll look at examples of metrics including lead and cycle time, throughput, and the cumulative flow diagram (CFD), reviewing what each represents, easy ways to collect them, and how they can be used in both a Kanban and Scrum context. You’ll leave the session knowing how to interpret and capture all these valuable metrics, so your agile team can measure and improve its flow.

Have you ever been in a technical interview, stuck at a whiteboard or solving a brainteaser, and thought “there must be a better way”? Good news: there very much is.

Agility and adaptability are crucial for a development team's success, but how often do we target for agility when considering who to bring into our team? And how do we set expectations for agility from the first time this potential new hire begins evaluating our team?

In this talk, I walk through my philosophy & provide practical tips for running technical interviews that are primed for success.

Sure, we would like everyone to have an agile mindset and focus on continuous improvement, but sometimes as Agilists we need to work with stakeholders who don’t agree with our priorities or our methods. When you need to get something done in a bureaucracy, how do you adapt? Every place you operate has a unique combination of people, processes, and problems. We'll discuss general principles that will help you navigate successfully.

Over the last 5 years, Agile approaches have seen widespread adoption across the US Federal Government. Where real commitment is given to proven Agile frameworks and techniques, programs do see significant improvement in value delivery and speed. But unfortunately often, ‘Agile’ nomenclature is used while perpetuating behaviors that make real improvement impossible, and may actually make the lived experience worse for participants or stakeholders. And where Agile approaches fail, they add to a narrative that real methods won’t work in this environment. Many of the anti-patterns I’ve seen working as a Coach in the Public Sector are rooted in decision-makers clinging to 5 myths about Agile in Government. This talk will explore these 5 myths, where they come from, and some ways out of them.

It’s hard to overstate Benjamin Franklin’s contributions to the world. A true polymath, Franklin is best known for his statesmanship and diplomacy, his scientific insight, and his creation of the Scrum software development methodology.

Wait, what?

Okay, Franklin was ahead of his time, but he wasn’t telling us how to build software more than 200 years ago. Yet like the founders of Scrum, Franklin was obsessed with finding better ways to work and shared his productivity strategy in his autobiography. His to-do list is one of the first in the historical record, but the way he used it anticipates Scrum – and Agile principles in general – in many ways.

Attempting to deliver a project and maintain an agile mindset at the same time can feel fraught with peril. Unforeseen circumstances, the challenges of working in team of actual human beings, and organizational inertia act like riptide currents, pulling you away from your delivery, your team's commitment to agile principles, or both.

All is not lost! In this talk, I'll describe some symptoms of agile dysfunction and their antidotes. We'll explore some lessons I've learned as a technical lead working with agile and "agile" teams, holding it together with duct tape and a little help from my friends.

Several topics dominate the landscape of modern software delivery -- agile principles & practices, DevOps, Continuous Integration & Deployment, automated testing & test-driven development. Central to all of these is the idea of feedback loops.

In this talk, I will work through the essence of feedback loops, and the myriad ways that seeking & targeting smaller feedback loops can benefit your team & your organization in its pursuit of agility and excellence.

What can an experienced Scrum Master learn by going undercover, passing himself off as a software developer?

• Why developers complain about meetings!
• Why they always want to "pay off technical debt!"
• Whether TDD & Pair Programming are worth it!

For the last year, Dane has served as a Ruby developer on a Scrum team, while all of his prior experience on Agile teams was as a Scrum Master or Product Owner. Dane will share his experience and insights from life on both sides.

In a diverse company full of schedule-packed consultants and engineers, how do you continually find ways to engage employees and create a more inclusive environment? Khadijah and Lizzie knew they had the support of leadership – and the interest of the employees – so all they had to do was come up with a way to learn quickly, fail fast, and prototype.

Come hear how Lizzie and Khadijah, along with their fellow Blackstonians, applied Agile Principles to solve a decidedly non-IT challenge.

Psychological safety is one of the newest buzz terms in team dynamics but what does it really mean for an Agile team? No need to reinvent the wheel here - whether you’re using Scum or Kanban, they both have safety built in. You can find it hiding in plain sight - in Scrum values & Kanban principles.

Let’s learn how to use these concepts to develop trust in our teams and where to start.

Whether it be in non-profits, the government space, or even in commercial software development, we are often at the beck and call of powers outside of our control: a new election result, a tax-law coming into place, a competitor trying to get to market first. This causes us to have to abandon the best practices that we know we have to do in favor of meeting our client's expectations. "You don't need to write so many tests, just write non-buggy code! Why are you pair programming? More developers working on a single story is inefficient! We don't have time to refactor code, just make it work!" This is a story that we all know too well. In this talk, I'll speak about my experiences with two different entities under entirely different expectations. One is a non-profit that needed to update its ageing mainframe system, and the other a government agency that is tasked with a seemingly impossible goal that happens to coincide with an election cycle. In each scenario, we see the effect that this has on the quality of software. We'll also look into how the environment, people, and timelines impacted the approach of each team.