Are customers beating down your door before the product is even ready? Do you have an inexhaustible number of new ideas on the horizon? And are your teams cranking them out month after month? If you answered no to some or all of those questions, then... your employees are probably afraid of emotions, and it's standing in your way.

Yes, I did just say that emotions are the thing in your way.

And you're not alone. The Age of Reason brought us Scientific Discovery, which is vital to continued survival, for people and companies. It inspired the Industrial Revolution. We reached for the stars, and touched other planets. So we raised up idols like Mr. Spock from Star Trek, and phrases like, "It's not Rocket Science". The Toyota Lean Movement inspired additional data-driven revolutions like Agile and DevOps. We automated our factories, and our stock market transactions. We created machines that can learn, and cars that can drive themselves.

And... we tricked ourselves into thinking that WE also became logical in the process.

But we're still human beings. In 2002 the Nobel Prize was awarded to two economists for research that proved that the decision making part of our brain is not connected to the logical part of our brain. Decision making is still done with our emotional brain. The emotions of your customers prevent them from buying. The emotions of your managers prevent them from making the right decisions. The emotions of your employees prevent them from delivering great ideas. And you can't just remove emotions from the equation. You must understand them, embrace them, and journey through them, to get to the other side. And on that other side you will coincidentally find our old friend, Reason.

If you don't start embracing emotions, talking about them, and designing for them, then you will be left behind. It's what makes Apple and Amazon successful. (It's why Donald Trump got elected.) And it's why your products are failing.

It’s the latest and greatest business bingo term, the Minimum Viable Product, or MVP! It even has its own children now, like Minimum Loveable Products (M♥️Ps), Minimum Marketable Products (MMPs), and Minimum Marketable Features (MMFs). It’s made it up to the executive level, and almost every organization I work with these days has at least heard of the MVP.

But almost no one actually does it right. Most just map the name onto old Project Management concepts of “this is what I want in my first release”. Like Agile itself, MVP is a mindset shift. It’s not like anything most of us have ever done before.

• Do your “MVPs” take less than a month to build? If not, you’re doing them wrong.
• Do your customers pay you to build your “MVPs”? If not, you’re doing them wrong.
• Do your “MVPs” make your users light up with joy? If not, you’re doing them wrong.

I'll show you a build and release prioritization technique, based off of Lean Startup workshops I’ve been running since 2010, that can be done in hours - not days - and which will produce a true Agile Design that your teams can implement, in true iterative fashion.

Having led or assisted on multiple whole-organization Agile Transformations, I know it can be a difficult road to navigate. There are many flavors of Agile, each with their own dictionaries of common Agile terms, often in conflict with each other. Agile coaches can give you widely different advice. And on top of this there are different levels of experience throughout the organization, so some employees are overwhelmed while others are bored.

Are you struggling with your Agile Transformation? Have you ever rolled out a new technology or a new practice that worked great for one team but fell flat with another? Do you have some teams that just aren’t getting any better? You’re not alone.

The reason is psychology. Some organizations and some teams aren’t ready. Others, like Icarus, fly too high, too fast, and crash and burn. In my practice I started noticing an overlap, between the Agile landscape and a 40-year study on human social evolution I had been exploring. Now, several transformations later, I can show you how to spot the patterns, and engineer your own Agile Transformation.

In this workshop we’ll walk through and self-assess your organization across 4 levels: Team Value Delivery, End-to-End Team Alignment, Data-Driven Market Analysis, and Culture/Mission. We’ll use a simplified form of an assessment tool called the Agile Transformation Roadmap that you can take with you as a way to plan your own Agile Transformation adventure.

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.