More and more organizations and teams are adopting Agile, however most stay focused on just the development part. They maintain a Big Upfront Requirements/Design (BRUF) phase and still have a long test and deployment phase. This approach results in more of a mini-waterfall approach rather than an Agile approach where we actually place valuable products in our customers’ hands. The old risks and pain points are still there: are we building the right thing? Is it valuable and usable? Does it work? So the true benefits of an Agile approach in terms of quality valuable products and higher ROI is never achieved due to our long cycles and slow feedback loops. Come to this session to see how Lean Discovery and Agile Delivery combined with a DevOps mindset, can make actual delivery of customer value sustainable. We will look at how Lean Discovery replaces BRUF and ensures the team is constantly building the right thing. We will also see how applying Agile Engineering practices ensure that the team is building the thing right and how a DevOps mindset ensures that the product the team builds actually gets delivered to the customer early and often.

FeatureBan is a simple and quick simulation that introduces several of the key concepts of Kanban, including visualization, feedback loops and limiting work in process and that lets participants learn by doing.  The simulation is also useful because it lets organizations who are curious about Kanban quickly learn about it before investing further.  Mike Burrows invented the simulation, but in this session we will present a modified version that we have used with both technical and non-technical audiences.

Situation A: Your team is great. You’ve met all your sprint goals and your Product Owner is pleased with the results to date. Yeah!

Situation B: Your team sucked. Zero story points completed last sprint. Team members are complaining and blaming each other for the failures.

These two situations demand two very different retrospectives. The right retrospective can make a good team great and turn a bad situation into a learning opportunity. A bad retrospective can set a team back and create a non-safe working environment.

In this session, attendees will explorer retrospectives techniques and examine the pros and cons of the techniques. The workshop will then explore scenarios and examine how to effectively run retrospectives across a variety of scenarios.

Coming out of this sessions, attendees will have an understanding of applying the right retrospectives based on the state and needs of the team and projects.

Ever solve a jigsaw puzzle?  Do you typically design and document all your pieces before assembling the puzzle or know anything about the kind of picture formed by the puzzle?  Hardly.  Usually, the specifics of the puzzle, as they emerge through the process of solving that puzzle, affect our tactics for solving it.  

This analogy is at the heart of Exploratory Testing (ET) - a fun, focused and powerful approach to testing that has been gaining in popularity in recent years.  While not a new idea, it is often misconstrued as being a random, flailing at the keyboard approach to uncovering problems.  Not quite.  ET is a disciplined practice that involves simultaneously learning about the software under test while designing and executing tests, using feedback from the last test to design the next.  It leverages traditional test design analysis techniques and heuristics, but design and execution become a single inseparable activity.  Within the agile context, there is a need for agile teams to augment their scripted automated tests with a manual testing practice that is adaptable, and ET provides the right fit.

In this session oriented towards beginning explorers, we will gain a deeper understanding of what ET is, what it isn't, and discuss the essential elements of the practice with practical tips and techniques for: learning the system under test and capturing our understanding to design tests; designing tests on the fly using heuristics; executing tests and observing results; and finally, integrating ET into the cadence of an agile process.

Gerry Weinberg once said of consulting “There is always a problem, and it’s always a people problem.” The world of DevOps is emerging rapidly, and just like the early days of Agile, is still working on refining exactly what DevOps means.  So often, the focus is either on the technical aspects of the various tool, or on the people problem of “bringing Ops into the room”.  But what is the problem that DevOps addresses, and is that problem more of a technical problem, or a people problem?  We will explore this, and look at the possible intersection between the two “problems” and how a DevOps approach can help overcome them.

Do you want to be able to “trust the wisdom of the group” but find it difficult? Do you ever feel like you’re having the same conversation over and over again with no real progress? Do you ever feel like you are stuck in a disagreement and not sure how to move forward?

If any of these issues are standing in the way of your work with groups and teams ‐ ‘how’ you are having (or not having) the conversation is likely contributing to your challenges. Research consistently demonstrates that team effectiveness is highly dependent upon the quality of the communication between team members. Yet it’s easy to get into the flow of daily work and be really focused on the ‘what’ in our conversations without much attention to the quality of ‘how’ we’re communicating.

As an agile coach one of the most important ways you can serve your team is to help them unlock the wisdom that exists within the team itself and have the conversations they need to have. We’ll explore a framework for learning to ‘read the room’ using four elements for all face-to-face communication. We’ll do some live practice to apply the framework to a conversation and then identify some typical patterns of “stuck” communications that can lead to “breakdowns” in teams.

This will be an interactive session with people actively engaged in both large group and small group discussions.

What do the commercial world and Federal government share in common? Agile success! Yes, it is true that agile grew from the commercial world and has been a shining story of success there, but the Federal government has been adopting agile’s brilliant ways more recently and has success stories of its own to share.

