If you are one of the people in your organization that is helping to increase the Agility of people, teams, or the organization overall, then you are a cultural change agent. According to Merriam-Webster’s, culture is “the set of shared attitudes, values, goals, and practices that characterizes an institution or organization” and “a way of thinking behaving, or working that exists in a place or organization.” Agile brings a new set of attitudes, values, goals, beliefs, and practices; and a new way of thinking, behaving, and working.

In this highly interactive session, we will examine the kinds of cultural and behavioral changes that Agile can bring, the benefits of those changes, and the practices and techniques that can ease the inevitable culture clash. Participants will split up into small cross-functional groups which will go through a series of exercises to discover their current level of "Agile culture", the many sub-cultures in an organization and their unique challenges, behavioral changes that lead to cultural change, and the opportunities that we all have to personally affect our organization's culture.

One of the highlights of the workshop is a thought experiment called "the locked room" which gives participants an opportunity to see their organization's culture in a new light, imagine a more Agile culture, and consider the changes required to move to that more Agile culture.

In large Government and Commercial organizations with many interacting systems, architecture is necessary to collaborate effectively across disparate entities and systems. Traditional command and control approaches to architecture are often ineffective and cause great tension, especially when Agile efforts are part of the portfolio. We will discuss two principles, Vision and Partnering.  These principles provide insight and get results for both architects and Agilists; and present tools and approaches on how to effectively engage architects and architecture.

For a team new to Agile practices, writing clear, concise requirements and acceptance criteria can be daunting. Add to that the additional challenge of automatically testing those criteria. Does your team struggle to manage bugs? As a business analyst or product owner, do you find yourself clarifying user stories and acceptance criteria for the team?

Working software is only as good as the requirements are at identifying the end customer’s needs and having code that executes against those requirements.

This talk will be a case study of the challenges faced by a team new to Agile writing testable requirements and how we overcame them. Attendees will leave with strategies to improve their requirements and acceptance criteria for automated testing.

Agilists employ user stories as a way to capture user requirements and drive the planning process for iterative and incremental delivery of software. Traditionalists with experience in “big requirements up front” often struggle with the brevity of user stories and how to best communicate requirements. In this presentation, Fadi explains the benefits of using user stories to represent customer requirements. After explaining the basic concepts, he quickly progresses to discuss attributes of a good user story along with different techniques for user role modeling. Fadi shows you how to manage risk and dependencies by properly sizing user stories. Learn what size is the right size and how to deal with constraints, assumptions, and non-functional requirements. Understand the different criteria used to decide when to split or merge stories. Discover different boundaries for prioritizing stories. Leave with new insights on how to write effective user stories.

Most software professionals have read and internalized the Gang of Four Book on Design Patterns.  Every team and it's individual members have experienced the cycle of team development described through the Tuckman Model.  This session combines those two concepts by describing typical patterns of behavior during the team development phases of forming, storming, norming and performing.  Moreover, we will describe techniques to help teams overcome the pains of forming and storming and techniques to thrive while norming and performing.

Ever feel like your team is fighting an uphill battle when it comes to working with support teams, like Dev Ops or Procurement, to complete a project? Has your team ever wanted to just go buy servers for themselves just so it gets done while they are waiting on server delivery from a supporting team? Well, you are not alone!!

When it comes to working within government agencies, as well as other private organizations, this is the way most Agile teams end up working. It is all about the project team moving toward being Agile while other teams are not. What does that mean for your project and team? Will things get done? Are there other options? 

This session will take a look at how it feels to work with non-Agile support teams, focusing on working with government agencies, when your team is trying to be Agile.  We will dive into a world of “what-ifs” and “how tos” that will get you thinking about alternative ways to work within the boundaries of what you can control and how to migrate through the things you can’t.