Agile Mindset

So, I'm doing this second talk because Peru couldn't make it. Unfortunately, he's living in Japan—well, unfortunate for us, fortunate for him. There are weather problems in Japan, as you’ve probably heard, and no place that allowed him to present. So, this is what I’m using for this presentation.

Normally, this presentation takes way longer than half an hour, so I’ve already skipped a lot of slides that were similar to what we covered this morning. I’ll try to keep track, but if someone could tell me when it’s over, that would be helpful.

In 1970, Royce Limited published a paper. Who here was around in 1970? Who was alive? Not many—maybe two or three people? Not even five or six. Well, in that paper, he documented something called "Managing the Development of Large Software Systems." On the second slide, or the second section, there was a diagram—one we all now recognize as the waterfall model. But actually, when he wrote this, the word "waterfall" was never used in his document. Even more interesting, on the third page, he wrote, "I believe in this concept, but the implementation described above is risky and invites failure."

The person who supposedly invented waterfall was already telling us not to use it. The rest of his document—16 or 17 pages—explains what we should do instead, which is to go back and iterate, exactly what we now call Agile. But most people, journalists included, just read the first two pages, saw the diagram, and decided, "Hey, this looks great!" They called it waterfall and said everyone should work this way, which is the exact opposite of what he intended.

Fast forward a few decades to February 11-13, 2001. A few white men gathered together—yes, mostly white men. Like I said this morning, for me, the most important part of the Agile Manifesto is this: "We are uncovering better ways of developing software by doing it and helping others do it." If you look at some of the names on the manifesto, like Kent Beck, who I talked about earlier, many of them were still actively coding even years later—not just consulting, but actually doing the work.

Who here has read the Agile Manifesto? Lots of people. Who has read the second page? Fewer hands. Who has read the signatory statements? Even fewer. It’s interesting how people focus on the headline and ignore the depth behind it.

Now, people often ask me, "We want to do Agile by the book." My response is always, "Which Agile book?" There are many Agile books, and they contradict each other. For example, I worked with a product owner who was asking for help, but the way she asked was all about "how" questions. She was looking for a silver bullet. But, as I said this morning, there are no silver bullets. I love this quote from a completely different field: "Every tool can be used as a weapon if you hold it right." If you're looking for a silver bullet, be careful—you might end up being the target instead.

People get obsessed with the "how" of Agile. They ask, "How do we implement it?" But if your "why" is zero, then all the "how" in the world won't help. It’s a simple formula—if your "why" is strong, the "how" follows naturally. This is why I always push teams to think about the purpose behind what they are doing.

Let’s talk about an analogy. If you were doing fire walking, and you started walking across the hot coals, one thing is crucial: you should not stop halfway. If you start, you need to keep stepping forward. The same applies to Agile—once you commit, you have to keep going. You might hesitate before you begin, and that’s fine, but once you start, stopping halfway will burn you.

Agile is also about balancing short-term and long-term thinking. Long-term is important, but if you focus only on the long-term and ignore short-term realities, your project or company might not survive to see that future. One of the ways I learned this was from Stephen Covey, who said, "Begin with the end in mind."

In 2010, I was in the south of France with my family. My son needed to complete some schoolwork before we returned to Belgium. My partner was worried—she didn’t think he would finish in time. So, we broke it down. He had nearly 300 pages to complete before September. We calculated—how many pages per day would he need to do? The answer was seven. But he was doing only one or two pages most days. So, we adjusted—if he wanted to finish early, he needed to do ten pages a day. The moment he understood the math, a remarkable thing happened—we never had to remind him again. He took ownership of the goal.

One day, he was so motivated he did 22 pages in a single sitting. The next day? Almost nothing. This is exactly what happens in companies. People sprint ahead, then crash. But since we tracked the progress visibly, he quickly saw he needed to get back on track. In the end, he finished two days ahead of schedule.

Another key principle in Agile is limiting what you take on. When we moved to France, my family of five packed everything into a single moving truck. I was proud of how much we had minimized—until I saw two friends who traveled the world with just a suitcase each. That made me realize I still had a long way to go in simplifying.

Long-term thinking also means building quality into the system. Look at this build monitor. It hasn’t been broken in 35 days. Is that good? Some might say yes. But I think it’s suspicious—either they aren’t testing enough, or they’re afraid to change things. In Agile, we should be breaking things occasionally, but fixing them quickly.

Now, let's talk about trust. Once, I ran a leadership training and handed my expensive camera to the participants, telling them to use it freely for a week. When I got it back, I found a bunch of unexpected, creative photos—including this one, where they had arranged themselves to spell out "Leadership" using their bodies. That’s the power of trust—when you let people take ownership, they create things you could never have planned.

Agile is also about transparency. In one company, we had a board right outside the CEO’s office. One task was marked as "blocked" for two days. The CEO walked by and asked about it. The team told him, "We’ve been trying to reach you about this." Five minutes later, he made a phone call, and the issue was resolved. That’s the power of visible work.

Facing reality is another crucial principle. My son once climbed a tree and got stuck. He was terrified. Some parents might say, "It’s not a big deal." But for him, it was. Instead, I acknowledged his fear: "I see you're scared. I think you'll be okay." That small difference in messaging changes everything. Agile is about seeing reality as it is, not dismissing problems.

One final thought—quality. Imagine a restaurant where they stop cleaning to save money. For a while, things seem fine. But eventually, the kitchen gets so dirty that it has to shut down. That’s exactly what happens in software development when we neglect quality. We say, "We don’t have time for refactoring," but later, we ask for huge budgets to fix the mess we created. It doesn’t work. The professional approach is to clean as you go.

Thank you very much.