In getting to the point of successful agile delivery, especially at the organizational level, the Federal government has had to clear many hurdles and transform the way it works. This hasn’t been an easy task and is still in its infancy. The commercial world has cleared its share as well and has many war stories along with their success stories.

This session will be delivered as a moderated panel discussion. Two panelists from progressive Federal programs join two shining examples of agility from the commercial space – and entertaining fellows to boot.  Panelists will discuss topics that provide insight into their organizations and the work they did to implement agile successfully on their teams, across their programs, and throughout their organizations.

• Alastair Thomson is the Chief Information Officer for NIH’s National Heart, Lung, and Blood Institute
• Joshua Seckel is the Applied Technology Division Chief at the USCIS Office of Information Technology
• Nate McMahon is a Vice President of People and Technology at The Motley Fool
• Bob Payne is the Vice President of Enterprise Agile Consulting at LitheSpeed

Ever wonder if a major Federal program has been able to achieve Continuous Delivery or implement a Zero Defects strategy? How have the commercial companies been able to increase their output so well while decreasing risk at the same time? What can Federal organizations learn from the commercial world about agile contracting and procurements? How did commercial companies have to change to enable self-forming teams and could our Federal government, with its myriad contractors and its layers of separation, benefit from the same? What can the commercial world learn from Federal agile success? Do successful agile approaches differ between products and services? What do the Feds see as their next agile conquest on the horizon? What is hot for commercial companies to tackle now?

You will leave this session understanding some of what the commercial world has done to achieve great success with agile. You will also hear about agile success in the Federal government, bureaucracy busting moves, and what the government had to do in order to achieve those feats. Both sides will share their stories, describing the impediments they faced, the benefits they have seen, and even the areas they have not been able to conquer just yet, attempting to drive agile throughout their organizations and into every aspect of their delivery. Panelists will also discuss topics and answer questions the session participants have for them to ensure everyone has an opportunity to take back valuable and pertinent knowledge afforded by these experienced agilists.

When design is based on random choices, the end product is an assembly of random elements that have little or nothing in common. But when design forces all elements to work together then it makes a single, powerful, and meaningful impression to the user. While agile can get the job done faster, it doesn’t help guide design choices for a software product.    

This session presents a design driven approach called Strong Center Design that incorporates design into an agile workflow.

If you have an interest in improving design of your software products, then this is the session for you.

The Zombie Retrospective - presented by Tommie Adams 

So they say the retrospective is one of the strongest and most powerful tools in the agile scrum methodology tool kit, and is often overlooked or skipped. So how does a scrum master find ways to creatively explain and express the importance of this agile scrum ceremony, or even the basics of agile scrum in general. How does the scrum master explain the importance of banding together as a team in this brave new agile scrum world.  In many organizations, nowadays, the teams are even made up of outside vendors as well as in house associates. So how do you even start to pique the interest and the importance of team collaboration to a bunch of folks who are strangers to one another on a agile scrum team?  Even more specifically, how do you explain how the retrospective ceremony will help improve the way they work with one another over time?

My answer: ZOMBIES!!!  Everyone loves zombies, right?  So come, take a bite!

Tommie works for Marriott International in Bethesda MD. His background is in theater and communication which he studied at Grinnell College in Iowa. He has worked for Marriott International for 26 years with jobs ranging from reservation sales associate, to group sales manager, to functional IT tester to his current position as scrum master for the Marriott Rewards Agile Scrum Team. A native of Omaha, Nebraska, his hobbies include photography, cello and learning the ukulele, (you know, in case you were curious.) 

Why does the Agile community encourage cross-functional teams?  So many large organizations have naturally organized into system-specific teams.  This is a very common and logical approach.  At scale, though, it creates serious impediments to organizational agility and getting things done.  We'll discuss the roots of that phenomenon, one of our key interests in cross-functional teams, patterns for enabling such a team structure, some failure modes, and how to prevent them.  Please join us!

Delivery teams know from experience the importance of maintenance such as applying patches, upgrading, and conforming to the latest security and accessibility regulations. Product Owners, other value team members, and system stakeholders are focused on functionality and end user satisfaction. Maintenance isn’t sexy and can sink in priority until it fails to be included in releases.

The Security community has been using Dark/Abuser/Evil Stories using the persona of a Black Hat Hacker to uncover vulnerabilities. In this workshop participants will assume the role of Delivery Team members and use the power of personas to write “Dark Stories” that bring to life the full impact of failing to perform necessary maintenance.  The intent is to give Product Owners a complete understanding of the importance of maintenance so they can appropriately prioritize maintenance and keep their systems strong.

