This case study describes an actual roll-out of an Agile Transformation across 7 product lines, and 18 scrum teams in a local commercial organization. It maps out 4 levels of industry best practices, and describes what techniques worked, why some techniques failed when they were introduced, and what other techniques had to be mastered before they could be re-introduced.

We will also talk about assessment models, and give examples on how to design good metrics for each level of performance. At Level 1 we have 6 core metrics that all teams must report. When the teams start Level 2 we ask them to design their own metrics, based on their products’ business models, to show how they impact income, overhead, strategy, and risk. When teams reach level 3 they are ready to start advising executives on corporate strategy, with a track record of proven performance.

To motivate teams we’ve mixed in several elements of gamification (rather accidentally, to be honest), that inspire teams to complete their assessments, “level up”, and engage in healthy competition. But it’s also not a winner-take-all culture. We leave room for multiple teams to receive rewards and appreciation for their unique achievements across 5 different performance categories.

The design of this Agile Transformation program is based on the principles of Teal Management, drawing on techniques from DevOps, Lean Startup (R), SAFe (R), and more, and combined with practical, real-world techniques, honed over years of practice. (You do not, however, have to be a “Teal” organization to use this model. Rather, this program is a map of “the road to Teal”. And while Teal Management will be referenced in this case study, it will not be talked about in depth.)

An Agile Transformation is very difficult. We found that each team needs to travel at its own speed, and one size does not fit all. This case study is how we make that happen, show appreciate for the uniqueness of each team, and ensure consistent, measurable, overall success.

Are you “going Agile” but your executives are still asking you for Gantt charts and delivery dates? Here’s an exercise to do with them instead. Usually, they just want to know when to check back on “the project”, and whether or not their money is being well invested.

To answer the last question, many teams have discovered the “Weighted, Shortest Job First (WSJF)” method of project prioritization. Basically, if you have two items of equal effort, but one has twice the return on investment (ROI) of the other, do the one with greater ROI. And if you have two items of equal ROI, but one can be done in half the time, do the shortest job first. But that’s not enough. We all know of projects that had great promise, but customers wouldn’t pay for it.

Lean Startup has discovered that emotions are one of the best leading indicators (predictors) of future product success. Emotional-WSJF (eWSJF) balances customer demand with Minimum Viable Products (MVPs), i.e. "this only has true business value if we can deliver within 2-3 sprints."

I use eWSJF within my teams to prioritize Epics, and I’ll show you how to use it to keep your executives happy! It replaces the conversations about “Show me a Gantt chart,” and “When will this be delivered?” My executives instead ask, “Have you talked to any customers?” or “Can you build it faster?” To which my teams respond, “Yes we have talked to customers, and they’re even helping us beta test it!” and, “The next version will be delivered in two weeks, and here’s what it contains.”

Your team process is getting Agile, but is your code Agile? How long does it take you to add a new feature? How about a logger that listens to every object in your application? For me it’s a just a few lines of code.

After designing software for over a decade for the DOD, the FDA, NASA, the DC Metro, multiple startups, and more, I discovered the architecture that made me truly Agile, and it became the foundation for my next decade of work. It was designed through what I call “looking back at the present from the future,” which is a long-winded way to say that it was designed around what would make an application easier to maintain, since on average 85% of the cost of any application is during its maintenance phase. Turns out this makes it easier to build applications from scratch too!

Property-Invocation Programming is like Story Splitting in code form. Each step of your workflow is encapsulated in a function, and the init() function for your object shows a map of how all those pieces come together, and in which order. With this map, you can have multiple developers working on the same object, and even the same file, without merge conflicts. Integration testing is just a matter of executing your functions in the correct order. And a year from now, when your Product Owner needs changes, but you’ve forgotten what you wrote, it’s all mapped out neatly in your init() function. No hunting for code. Just read what you wrote, add new functions, and insert them in the right order.

In this session I’ll show you the four simple rules at the heart of Property-Invocation Programming, and how to leverage them to create truly Agile software architectures. We’ll also look at how to build a new cross-platform (mobile and desktop) application from scratch that can handle anything your Product Owners throw at it. Plus I'll walk through the 5 Pillars of Modern Application Architecture that I used with my teams.

HOW you introduce a new practice to your organization is ten times more important than WHICH new practice you introduce. When is the right time for SAFe, DevOps, Lean Startup, or Usability Testing? Using learning from the “Teal” playbook, learn how to assess the current state of your organization and build a roadmap for introducing the right initiatives at the right time.

Agile delivers a huge jump in team productivity. Explaining this in words to someone who’s never seen it in action is often hugely difficult, if not impossible. This 10-minute simulation allows participants to experience Agile and immediately see the benefits. You’ll also be able to immediately take this exercise back to your teams. All you need is a deck of cards. (Cards will be provided for this session!)

Learn about the latest developments in brain research, and the practical exercises they’ve produced for facilitating conversations (even the most-difficult ones) and turning them into concrete action plans.

Have you experienced any of the following?

• Witnessed two people arguing the same side of an issue, at each other?
• Reached the end of a meeting with no decisions made?
• Been told, “That’s not what I thought I was getting.”?
• Had a great idea, but couldn’t get anyone to listen?
• Had anyone shout in your meetings?

Even if your teams aren’t necessarily in conflict, the techniques discussed in this session will deliver an repeatable way to discuss complex, multi-sided issues, in an organized way that respects all participants, makes sure everyone feels heard, and produces tangible results that everyone can be proud of.