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.

You probably started your Agile journey with Scrum, which helped. But regression testing still takes forever. New feature tests aren't what they could be and are hard to complete within the Sprint.

If you have active product owners, the POs helped to improve your product, but there is still a disconnect, between the user story and the tests.  And how do you test "as a, I want, so that"?

Now you hear you need Agile technical practices to keep improving and you find you need to automate. What are you going to do with your testers?  They really, really know your business, but they don't code.

If you are a manager, a tester or a product owner, come hear Camille as she shares her experience successfully teaching manual testers Automated Test Driven Development and showing product owners how to write great Acceptance Criteria that are easy to automate.

In this session you will learn:

• How to get your product owners, testers and developers to understand each other
• How to make your business scenarios unambiguous and testable
• How to avoid brittle tests that need frequent rewriting
• Which tools and languages are better for testers to learn and why
• Strategies and techniques for testers to learn test automation
• Where to find inexpensive and free resources to get started

How many times have you heard someone say that scope is fixed and then throw a tantrum when they hear how long it will take to build?  How many times have you seen the spirited creativity of development teams evaporate when a stakeholder tells them the deliverable cannot be changed at all?  And how many times have you discussed agility with naysayers who say, "That's all fine in an ideal world when you are building some hip little application, but we're in the real world with real projects with fixed scope."

This presentation explores the myth of fixed scope, how damaging the notion is, and the tool we all have at our disposal for escaping the trap.  Come explore how natural it is to use it, and yet how vigilant we need to be to keep ourselves from casting it aside.

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.

“More and more organizations are realizing the benefits of running projects using Scrum, XP, and/or Kanban at the individual team level. Unfortunately, the typically means that in a 12-24 business idea to production time-frame, the “Agile” part may only be a 1-3 month “construction” phase with rigid controls in place that all but eliminate most of the benefit of Agile.  The root cause of this issue is that the whole organization is purpose-built to support and reinforce traditional methodologies while unintentionally impeding and discouraging the use of Agile methodologies. This is reflected in the organizational structure, physical location of people, the physical workplace, policies, procedures, governance, SDLC, contracts, vendors, belief systems, compensation, software tools, funding model, metrics, and more. A common belief is that all of these are set in stone and that Agile will need to fit in to this existing framework. As a result, many Agile adoptions eventually regress as the effort of working around the existing framework overwhelms the enthusiasm of the Agile evangelists. Unlocking the full power of Agile requires an understanding that changing the status quo is a long-term, organization-wide, major initiative that will take significant resources to accomplish. Such an initiative will only be undertaken if the rewards are significantly greater than the cost. In this session, you will learn about the true barriers to Agile adoption; the surprising and significant financial benefits of organization-wide Agile transformation; and the Kotter Change Model, an approach for implementing major change management efforts.”

The Tadpole Technique is an approach that teams can use to break a larger idea into smaller pieces in an interactive and visual way.  This facilitated session is a way to get team members to participate in some chatter as well as as generate a few takeaways from the session.  This technique is useful in meetings where a group of approximately ten individuals and a facilitator go through a series of discussions following a brief writing activity.  The result is a visual representation of the teams thoughts and discussion, and can be used to further expand later talks or to create some takeaways.

This talk will explain the mechanics of this technique, what teams will need, and explain how to facilitate the session.  Participants will then engage in an exercise where they get to experience the technique as a group, enhancing their ability to facilitate future sessions of their own. 

Your Agile Stand-up Meeting Sucks!

Most Agile and Scrum stand-up meetings I see are boring, lifeless, status meetings that don't provide any real value.

In this session you'll learn:

The REAL purpose of the daily stand-up

The most common bad habits and how to correct them

The habits good stand-up meetings have

How you can use Improv to invigorate your daily stand-up

A whole bunch of Improv exercises you can start using with your team right now!

Often when organizations go through an Agile transformation, there are some concepts that are challenging to address or adopt. We have a tendency to avoid the ‘crucial conversation’ so as not to hinder progress. Eventually these fundamentals can get overlooked or "put on the back burner". At this point transformations stall, and we find that our process is operating more like a 2 week waterfall than an Product-Increment-Producing-Machine-of-Wonder. I believe this behavior is one of the drivers for the ‘scrum-but’ concept.

This session will delve into anti-patterns, bad smells, and other pitfalls which are keeping organizations from reaching the next level of Agile adoption. We’ll examine common warning signs and identify strong signals that indicate that a sprint time box is not being optimized. Once we’ve identified the challenges, we’ll explore best-practices, tweaks, and courageous actions to get teams collaborating in a first-class manner. 

In short:  Step 1: Understand what is hindering our Scrum practice. Step 2: Surface actionable remedies that we can apply tomorrow.

As we see Agile evolving through the years, particularly into the government space, a lot of terminology is used that seems foreign to many who first used agile with their individual teams.  "Hybrid Scrum"..."Delegate Product Owner"...even "Scaled Agile".  Are these simply extensions of the agile values and principles in the manifesto to fit a different and more complex environment, or do they represent a diluting of those same values and principles?  Explore in a facilitated workshop with your peers whether such terms are appropriate (maybe even necessary) to adopt agile in the complicated enterprise, or whether they represent (oxy)moronic agile and a step backward.