Teal is a natural extension of the Agile mindset, but who would have thought flattening the hierarchy could be this difficult! If Agile removes impediments and empowers teams to deliver more frequently and more valuable offerings, teal removes organizational impediments (hierarchy built on lack of trust ) and fosters empowerment by localizing decision making, re-centering activities around an evolutionary purpose, and aligning the personal with the organizational (wholeness). But what actually happens when you put rubber to road and empower teams to recruit, hire, fire, and determine each other’s bonuses? Well, things get a little messy. If you’re patient, set aside short-term outcomes, and look to long-term gain, it can prove deeply rewarding. I’ll take you on our own evolutionary journey from green to teal and share with you lessons learned along the way.

If you’re curious about alternative management styles or interested in the next extension of Agile, then come sit, chat, and reflect.

"Language does not just describe reality. Language creates the reality it describes." - Desmond Tutu

The agile community has evolved into a group of highly enthusiastic proponents who bring a high level of excitement to everything they say and do. Agilists speak a strange sort of insider jargon in which plain English words have very unusual, and often counterintuitive meanings.

They may describe your multi-billion-dollar enterprise as "dysfunctional" and on the verge of "failure." They may suggest your teams "sprint" to get work done, and yet do so at a "sustainable pace." They may tell your management that agile helps teams "go faster" while assuring your teams that agile isn't about "going faster." They may insist that agile is more about culture and mindset than about practices, and then measure your progress in terms of how faithfully you follow a prescribed set of practices.

There are many more examples of this odd insider jargon, starting with the seminal buzzword itself, "agile." Over the years, the way agilists speak has confused and turned off many who might otherwise have benefited from applying agile values and principles. The presenter will share several stories of the unintended effects of agile-speak, and will invite you to share your own tales of woe and amusement.

When we have our most successful coaching moments, they often come from a deep groove: where we seem to anticipate the team's needs; know when the breakthroughs are coming; know how to dance between mentoring the team and letting them innovate (or struggle) on their own. But, it rarely starts that way. Coaching new teams can be awkward -- and especially so if you're new to coaching. I will show you some ways of approaching these coaching engagements that can break down the awkwardness, reveal things about the team, and get on a track of improvement and discovery.

I will share some attitudes I think can benefit coaches who find these situations awkward, as well as practical tools and tips you can exercise tomorrow to get teams talking and making progress. We will also engage as small groups, for further practice on these tools and to create space for coaching one-another.

We've all see Project Charters.  Project Charters usually state the vision, mission, roadmaps, and is hand top down to the teams.  However, how many of us have Team Charters in place.  Team Charters are one of the most powerful tools a team has when it comes to being able to work effectively together.

This workshop explores the dynamics of creating a team charter, the definition of ready, and the definition of done and how all this works together to create software that is ready for review, to potentially shippable, to released into production.

Sprint Planning is a frequent, important part of the rhythm of many agile teams. And yet, we find that many coaches and Scrum Masters struggle to make the meeting relevant, valuable, and creative. We will work through a simple, relatable simulation that we use to teach effective planning to teams and facilitators that brings energy, creativity, and problem-solving to the Sprint Planning experience. 

Agile works best when the entire team is sitting together in the same office. Or does it?

The reality of today's working world is that more and more teams have people working remotely. As agile practitioners, we must "inspect and adapt" to this new world. What strategies should we use to make agile work better in a distributed world? How important is picking the right tools vs. setting a positive culture? What practices should team leaders and Scrum Masters of distributed teams implement to make distributed life easier and more effective?

presented by David Horowitz

David is a co-founder and CEO of Retrium. Retrium makes distributed retrospectives easy and effective through the use of a real-time facilitated web app that enables private ideation, dot voting, prioritized discussion, and the creation of action plans. In a prior life, David was a software developer for The World Bank for 9 years.

A build pipeline is such an important aspect of a software project.  It saves a ton of manual, error-prone depoyment work, as well as results in higher quality software that can be released more frequently.    

However, I have been on multiple projects where one of the steps in the continuous integration process was failing (red), often for multiple days or even perpetually.  So much of the benefit a build pipeline provides is lost when this is allowed to happen.  Bugs are not caught by automated tests; additional tests break without being fixed because no one notices; the culture of keeping a green pipeline diminishes and faith in everything from the pipeline itself to automated tests reduces.  Developers learn bad habits.   

Building the pipeline and getting all steps working (keeping it green!) is no small feat in the first place, and keeping it that way can also be a large undertaking. One way I have tried to combat this is to institute some specific process for the Scrum team, pertaining to monitoring and maintaining the build pipeline.  There is also an aspect of convincing the team and management that it is worth spending the time, and dropping everything to maintain a fully functional pipeline.  

Join me for a common sense, tactile approach to keep a build pipeline green that has worked on small and larger projects with multiple teams.  

Learn what coaching is and how it can be used at coaching agile teams and agile enterprises.