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.

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

There are many levels of estimation, including budgeting, high-level estimation and task planning (detailed estimation).  We can link a more classic view of estimation to  the Agile planning onion popularized by Mike Cohn.   In the Agile planning onion, strategic planning is on the outside of the onion and the planning that occurs in the daily sprint meetings is at the core of the onion. Each layer closer to the core relates more to the day-to-day activity of a team. The #NoEstimates movement eschew developing story- or task-level estimates and sometimes higher levels of estimation. As you get closer to the core of the planning onion the case for the#NoEstimates becomes more compelling and dare I say useful. 

This presentation focuses on challenging the attendee to consider estimation as a form of planning. Planning is a considered an important competency in most business environments. Planning activities abound whether planning the corporate picnic to planning the acquisition and implementation of a new customer relationship management system. Most planning activities center on answering a few very basic questions. When will “it” be done? How much will “it” cost? What is “it” that I will actually get? As an organization or team progresses through the planning onion, the need for effort and cost estimation lessens in most cases. #NoEstimation does not remove the need for all types of estimates. Most organizations will always need to estimate in order to budget. Organizations that have stable teams, adopt the Agile mindset and have a well-groomed backlog will be able to use predictable flow to forecast rather than effort and cost estimation. At a sprint or day-to-day level Agile teams that predictably deliver value can embrace the idea of #NoEstimate while answering the basic questions based what, when and how much based on performance.

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.

“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.

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.

“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.

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.

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.

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.