Gain insights and learn real-world strategies and techniques for leading an enterprise or divisional Agile transformation.  Based on current experiences driving Fannie Mae's enterprise Agile transformation, and drawing upon years of experience leading Agile transformations in multiple divisions at Capital One, Mr. Richardson will share proven methods and approaches for leading a successful Agile transformation.  This session is aimed at senior leaders, executives, and management. 

Via a dynamic presentation and lively participant dialog, we will cover in depth topics such as:

• Assessing your organization's strengths and opportunities re: Agile adoption at all levels in the organization
• Key elements of a successful Agile transformation plan & execution of that plan
• Engagement strategies for teams, middle management, and executive leadership
• Techniques for lighting a fire with Agile enterprise-wide
• The appropriate roles of delivery leaders, Circles of Excellence, User Groups, PMOs, etc.
• Maintaining Agile discipline in the face of organizational friction
• Dealing effectively with many varieties of change resistance specific to Agile transformations

Additionally, we will cover advanced enterprise topics such as:

• Enterprise investment management and new techniques for an increasingly Agile portfolio
• Refinements to Procurement approaches to enable Agile
• Structural elements in large organizations that must be addressed for an Agile transformation to have staying power

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.

“Running a football team is no different than running any other kind of organization…” -- Vince Lombardi

Large enterprise scale software development is a team sport. In order to win in this game your software needs to be of the highest quality, which is almost impossible to achieve with testers on the sidelines. To build a winning a team you need the right players, but great teams don't always need the best players. Great teams win because they find ways to let the individuals on their team be great. 

The wave of DevOps in the industry is in a broader sense an effort to let developers and system engineers do what they do best by eliminating or simplifying tasks that forced individuals into activities beyond their expertise. Pre-DevOps roles were like trying to ask Payton Manning to play both quarterback and running back at the same time. DevOps is the manifestation of empathy between two distinct sets of skills allowing the other to focus on what their best at. What about testers? How can the team expand their empathy to their role? What can the developers, program managers, and others do to let testers be great? Please join me if your curious to hear about the practices, tools, and culture that can make your software a winner with quality.

Most scrum teams create effort estimates, often using story points. As a product owner, you also want to have an estimate of the business value of each user story. Business value estimates help you create a more rational backlog and maximize the value the team delivers.

This workshop explores the art and science of estimating the business value of user stories. Participants will gain an understanding of the essence of business value,
and why it is more complex than just revenue or profit. Then we will then learn a surprisingly simple technique to estimate and quantify business value.

All Not for Profits aspire to be effective, nimble, and fun all while changing the world. Agile mindsets and practices can help all nonprofit organizations use technology agile concepts skillfully and confidently to meet community needs and fulfill their missions.

Successfully implementing and fully adopting agile can be seen as unnecessary overhead.  Creating an Agile community and toolbox for Not for Profits would greatly reduce the organization change costs and allow not for profits to benefit faster.  This community would facilitate the exchange of knowledge and information within the agile community and within the Not for Profit sector. It would connect members to each other, provide professional development opportunities, educate our constituency on issues of technology use in nonprofits, and spearhead groundbreaking research, advocacy, and education on technology issues affecting our entire community.

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.

This unique journey will transport you deep inside the world of the General Services Administration (GSA) Integrated Award Environment (IAE).  You will see how user-centered Agile is transforming the way software applications are engineered, how users' voices have been integrated with large-scale Agile development, and what issues we encountered along the way.

When Eric Schmidt, former CEO of Google, predicted, "Everything in the future online is going to look like a multiplayer game," perhaps he was envisioning a user community such as ours.  The IAE family of software applications have more than a million users representing federal, state, local, and tribal government organizations; congressional staff; large and small businesses; universities, schools, and hospitals; non-profit organizations; foreign entities; private citizens and others.  Our greatest challenge is the diversity of our user base, resembling a massive multiplayer game in many ways. 

This case study looks inside a major reengineering effort to migrate 10 legacy applications into an integrated environment while at the same time transitioning from Waterfall to Agile development.  It tells the story of how IAE users have shaped our transformation thus far.  

Like in Horseshoes and Hand Grenades, being close in Agile has great value.  We need not abandon our brethren in the trenches just because some of the most recognizable practices are out of play.  The great principles of Agile help in even the most difficult environments.  Shipping great software while under some traditional constraints is a true test of the movement – and we have a track record of doing just that.  We have employed Stealth Agile, Green Box Agile, Cafeteria Agile, Agile Pathfinding, and even Agile Treason in order to deliver in less than ideal circumstances.

A series of actual scenarios will reveal the adaptations to Agile practices that kept us close to principles.  A small set of practices are present in so many of our projects that we consider them to be part of our Agile core.  Sometimes we rename them, sometimes we feather them, sometimes we disguise them, but they are always present and are pivotal to success.  Chief among these are the various practices that enable and encourage rapid feedback at multiple levels including Customer, Product, System, and Development.

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.