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.

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.

The many trivial testing and refactoring examples available on the web are difficult for developers to apply to real-world code bases. As a result, many "new to agile" developers don't attempt to apply tests or refactorings to legacy code, reserving these techniques for the ever elusive greenfield project.
To help developers with this dilemma, this session will walk through a real legacy Java code base, and go through the steps required to bring the code under test & begin to perform useful refactorings. All of this will be done under the guidance of the principles of Simple Design.

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.

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!

While many companies are adopting Agile development practices, it is fascinating how most of the management team in these companies are still starting trying to budget and plan in one year increments. Budget and planning starts in the fall and managers are literally guessing what they will need and what they are going to be working on 12 months down the road. It is inevitable that within the first few months of the plan there is going to a major event that is going make the plan completely irrelevant. It could be a new project that came out of nowhere, an issue with a major application that needs all hands to address, or the simple fact that as the team has completed work throughout the year, what was important at the beginning of the year is no longer important. 

In this talk we will share the experiences of the IT management team of a small financial services firm that took a conference room and Scrum and found a way to improve throughput, increase visibility, and improve coordination across IT, all while delivering projects, responding to auditors and growing the company's product portfolio. 

Have you been adopting Agile methods across several teams but wondering if there is a consistent way to measure their health and progress? What does it even mean to be a "healthy" Agile team? Take a deeper dive with our dynamic Agile Expert, Sally Elatta, as she walks you through the top 5 metrics you need to be looking at to measure the health and performance of your Agile teams and how you can create a continuous growth process where teams, programs and portfolios are getting better quarter after quarter.

Learning Objectives: 

• How do you really measure TeamHealth and what metrics should you look for?
• Why it's important to look at both Qualitative and Quantitative measures and not just focus on 'hard metrics'. 
• How to create a continuous quarterly growth process that is predictable and measurable.
• Go through a TeamHealth retrospective simulation!

This will be an engaging and hands on session where attendees get to color a blank TeamHealth radar using crayons and have a tangible output they can share with their teams. 

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.

Are you struggling with delivering a potentially releasable working product every iteration? Ever wonder what one of biggest reasons we have difficulty getting things done at the individual, team and organizational level are? Do you keep doing something even though you know it reduces your productivity and lowers quality? We are going to run an exercise that highlights one of the major culprits that you have all experienced and continue to experience. The exercise will likely ignite a fire that will help you, your team and your organization to become more productive and improve product quality. We will discuss ways to improve this at the individual, team and organization levels.

Knowing this will help anyone to understand the consequences of not prioritizing and increase their desire to. This will lead to producing faster, higher quality products that should lead to delighted customers.

“Agile doesn’t have a brain.” This quote from Bill Scott, ‎VP, Business Engineering and Product Development at PayPal, is provocative for sure, but it highlights the perception that in most organizations Agile is primarily applied as a downstream engineering approach. As such, it isn’t inherently concerned with optimizing product design and user experience, the biggest drivers of customer satisfaction. The feedback cycles that form the basis of Scrum provide verification and validation of stakeholder needs only as they are expressed in the backlog’s user stories. Even if a sufficiently empowered and accessible Product Owner is available, agile methods offer little guidance on how to translate organizational goals and customer needs into the backlog’s content and relative priorities in the first place. As a result, the danger persists that agile teams end up very efficiently building products that implement an incomplete and subjective perception of the wants and needs of both the organization and its customers.

In this session, we will explore how Lean thinking expands the “inspect and adapt” loops of agile development and helps systematically determine which features and design choices really provide the greatest organizational value. After a brief introduction to Lean concepts, we will discuss how Lean approaches product development as a series of hypotheses about customers’ behavior and value perception and builds on Agile’s rapid iterative delivery of working software to test these assumptions. Finally, we will examine ways to derive testable assumptions from organizational goals, such as the Lean UX Hypothesis Statement template and Gojko Adzic’s Impact Mapping.

There has been a lot of talk lately about Software Craftsmanship. Most of this talk has been centered around how to take existing, skilled programmers and turn them into Craftsmen. What about those who are just entering the field? In this talk, we will explore a new approach to fulfilling the entire journey from Apprentice to Master, both from a personal and organizational level. We will also look at how to get such a program started, and how to bring the existing team along.

