You've sent the managers to Scrum Master training. The development team is getting pretty good at writing automated tests and have most of the release process automated. Your CIO is recognizing that Quality Assurance, Security, and Independent Testing is going to need to change to take advantage. But something isn't right. Specifically, you're still not producing products that delight customers. Or, you are producing products that delight customers, but they can't see the light of day because of other stakeholders.

The dirty secret in Agile Transformation is that for all the talk about how the IT organization needs to change to engage with customers and produce working software, what gets less talked about is how comfortable the customers, or the proverbial "Business", has gotten with the status quo before Agile.

In this talk, we explore who are the stakeholders that comprise "the Business", what barriers they often face in adapting to Agile, as well as some practices that can help you ensure that they have seat on the Agile Transformation train.

"You can't do agile until you have the technical practices down"

"Just start with Scrum, everything else will follow"

"We have to change the mindset here first!"

Do any of these sound familiar? Where does an agile transformation need to begin? In this workshop, participants will play "Wheel of Agile Transformation" where they will spin a wheel and develop their own story on how an agile transformation within their organization is rooted in focusing on either technical practices, process, culture, or other areas! 

Empowerment. All of the agile literature focuses on it being a key characteristic of a successful Product Owner. Necessary to ensure decisions can be made quickly and representative of business value. Yet in most environments, particularly in the public sector, the notion of a single Product Owner empowered to represent the multitude of stakeholders isn't feasible. In this session, if you have a situation where you are a Product Owner, or know a Product Owner, who is not in that ideal textbook situation (and even those who are), learn how we can harness the power of classic and emerging innovation methods to put you in a position of success.

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.