Despite thinking that organizations are slow to innovate, innovation actually abounds at many companies. Kodak, DEC, and Xerox did not fail due to lack of new, cutting-edge innovation; they failed because their organizations were tuned to their traditional markets, and a failure to change their business models and organizations led to their eventual disruption.

The key to achieving business agility lies in leadership that transforms organizations. Transformational leaders succeed by changing the system, leading with purpose, and steering from the edges. They own their responsibility and boldly lead their organizations into the future. As leaders, we can accelerate this evolution by enabling true self-management and team-based governance.

Join Bob and Sanjiv to learn how leaders can transform organizations with a flatter organization structure, work anywhere flexibility, participatory profit sharing, and delegated hiring and firing. Explore the agile leadership journey needed for true business agility.

In 2001, a group of software developers got together in Snowbird, UT, and created the Agile Manifesto. The Manifesto was a statement of core value and principles. The core values are:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

These four values are supplemented by 12 principles of agile software. The original 17 signatories were joined by thousands of additional people with the ability to sign cut off in 2016.

These principles are the foundation of much of the work in agile that has occurred in agile development, but have been mostly frozen as practices and agile has evolved.

Modern Agile has been created recently to update the underlying foundational values and to provide a focus beyond software delivery. Those four values are:

• Make People Awesome
• Deliver Value Continuously
• Make Safety a Prerequisite
• Experience and Learn Rapidly

This talk will walk through this reimagining of the agile values and what they mean for delivery within a government context. We will take each value and look at government cultural and technical challenges and opportunities to advance modern development practices.

The best way to learn Scrum is by doing, but it can be difficult to simulate Scrum and see how well Scrum helps team overcome technical hurdles without actually building something technically challenging. Lego's have always been a fun option for introducing Scrum, but it's difficult to recreate technical impediments, the need for spikes and managing technical debt with our tried and true friend, the box of Lego's.

Arguably, a better alternative might be Snap Circuits, a toy designed to introduce children to electronics in a fun and easy-to-understand format. Like Lego's, adults gravitate toward Snap Circuits because they are colorful, quickly understood and snap together with ease.

But, Snap Circuits have the added advantage of requiring a small amount of technical learning during the simulation that make it a closer match to the technical obstacles faced by a typical Scrum team.

In this workshop, you'll learn one "Scrum in a Snap" simulation exercise. In addition, we'll provide you with a few other "Scrum in a Snap" ideas and encourage you to experiment on your own. Four lucky attendees will also win their own Snap Circuits kit so they can develop their own Scrum games.

Past participants in "Scrum in a Snap" have said "The best Scrum exercise I've ever done", "I can't believe how much it's like coding - without actually coding", "What a blast - I'll never forget this activity!" and "Where can I buy one?"

Attend this workshop to see why.

How do you promote mastery of practice areas? Danial H. Pink tells us people are motivated by autonomy, mastery and purpose. Small Agile teams promote autonomy while value streams and corporate missions promote purpose. Communities of Practice can be a great way to promote mastery, if formed correctly.

Communities of Practice are more important today then they’ve ever been before. We’ve learned cross-functional teams are the best way to produce customer focused products but as we put people into value streams and product teams, are we creating silos where practice domains don’t communicate as often and knowledge gaps are widening? There’s a reason why most Agile Frameworks recommend forming Communities of Practice.

In this workshop we’ll talk about forming masterful communities and you’ll create a handy pocket guide to take with you.

Come learn how to form Masterful Communities of Practice and lead your organization going forward.

As agile practitioners, we are well aware that we need to delegate decision-making and responsibility to members of the team, but it's often easier in principle than it is in practice. Frequently, delegating triggers some angst in most of us, usually revolving around our biggest fear: "What if they fail miserably?"

Fortunately, there are better questions to ask before we delegate, including:

• How can I determine whether the person is capable of handling the responsibility delegated?
• If they're not ready, how do I help them to acquire that ability?

In this combination tutorial and workshop, we'll answer both these questions so you can be more successful when you delegate. We'll also give you an opportunity to apply your newly acquired knowledge via in-class simulation and provide information to help you coach others in effective delegation.

Retrospectives are a key component in assisting you teams to improve. Most Jedi, er, Scrum Masters know how to facilitate a retrospective. However, many do not consider how to SELECT a retrospective based on the needs of their teams. Different types of retrospectives will be considered, such as the 6 Thinking Hats, Appreciation, Sailboat, and in addition, two Custom retrospectives. Have you considered which retrospectives you would facilitate for your team based upon their needs? For example, if you are with a new team, what would retrospective would you select? If your team seems to have trouble working together or communicating, which retro? How could you customize a retrospective to address the needs of your team?

Scrum relies heavily on Velocity for planning and performance improvements. Let's talk about what it really means, some anti-patterns and good practices.

One of the more abstract concepts in Agile is how to use Story Points and Velocity. It seems pretty straightforward in concept--assign each work unit (story) relative points; at the end of the sprint count up how many points you completed and plan that number for next sprint. But in practice...

Do points represent days? Complexity? What if something is easy to develop but hard to test? Maybe a task is UI heavy or back-end heavy? Should all teams in an organization use the same scale? What happens when the team composition changes?

One of the most common challenges is how velocity is viewed outside the Scrum team. Why is Team A's velocity 70 while Team B's is 90? How can we increase velocity to 90? Of course the team can and will fix that just by changes the SPs assigned to each task--that three-point story is now magically worth five; how did that happen?

Points and Velocity are just tools. Learn some ways to not let them take over.