We've all heard how we need to collaborate better, but what does this really mean?  What results can I expect to see with better collaboration?  

This workshop will demonstrate how productivity increases with greater collaboration and how to create better a more collaborative environment.  In the session you will not only have an opportunity to experience this relationship with a relatively simple learning game, but we'll look behind the curtain at the science and how some various behavioral models explain why this relationship exists.  We'll then explore some tactics you can use to help teams collaborate better and close with an exploration of what either helps or hinders collaboration and how you can use this information as well as the game with your teams.

If you have an interest in improving productivity of your team or the teams you serve, then this is the session for you.

Can a federal agency’s PMO support Agile teams that are focused on delivering working software frequently? What about all the needed documentation, reviews, and sign-offs from a myriad of groups including systems engineering, privacy, PRA and cyber security? In this session we’ll look at a federal agency’s PMO processes and the concept of minimum viable bureaucracy. We’ll explore the roles and relationship between the PMO, PM, Product Owner, ScrumMaster, and team. We’ll see how projects get initiated and the decision criteria needed to start or defer a project. We’ll walk through a lightweight gate review process and the activities and deliverables of each phase. We’ll also see how gate reviews can co-exists with a continuous delivery pipeline. We’ll share lessons learned and take a look at the challenges ahead. Come to this session to see how a lean PMO is operating in a Federal Agency.

Many Agile adoptions stall because they fail to align with what the business needs. It's not about just delivering work more quickly, but also ensuring that it is what the business needs; for the Government, this is mission needs alignment. Getting a fully automated DevOps pipeline does nothing if you don't have any idea what type of impact you plan to make on the business.  

However, once you have that delivery aligned with your business or mission, you can begin to perform experiments safely and more importantly measure the impact they make.  This session will discuss the types of measurements one can make and explore a few techniques you can use at both the macro and micro level to understand impact. We'll cite real-world examples set to help you understand how to apply each of the following techniques:

• Business Canvas
• Value Streams
• Personas and Customer Experience Journeys
• Impact Maps
• Experiments & Hypotheses via Validation Boards

This tour of techniques will give you ways to better craft your agility to your business needs.

So you want to transform your organization? How should you get started? Am I throwing everything away?

Understanding how to co-create your organization's aspirational characteristics creates a great start to your Agile journey.  This allows the people to internalize what agile means to them in their context; doing this will allow greater alignment and commitment during the transformation. We'll explore a technique that allows you to do this invented by some coaching colleagues (Michael Sahota and Olaf Lewitz) and that I've utilized in Federal and commercial clients.  

After performing this short exercise, we'll discuss next steps of selecting strategies using Appreciative Inquiry to help find and build upon your organization's strengths. Along the way, we'll learn a bit about what Appreciative Inquiry is and how it complements other change management approaches one can take. Don't throw out everything, build on your strengths!

I will share how I led a team from believing that end-to-end functional (browser) tests were "other" or "someone else's problem", to engaging the whole team in writing these kinds of tests.  By the end of the transition these tests were on almost equal footing as unit tests.

Along the way, I had to challenge conventional wisdom and dogma about unit tests - that unit tests are easier than functional tests, that unit tests are less brittle, or that unit tests are unconditionally useful.  

This talk is more about changing people's mindset than about specific tools, although I found that having the right tools made the mindset shift possible.

In the Agile community, we often talk of Servant Leadership, but this notion often doesn't resonate with leaders that have a history for more command and control based approaches. While Servant Leaders exhibit behaviors preferred for leading and supporting teams, the transition can be difficult to grasp. In order to help leaders understand and take action, I have merged the concepts of Servant Leader with a participatory style to become Facilitative Leadership.  This provides a means for better helping people understand more of what they can take action on.

This talk will help people understand how anyone can become a facilitative leader with a specific focus on people who need help in transitioning their thinking from typical command and control approaches to those that are more facilitative. So if you have been struggling how to serve your teams better, let's reframe how we think of approaching the actions we can take.