Book Notes #17: Changing Software Development by Allan Kelly

Title: Changing Software Development: Learning to Become Agile
Author: Allan Kelly
Year: 2008
Pages: 258

Changing Software Development is peppered with practical advice and case studies to explain how and why knowledge, learning, and change are important in the development process. 

I thought I’d be reading another book about Agile tools and team roles. Instead, I found something that challenged how I think about learning, working, and leading change.

This book isn’t just for software folks—it’s for anyone who believes that improvement is possible, and that change starts with people, not process.

If you’ve ever felt stuck in how things are done at work, or wished there was a more human way to evolve how teams operate, this one’s for you.

As a result, I gave this book a rating of 7.5/10.

For me, a book with a note 10 is one I consider reading again every year. Among the books I rank with 10, for example, are How to Win Friends and Influence People and Factfulness.

3 Reasons to Read Changing Software Development

Book Overview

We often talk about change like it’s a destination—something to reach after a major project, a new tool rollout, or a bold organizational restructure. But what if change isn’t a place you arrive at, but something you practice every day? What if it isn’t something someone gives you, but something you grow into—one learning, one habit, one insight at a time?

That’s the quiet but powerful truth at the heart of Changing Software Development: Learning to Become Agile by Allan Kelly. While many books about Agile focus on frameworks, tools, and rituals, this one does something refreshingly different: it zooms in on the human side of software, the messy middle where real change happens—not through certifications, but through learning, reflection, and action.

From the very first chapter, Kelly reframes software development not as a mechanical process, but as a learning journey. Developers aren’t factory workers—they’re knowledge workers. And knowledge, unlike code, doesn’t sit neatly in version control. It’s created, shared, challenged, and lived. Teams learn as they go. Users discover their needs by using the thing you built. And developers, in trying to solve problems, end up transforming the very problems they set out to fix.

One of the most engaging parts of the book is how it weaves learning and change into a single thread. Kelly argues that you don’t truly learn something unless it changes the way you act. Think about that for a moment. How often do teams reflect on retrospectives but return to the same old patterns? How many organizations say they value learning, yet penalize failure and reward predictability? This book challenges those patterns—not with buzzwords, but with grounded ideas that invite you to rethink your role in the system.

The author draws from a rich mix of influences—Deming, Senge, Drucker, Nonaka—and blends them into a clear, human-centered perspective. He doesn’t treat Agile as a checklist of practices, but as a mindset rooted in responsiveness, experimentation, and humility. The real test of an Agile team, he says, isn’t whether they run sprints or stand-ups—it’s whether they learn, adapt, and improve over time.

But here’s where the book really stands out: it refuses to fall into the trap of waiting for permission. Instead of preaching about top-down transformations, Kelly shows how change often begins from the bottom up—with individuals who dare to see things differently. Whether you’re a developer, a tester, or a team lead, the invitation is clear: start where you are. Reflect on what’s working, what’s not, and what you can do about it. Don’t wait for management to approve a grand change initiative. Find your allies. Start small. Rehearse the future you want to see.

And when it comes to planning, the book offers a surprisingly gentle take. Plans are useful—but only if we treat them as tools for thinking, not as promises to predict the future. Kelly encourages scenario planning, retrospectives, and “process miniatures”—tiny simulations of change that help teams build confidence and uncover hidden assumptions. Change, in his view, is like learning to play an instrument. You don’t just talk about it—you practice.

That practice, of course, isn’t always easy. Change is emotional. People resist, not because they’re stubborn, but because they’re uncertain. They might not see what’s possible. That’s why the book encourages clarity over jargon, storytelling over theory, and listening over instructing. Instead of launching into talk about “learning organizations” or “continuous improvement,” Kelly advises you to do the work quietly—help people learn, remove barriers, and make space for small wins.

In the final chapter, the book ends not with a conclusion, but with a beginning. Change never ends, because learning never ends. You celebrate a win, and then the next opportunity shows up. You fix one process, and uncover another. You grow your influence, not by demanding it, but by showing what’s possible and helping others succeed.

Reading this book feels less like reading a manual and more like having a thoughtful conversation with someone who’s walked this road before. It doesn’t try to hype Agile as a silver bullet. Instead, it leaves you with something more valuable: a quiet confidence that meaningful change is possible—and that it starts with learning, reflection, and the courage to act.

So if you’re feeling stuck in your organization, or wondering how to make Agile more than a set of ceremonies, this book offers a gentle but firm push. Not toward perfection, but toward progress. One step, one conversation, one lesson at a time.

Key concepts include:

Software Development as a Learning Activity: At the heart of the book is the idea that software development isn’t just a technical endeavor—it’s fundamentally a learning process. Developers learn about the problem, the tools, the users, and the solution as they build. This ongoing learning shapes the product and the process, meaning software isn’t “delivered” so much as “discovered” through iteration, conversation, and reflection.

Knowledge vs. Information: Kelly draws a clear distinction between data, information, and knowledge. While data is raw and information changes understanding, knowledge is something richer—it’s lived, contextual, and often tacit. It includes experience, intuition, and culture. You can write down information, but knowledge has to be shared through action, collaboration, and time spent solving real problems.

Tacit vs. Explicit Knowledge: Tacit knowledge is what people know but struggle to express—like navigating a complex codebase or understanding how a team really works. Explicit knowledge is what can be easily documented. Most valuable team knowledge is tacit, which is why documentation alone isn’t enough. Agile encourages collaboration because much of what teams need to know can only be transferred through close work and shared experience.

Ba (Shared Context for Knowledge): The Japanese concept of ba refers to the space—physical, social, or emotional—where knowledge emerges and flows. Without a shared context, people might use the same words but mean different things. Agile rituals like stand-ups and retrospectives help teams create ba so knowledge can move between individuals and evolve collectively.

The Knowing–Doing Gap: Organizations often know what they should do—but don’t do it. This gap between knowledge and action is where change efforts fail. Learning, in Kelly’s view, only becomes real when it translates into action. Agile addresses this gap by keeping learning loops tight: learn, try, reflect, adapt.

Learning Loops (Single, Double, and Triple): Single-loop learning is about correcting mistakes without changing the underlying assumptions. Double-loop learning questions the assumptions themselves. Triple-loop learning goes even deeper, questioning one’s identity and values. Agile teams thrive when they engage in double-loop learning—rethinking not just what they’re doing but why they’re doing it.

The Learning Organization: A learning organization encourages continuous improvement, personal mastery, and collective growth. Drawing from Peter Senge’s work, Kelly explains that such organizations thrive through shared vision, open reflection, and systems thinking. Instead of punishing failure, they create space for experimentation and learning, allowing teams to grow stronger over time.

Change as a Human Process: Change isn’t just organizational—it’s deeply human. People experience emotional responses like fear, uncertainty, and resistance. Kelly insists that successful change requires trust, empathy, and time. It’s not about enforcing new methods but creating the space for people to internalize and embrace them.

Incremental vs. Radical Change: Not all change is created equal. Incremental change happens in small steps and is easier to digest. Radical change is more disruptive and often harder to sustain. Kelly advocates for continuous, intentional, incremental change—because it allows people to adjust gradually and builds momentum over time without overwhelming the system.

Feedback Loops: Feedback is essential for learning. Agile relies on short, frequent feedback loops to help teams adjust quickly and accurately. Whether it’s from tests, users, retrospectives, or metrics, feedback must be visible, timely, and relevant to be useful.

Planning as Rehearsal: Plans aren’t roadmaps—they’re rehearsals. Kelly redefines planning as a learning activity that prepares teams for a range of possibilities, not a fixed timeline. By thinking through options and scenarios together, teams build shared expectations and strengthen their ability to adapt when things don’t go as planned.

Scenario Planning: Instead of predicting the future, scenario planning helps teams imagine multiple possible outcomes and prepare flexible responses. This builds resilience. Teams that explore “what if” scenarios can respond more calmly and creatively when real change hits.

Process Miniatures: These are small, time-boxed simulations of a full development cycle—like a one-hour Scrum sprint—to help teams experience Agile concepts quickly and safely. They allow for rapid learning and reflection, especially in training or coaching sessions, without the stakes of real projects.

The Role of Slack in Learning: Slack refers to the time and space needed for teams to reflect, experiment, and grow. Without slack, teams are too busy to improve. Kelly argues that organizations must create slack intentionally—whether through protected time, dedicated retrospectives, or reduced load—so learning can happen.

Appreciative Inquiry: This approach to change starts by asking what’s working well, rather than what’s broken. By identifying strengths and building on them, teams generate energy, hope, and engagement. Kelly contrasts this with problem-focused change, which can feel heavy and demotivating.

Push vs. Pull Motivation: Push motivation uses pressure, fear, or authority to drive change. Pull motivation relies on vision, opportunity, and purpose. While both can be useful, pull creates more sustainable and healthy change environments. Agile, when practiced well, taps into pull by inspiring teams through ownership and meaningful goals.

Empowerment and Legitimacy
Empowerment isn’t just giving people tasks—it means giving them authority, trust, and support to act. But empowerment also requires legitimacy. People need to believe their voice matters and their actions will have impact. Leaders must model the behavior they want and step back enough to let others lead.

Mental Blocks and Resistance: Not all resistance is defiance. Often, people resist change because of mental blocks—deep assumptions about what’s possible, what’s allowed, or what will fail. Kelly encourages leaders to listen closely and help people unlearn these internal stories, turning resistance into curiosity and momentum.

Systems Thinking: Instead of focusing on isolated tasks or roles, systems thinking looks at how everything connects. A bug isn’t just a coding error—it might reflect a lack of communication or a broken feedback loop. Agile teams succeed when they understand how their actions ripple through the whole system.

Change Events (Retrospectives, Workouts, Kaizen, etc.): Kelly introduces a range of practical methods to spark change: retrospectives for reflection, workouts for solving real problems collaboratively, Kaizen for ongoing improvement, and Kaikaku for transformative shifts. These events give teams a chance to pause, regroup, and actively shape their future.

Consultants, Coaches, and Facilitators: External help can support change—but only if it empowers internal teams. Consultants bring knowledge, coaches nurture growth, and facilitators create space for honest dialogue. The goal isn’t dependency—it’s building internal capability so teams can keep learning long after the external support is gone.

Change Agents and Lieutenants: Successful change efforts rely on more than one person. A change agent might start the journey, but they need lieutenants—people who carry the message, support others, and help embed new behaviors. Change spreads when more people start leading it.

Circles of Influence and Concern: Borrowing from Stephen Covey, Kelly explains that individuals should focus on what they can control—their circle of influence—rather than worrying about everything they can’t. Small wins within your control can expand your influence and gradually shape the wider system.

Continuous Change as a Culture: The ultimate goal isn’t a single transformation—it’s building a culture where change is normal. A place where learning is ongoing, improvement is expected, and reflection is part of the rhythm of work. In such an environment, Agile isn’t a method—it’s just how things are done.

Chapter by Chapter

Chapter 1 – Introduction

What this chapter is really about
This opening chapter lays the foundation for the entire book by presenting a bold yet simple idea: software development is not just a technical task—it’s a process of learning. Allan Kelly argues that learning is central to successful software development and that learning, when paired with action, becomes knowledge. To move forward, teams must learn, and that learning must lead to change. Without change, learning is wasted. This simple loop—learn, act, adapt—is at the heart of both Agile practices and the modern knowledge economy.

Learning and change go hand in hand
One of the most important insights here is that learning can’t happen in isolation. We need to shift how we work, not just what we know. The chapter outlines three kinds of change software teams face: adopting Agile methods, evolving beyond standard practices, and helping users adapt to changes brought by software. Interestingly, Kelly warns that change driven by top-down authority often fails, especially with knowledge workers like developers, who thrive on autonomy and purpose.

Developers are not factory workers
This part is particularly striking. Kelly challenges the outdated notion that software development should be treated like a manufacturing process. He emphasizes that developers are knowledge workers—more like scientists or artists than assembly line workers. They need environments that foster learning, collaboration, and creativity. Viewing software teams through this lens, rather than as interchangeable cogs, opens the door to better management practices, higher job satisfaction, and better outcomes.

So why does this matter?
Because in today’s world, the only real competitive advantage is the ability to learn faster than your competitors. That’s true for companies and individuals. The author encourages readers to reflect on why they want change and to start with themselves—by learning, thinking critically about their environment, and leading by example. This mix of self-awareness and team awareness sets the tone for the rest of the book.

Kelly is preparing us for a journey that’s not just about Agile tools or processes. It’s about seeing software development differently—through the lens of learning. By embracing this mindset, teams can break out of old habits and move toward something better, smarter, and more human.

Chapter 2 – Understanding Agile

Where Agile really came from
This chapter is like a history lesson with a twist. It walks us through the journey that led to Agile, starting from the chaos of early software development, when programming felt like building a plane mid-air. Back in the 1960s, the term “software crisis” was coined to describe the constant failure of projects—late deliveries, blown budgets, and incomplete products. The response was to treat software like engineering, with strict processes and heavy documentation. But decades later, the problems still lingered. That’s when a group of forward-thinkers—names like Kent Beck and Alistair Cockburn—decided to try something different. They favored lightweight, flexible methods. That movement led to the Agile Manifesto in 2001.

Agile isn’t just a method—it’s a mindset
Kelly makes it clear that Agile isn’t just a checklist of practices like Scrum or XP. It’s a broader philosophy rooted in simplicity, responsiveness, and—most importantly—learning. Agile took ideas from smart people like Deming and Crosby, who emphasized quality, continuous improvement, and putting people first. It also learned from real-world experiences: things like prototyping, short feedback loops, and collaborative teams. Agile is not about doing things faster—it’s about doing things smarter and adapting constantly.

From Agile to Lean to Learning
A fascinating part of this chapter is how Kelly places Agile within a larger ecosystem. He shows that Agile methods (like Scrum and XP) sit within the broader category of Agile thinking, which itself is a form of Lean thinking. And Lean, in turn, is rooted in the idea of the learning organization. So in a way, Agile is just one flavor of how learning shows up in practice. This layered view helps explain why Agile isn’t a one-size-fits-all approach—it evolves depending on the team, the product, and the business needs.

The everyday practices that make Agile work
Kelly then walks us through the most common Agile practices, but always with a learning lens. For example, pair programming isn’t just about writing better code—it’s about shared understanding. Time-boxed iterations aren’t just about scheduling—they help teams learn faster. Practices like test-driven development, continuous integration, and working closely with customers all serve the same purpose: learning quickly and acting on that learning.

A new agreement between business and tech
Another strong point in the chapter is what Kelly calls “The New Bargain.” He explains that Agile replaces the old illusions (like perfect plans and fixed requirements) with a new, more honest deal between developers and the business. The business agrees to stay involved and prioritize work; the team agrees to focus on what matters, deliver fast, and maintain quality. This trust-based model is more demanding—but also more rewarding.

Agile beyond software? Maybe—But not quite yet
Finally, Kelly asks whether Agile can be applied outside software. His answer? Yes, in spirit. Companies like Toyota and Dell already behave in Agile-like ways, even if they don’t call it that. But for now, “Agile” still mainly refers to software development. What these Agile-like organizations do share, though, is a commitment to learning, feedback, and continuous improvement.

This chapter helps us understand that Agile is more than tools or ceremonies. At its core, it’s about learning and adapting. It’s about working with—not against—change. And as Kelly emphasizes, Agile without learning is just going through the motions. The rest of the book promises to dig deeper into how we can turn that mindset into real, lasting improvement.

Chapter 3 – Knowledge

Why knowledge matters more than we think
This chapter dives deep into a term we throw around a lot—knowledge—but rarely stop to define. Allan Kelly makes a strong case that if we want to treat software development as a knowledge activity, we need to get serious about understanding what knowledge actually is. He starts by drawing a clear line between data, information, and knowledge. Data is just raw facts. Information is what changes our understanding. But knowledge is something else entirely—it lives in our heads, shaped by our beliefs, actions, and the context we work in. And unlike information, knowledge can’t be easily written down, transferred, or even seen.

Knowledge needs a space—and that space matters
Kelly introduces the Japanese concept of ba, which is essentially the space—physical, social, or cultural—where knowledge exists and grows. It’s not just about what we know, but where and how we use that knowledge. For example, knowing a programming language goes far beyond syntax; it’s about the idioms, style, and community practices—something you pick up through experience. That’s ba. When we ignore this context, knowledge gets reduced to plain information, and we lose something essential.

The knowing-doing gap is real
One of the most relatable insights is how organizations often know what they should do—but don’t do it. We’ve all seen it: the team that knows quality is poor but doesn’t fix it, or management that asks for innovation but resists change. Kelly calls this the “knowing-doing gap,” and he argues it’s one of the biggest barriers to improving software development. It’s not that we lack knowledge. It’s that we fail to act on it—and that failure holds us back more than any lack of technical skill.

The invisible side of knowledge: tacit vs. explicit
Another core idea in the chapter is the distinction between explicit knowledge—what you can write down or teach in a manual—and tacit knowledge, which is harder to express. It’s the stuff you learn by doing, watching others, or working through challenges. Think of riding a bike: you can’t learn it from a book. The same is true for navigating a codebase, understanding business context, or knowing “how we do things here.” Most of the valuable knowledge in software teams is tacit, and this makes things like handovers, documentation, and onboarding more complex than we like to admit.

Sticky knowledge and Xerox’s missed opportunity
The story of Xerox PARC is a powerful example of what can go wrong. PARC invented groundbreaking technologies, but the knowledge stayed “sticky”—it didn’t flow inside the organization. Meanwhile, it leaked easily to Apple, which turned it into the Macintosh. The lesson? Knowledge doesn’t care about org charts. It flows where it’s welcomed and dies where it’s ignored. Companies need to create environments that support the movement and growth of knowledge—or they risk losing it to more agile competitors.

Documentation can’t save us
Kelly pushes back on the idea that documentation solves knowledge problems. He calls it the “documentation myth”—the belief that everything important can be captured in writing. But much of what makes software work lives in tacit knowledge, team culture, and personal experience. You can’t document your way out of that. Over-reliance on documents leads to unread manuals, misunderstood designs, and false confidence.

Knowledge isn’t just stored—it’s created
Toward the end, Kelly introduces Nonaka’s SECI model of knowledge creation, which explains how we move from tacit to explicit knowledge and back again. It’s a cycle: we socialize knowledge, express it, combine it with other ideas, and internalize it again. This is exactly what happens in good software teams—through conversations, prototypes, testing, and reflection. The model shows that creating knowledge is an active, ongoing process, not a one-time transfer.

So what does this mean for software?
Software development is, at its core, about turning knowledge into code. But the knowledge doesn’t come from nowhere. It’s born in the messy, complex world of human experience—inside teams, organizations, and users. Developers not only use knowledge, they create it. And if we want to get better at building software, we need to get better at learning, sharing, and acting on that knowledge. Kelly’s message is clear: knowledge is our most important asset—and also our biggest blind spot.

Chapter 4 – Learning

Learning is the one skill that truly matters
This chapter opens with a powerful idea: in a world of constant change, the only real skill we need is the ability to learn. Allan Kelly argues that whether you’re a programmer, a manager, or somewhere in between, you’ve likely spent the last decade learning new tools, languages, frameworks, or business strategies. So if change is inevitable, then learning is how we keep up—and more importantly, how we improve.

Three domains of knowledge
Kelly introduces three overlapping types of knowledge in software development. First is the application domain, which is all about the business problem you’re trying to solve. Then there’s the solution domain, which includes the technical tools and methods you use. Finally, there’s the process domain, which covers how we actually go about building software. Great developers often move between these domains, learning from each, while customers and users are also learning—sometimes without even realizing it.

Development is learning, full stop
At its core, software development is a learning activity. Teams learn about technology, the problem domain, how to solve issues, and users even learn about their own problems through using the software. Every project is a cycle of discovery and adaptation. Kelly stresses that instead of resisting this, we should embrace it—because trying to freeze the learning process only leads to frustration and missed opportunities.

The real business advantage: people who learn
Why should companies care about learning? Kelly flips the script on traditional thinking. Instead of just hiring smart people for what they already know, companies should invest in helping them learn even more. He points out that learning is how human capital becomes more valuable over time, unlike machines or tools that depreciate. Companies that foster learning gain an edge that competitors can’t easily copy.

Learning happens in loops
One of the most insightful parts of the chapter is Kelly’s explanation of single-loop and double-loop learning. Single-loop is like a thermostat—it follows rules but doesn’t question them. Double-loop learning is deeper: it challenges assumptions and rewrites the rules. This kind of learning leads to innovation. He even touches on a possible third loop, which involves identity—how people see themselves (e.g., “I’m a developer, not a tester”) can affect what they’re willing to learn.

Different people, different learning styles
The chapter also dives into Kolb’s learning model, which shows how people prefer to learn in different ways—some through doing, others through observing, theorizing, or experimenting. Understanding this helps teams work better together and appreciate different perspectives. Tools like Myers-Briggs and Belbin also come up, showing how diverse thinking and roles can strengthen or weaken team dynamics depending on how they’re managed.

Learning = Change = Innovation = Problem-Solving
Kelly ties together learning, change, innovation, and problem-solving as essentially the same thing. When we learn, we change. When we innovate, we’re learning something new. And when we solve problems, it’s because we’ve learned something useful. They’re not separate ideas—they’re different sides of the same coin.

The leader’s new role: enabler of learning
In a traditional setup, managers are expected to control, direct, and keep things on track. But in a learning-focused environment, leaders should act as facilitators. Their job is to create space for learning, protect the team from distractions, and help people grow. The best leaders help remove obstacles—both external and internal—so people can reflect, challenge assumptions, and explore better ways of working.

Practical ways to spark learning
The chapter ends with a long list of ways to seed learning in an organization. From reflective journaling and training courses to internal talk programs, book clubs, wikis, blogs, and searchable intranets—Kelly shares that small steps can lead to big shifts in culture. The goal isn’t to force learning but to create an environment where learning naturally happens. Even debates and informal chats can plant seeds that lead to meaningful change.

This chapter is a call to action: treat learning as a central part of how your team works. If you can learn faster, reflect deeper, and act smarter, you’ll build better software and create a workplace where people thrive. And once your team becomes a learning engine, competitors won’t be able to keep up—not because of tools or budgets, but because they’ll be solving yesterday’s problems while your team invents tomorrow’s solutions.

Chapter 5 – The Learning Organization

Why learning organizations matter (and why they’re rare)
Allan Kelly opens this chapter by zooming out—moving from individual and team learning to what it means for an entire organization to learn. He argues that Agile teams must become “learning teams,” and that these teams, when multiplied, form the foundation of a true learning organization. But there’s a catch: most companies are unintentionally set up to block learning. The drive to cut costs, meet deadlines, and maintain control often squashes the time, space, and trust required for real growth. This creates a frustrating paradox: we need learning to survive, yet the system often gets in the way.

The spiral of learning: up or down
Kelly presents two learning spirals. Positive learning leads to improvement, motivation, and new opportunities. Negative learning—like gaming estimates or avoiding difficult code—just piles on more problems. Both are self-reinforcing. A key insight here is that all companies learn, but not all learning is beneficial. Some teams, for example, learn to avoid blame rather than improve performance. The challenge is making sure learning drives progress, not survival tactics.

Only people can learn
Organizations don’t literally “learn”—people do. And as they share experiences, observe each other, and form teams, this learning scales upward. Kelly compares it to a Turing test: from the outside, it may look like the company itself is learning, but it’s actually individuals and communities within who are growing and adapting. The implication is clear: if you want a smarter organization, you need to empower your people to learn and share what they know.

The double-edged role of IT
IT can both support and hinder learning. Kelly breaks this into two schools of thought. First, IT as a learning tool—think e-learning platforms or knowledge databases. But he warns that this often falls short because it overlooks the value of action and tacit knowledge. The second school is IT as an agent of change, where new systems shake up how people work and trigger fresh learning. This second stream is less talked about but far more impactful.

Technology vs. people: a tale of two streams
The dominant narrative in software still treats development as a rational process—pick the right method, tool, or language and everything works out. But Kelly brings attention to a second, more human-focused stream of thought, captured by classics like Peopleware and The Mythical Man-Month. These works show that success is more about how people work together than the tools they use. Unfortunately, the tech-heavy narrative still overshadows this view in practice and education.

Hiring for growth, not just skills
Companies often try to solve everything by hiring the “best people.” But Kelly argues this strategy doesn’t scale. Everyone’s chasing the same talent, and even brilliant hires can fail without the ability to work in teams. Instead, learning organizations invest in growing their own talent. It’s about hiring for potential—not just raw skills—and building a culture where people can develop over time and contribute meaningfully to the team.

Business as an infinite game
One of the most memorable parts of the chapter is the distinction between finite and infinite games. Software development and business are infinite games—you don’t “win,” you just keep playing. Every project or product release is a round. You need to survive the current round, but also prepare for the next. Agile teams often fall into the trap of over-focusing on the immediate deliverable. Kelly suggests a better long-term strategy: stop future-proofing code, and start future-proofing people.

Building a learning organization, layer by layer
Using a layered model, Kelly shows that learning organizations are built from the bottom up. First, you need trust and honesty. Then you need slack—time, space, and resources for people to learn. With those in place, individual learning leads to empowerment, team learning, and eventually organizational change. Without tolerance for failure or time for reflection, though, none of this can take root. The goal is not perfection, but momentum—toward better thinking, better collaboration, and smarter systems.

Peter Senge’s five disciplines
Kelly brings in Peter Senge’s classic The Fifth Discipline, summarizing the key elements of a learning organization: personal mastery, shared vision, team learning, mental models, and systems thinking. These aren’t just nice-to-haves—they’re essential for any team or company that wants to thrive long term. Senge also highlights reflection as a hidden sixth discipline, showing how slowing down and thinking deeply is critical for both individual and collective growth.

The real enemies of learning
The chapter ends with a sobering look at what blocks learning: invisibility (we don’t see the problem), camouflage (we patch it without fixing it), personal defenses (we protect ourselves from discomfort), and overemphasis on action (we’re too busy to think). He also calls out common anti-patterns like solo developer projects and resource pools, which kill collaboration, fragment teams, and build brittle systems. These may seem efficient in the short term, but they create long-term chaos.

In short, Kelly paints a realistic but hopeful picture. Learning doesn’t just happen—it needs space, support, and culture. And the best way to build that isn’t more tools or process—it’s investing in people. Empower them, trust them, and give them time to reflect and grow. Do that, and you won’t just get better software—you’ll build an organization that’s ready for whatever comes next.

Chapter 6 – Information Technology: The Bringer of Change

IT is a force for change—like it or not
This chapter begins with a powerful idea: technology is not just a tool; it’s a driver of change. Businesses introduce new technology to create change—not just for fun or because something is new, but to reach specific goals. Yet oddly, technology can both enable change and block it. Legacy systems, data silos, and outdated platforms often become major barriers. When IT is slow, clunky, or rigid, it stops the rest of the organization from evolving. That’s why Agile isn’t just a process tweak—it’s a response to this very tension, turning IT back into a source of possibility instead of frustration.

Most change efforts fail—and it’s not just about tech
Kelly makes a strong point: most change initiatives fail. And not just in IT—across the board. He cites research showing that up to 70% of change programs don’t succeed. One of the biggest mistakes companies make is treating change as a purely technical challenge. But mandates and top-down orders rarely work with knowledge workers like developers. Change is messy, subtle, and deeply human. If people resist—even quietly—the whole thing can stall. Developers especially are often tasked with building systems that change how others work, yet they rarely consider how disruptive that can be.

Technology benefits unfold in three waves
Kelly introduces three types of benefits that technology brings: automation, process change, and innovation. Automation is doing the same thing faster or cheaper. Process change is rethinking how things get done. Innovation is changing what you do altogether. He illustrates this beautifully with the story of shipping containers—a seemingly boring technology that revolutionized global trade. But the lesson isn’t just about boats and boxes; it’s about how organizations often stop at automation and miss the deeper gains that come from process and innovation. The real payoff comes when you’re willing to reimagine everything, not just do old things faster.

IT people often miss the bigger picture
A recurring theme in the chapter is that IT professionals usually focus on the technical part and miss the broader impact. For them, deployment is the end—but for users, it’s the beginning of the real change. This disconnect creates tension. Users are expected to adjust without support, while developers think they’ve done their job. Kelly suggests that IT teams must start seeing themselves as agents of organizational change, not just builders of software. That means caring about what happens after delivery—not just shipping code.

Why software projects fail—and what we’re missing
The chapter pulls no punches: software projects fail all the time. But it’s often not about bugs or missed deadlines. It’s because the larger change initiative falls apart. Companies may blame the tech, but the real issue could be poor communication, lack of training, or unclear goals. Kelly argues that failing to embed IT within a broader change management plan is a key reason for these failures. It’s not enough to build the thing—you have to bring people along with it.

The problem with fixed requirements
Kelly takes aim at the old idea of “stable requirements.” In reality, requirements change constantly—and that’s a good thing. If requirements change, it means learning is happening. Agile development accepts this by keeping the feedback loop short and allowing requirements to evolve alongside the product. Trying to lock down everything up front creates bureaucracies that slow progress and block learning. Ironically, freezing requirements may reduce development costs but also reduces value, especially if those late-stage ideas are the most innovative or strategic.

Why late requests might be the most valuable ones
In a refreshing twist, Kelly argues that late requirements often come from deeper understanding and richer feedback. These aren’t nuisances—they’re signs that people are learning. He pushes back on the idea that late changes are always bad or too expensive. Instead, he urges us to value flexibility. Real options theory even suggests that keeping decisions open longer increases value. So rather than resisting change, Agile embraces it—and the business benefits.

Learning through change, not before it
The most interesting insight in the chapter is that software development itself triggers learning. By investigating a process to automate it, we force people to reflect on what they do and how they do it. This can change the very problem we thought we were solving. Developers, analysts, and users all learn in the process—and that learning shapes the final product. But that only happens if we stay open to change and keep talking to each other throughout the journey.

This chapter is a wake-up call for IT professionals and businesses alike. Change isn’t a technical phase—it’s a continuous, messy, human process. And software development is deeply tied to that. Agile works not because it’s faster, but because it helps us learn as we go. The challenge is to shift our mindset: from resisting change to enabling it, from freezing requirements to evolving them, and from thinking the job ends at delivery to understanding that’s when the real work begins.

Chapter 7 – Understanding Change

Not all change is the same
Allan Kelly kicks off this chapter by showing that “change” isn’t just one thing—it comes in different forms, with different impacts. At one end of the spectrum, you have routine or transactional change—the everyday stuff that happens smoothly and predictably. At the other end is radical or transformational change, which is disruptive, rare, and often comes with anxiety and resistance. In between, there’s incremental change—smaller steps that aren’t as scary, but still push things forward. The chapter argues that understanding these types of change is key if we want to make our organizations better without constantly triggering chaos.

Why incremental change is often the sweet spot
Incremental change—when done intentionally—can turn into continuous improvement. That’s the goal: learning a bit, changing a bit, repeating. But it’s not without risks. Sometimes it’s too slow, too shallow, or gets stuck. Critics say it can avoid deeper issues. And yet, Kelly argues, it’s still better than waiting until things are so broken that only radical change can fix them. The trick is to make learning and improvement part of the culture, so change becomes normal—not a crisis response.

The limits and dangers of radical change
Kelly doesn’t dismiss radical change—it has its place, especially when the gap between where we are and where we need to be is huge. He dives into Business Process Re-engineering (BPR) as a textbook case of radical, tech-driven change. It promised major leaps forward by redesigning everything from scratch. But BPR often failed because it was too complex, relied heavily on consultants, and ignored the tacit knowledge already embedded in people’s work. The lesson? Sometimes radical change is necessary, but it comes with high stakes—and it needs to move fast to avoid dragging teams into uncertainty and fear.

Routine in software development is rare—and that’s okay
One of the most insightful parts of the chapter is about routines in software development. While routines do exist (like checking email or writing code), real software work is often disrupted by bugs, shifting priorities, or sudden insights. Because of that, Kelly argues, the dream of a “software factory” is a myth. Attempts to over-standardize development kill flexibility and reduce value. Instead of trying to force routine onto a non-routine activity, we should focus on creating routines around learning—like stand-ups, retrospectives, and personal reflection.

Automation as a response to routine
Whenever developers spot a repeatable process, they tend to automate it. That’s a good thing. Tools like source control systems and automated builds free humans to focus on the interesting, creative work. Kelly sees this as a natural evolution: as we understand more, we automate more, and we shift our attention to the unknowns. So, instead of chasing routine for its own sake, we should treat it as a springboard for innovation and improvement.

Continuous improvement isn’t easy—but it’s essential
Agile thrives on continuous improvement. But maintaining momentum is hard. Teams risk either not going fast enough (leading to stagnation) or not going far enough (leading to shallow results). Sometimes change stalls because people think they’re improving when they’re really just tweaking. Other times, real improvement requires unlearning—letting go of old habits that once worked but no longer serve. This kind of deep change often feels risky because it challenges what we think we know.

Change doesn’t happen in a vacuum
Kelly reminds us that change can come from inside or outside the organization. External shocks—like new competitors or market shifts—may force radical change. Internal initiatives, on the other hand, can steer steady improvement if they’re driven by learning and reflection. The best scenario? Internal, incremental change at a sustainable pace. It builds resilience so that when external change hits, teams are ready.

You don’t have to choose one or the other
While the chapter explores radical vs. incremental change, it ends with an important takeaway: these aren’t always choices. Sometimes we have no say—external pressures or organizational structure decide for us. But where we do have control, we should aim for ongoing learning and steady, meaningful progress. Continuous change is our best shot at avoiding painful overhauls later on.

Chapter 8 – Change Models

Why bother with models?
Allan Kelly begins this chapter by addressing a fair question: why should practitioners care about change models? After all, software teams want practical advice, not theory. But Kelly argues that good models give us a new lens to see reality. They help us spot patterns, understand human behavior during change, and plan our actions better. In short, models don’t give us all the answers—but they help us ask better questions.

Learning and change go hand in hand
This chapter reinforces a core theme of the book: learning and change are essentially the same thing. You haven’t really learned something unless it changes your behavior. Using a simple example—like switching bus routes—Kelly shows how true learning requires action. If we learn something and ignore it, we’re not really learning. This ties back to the danger of single-loop learning (where nothing changes) versus double-loop learning (where beliefs and behaviors evolve).

Lewin’s three-step model
Kurt Lewin’s classic change model—unfreeze, change, refreeze—is simple but powerful. First, shake up the status quo (unfreeze). Then, make the actual change. Finally, solidify the new state (refreeze). While useful for understanding change at a high level, Kelly critiques the final step. In a world of constant change, should we really “refreeze”? Maybe we should just slow down, stabilize, and prepare for more change—rather than pretend it’s over.

Satir’s model: chaos before progress
Virginia Satir’s change model adds emotional depth. When a “foreign element” disrupts the system, people enter a chaotic phase of confusion and anxiety. Only after a “transforming idea” appears does performance begin to recover—and eventually improve. This model helps explain why change feels messy and scary at first. It also shows why we shouldn’t interpret resistance or confusion as failure—it’s just part of the process.

Kotter’s eight-step plan
John Kotter offers a more actionable framework for leading major change. His model includes steps like creating urgency, forming a coalition, developing and communicating a vision, and generating short-term wins. Kelly highlights how this approach forces teams to focus first on the problem—not jump straight to a solution like “let’s adopt Scrum.” Without a clear understanding of what’s broken, change efforts risk becoming hollow or misdirected.

Theory E vs. Theory O
Beer and Nohria’s two types of change—Theory E (economic, top-down, often involving layoffs) and Theory O (organizational, bottom-up, focused on culture)—show that not all change plays by the same rules. Each has its strengths and risks. The challenge is using them wisely without sending mixed messages. You can’t talk about caring for people while cutting jobs the next day—at least not without losing trust.

Appreciative Inquiry: start from what’s good
Instead of always starting with what’s broken, Appreciative Inquiry (AI) encourages us to look at what’s working and build on it. Kelly argues that this mindset shift boosts energy, engagement, and learning. It’s not about ignoring problems—it’s about avoiding the burnout and defensiveness that come from constant negativity. Teams that celebrate strengths are often more open to change than teams stuck in problem-solving mode.

Push vs. pull motivators
People change either because they’re pushed (fear, threats, problems) or pulled (aspiration, vision, opportunity). Push can create urgency, but it also sparks defensiveness and fear. Pull creates more sustainable momentum, though it can sometimes lead to complacency. The ideal is a balance—use push when needed, but let pull do most of the heavy lifting over time.

Success and failure are stories we tell
One of the most thought-provoking ideas in the chapter is that success and failure are often constructed. One team may see a project as a triumph; management may call it a disaster. Without shared understanding, people draw different lessons—and make different decisions next time. Kelly emphasizes that teams must talk openly about what happened, what worked, and what didn’t, to truly learn and grow together.

Removing blocks, not just motivating change
Often, people aren’t resisting change—they’re blocked. Kelly shares examples of organizational, physical, personal, and mental blocks that stop progress. Sometimes, developers blame management for something that isn’t even a real restriction. A huge part of change leadership is simply identifying and removing these invisible barriers. And just as importantly—don’t use fear. Fear kills learning.

When not to change
Finally, Kelly acknowledges that not every project is the right place for experimentation. High-risk environments (like life-critical systems) may not allow much room for failure. But that doesn’t mean teams can’t learn elsewhere—like in simulations, training, or side projects. Change is important, but so is timing and context.

This chapter is packed with practical wisdom and models that help us navigate the messy reality of change. From emotional journeys to strategic steps, from fear-based motivation to aspiration-driven growth, it provides a toolbox for anyone trying to lead or support change in software teams. The key message? Learning drives change—but only if we create the space for it to happen.

Chapter 9 – Making Change Happen

Creating change isn’t a passive process
In this chapter, Kelly shifts from theory to practice, focusing on how you can actually bring about change in your organization. He stresses that while learning drives change, it’s not enough just to understand what needs to change—you have to take action. The key message is that change isn’t something that happens on its own; it requires intentional effort, focus, and leadership. The chapter serves as an introduction to practical strategies for leading change, but Kelly warns that there’s no one-size-fits-all answer. Each individual and organization must chart their own course for change.

Building a case for change
The first step in making change happen is building a case for why it’s needed. Kelly argues that change, especially radical change, doesn’t happen on its own—it requires understanding the problem deeply. This means digging into the forces behind the need for change. It’s not enough to start with a solution like “we need to go Agile”; you have to work backwards and understand what problem or opportunity the solution addresses. This ensures that the solution is both valid and necessary. Additionally, being clear on the problems helps make a stronger case when you present it to others.

Understanding and communicating the problem
Once you’ve identified the problem, it’s crucial to communicate it effectively to others. Kelly emphasizes that you need to engage the right people—those who have the power to sanction change, those who will be affected by it, and everyone in between. He highlights the power of storytelling as a tool for explaining the need for change. People connect with stories far more than they do with statistics or dry facts. So, sharing success stories within the organization can help build momentum and support for the change initiative.

Creating the time and space for change
Kelly introduces the concept of “slack”—the time and physical space necessary for change to happen. He argues that organizations need to prioritize time for learning, experimentation, and reflection. Without slack, employees will fall back into old routines and resist change, even if they know it’s beneficial. Change often feels slower at first, especially when new techniques are introduced, but Kelly stresses the importance of allowing time for this initial learning curve. When people are constantly under pressure to meet deadlines, they’re more likely to stick to what they know and avoid trying new approaches.

Leading the change
Leadership is central to change, but it’s not just about authority—it’s about legitimacy. Kelly suggests that leaders must demonstrate the behaviors they want to see in others. If leaders say they want to adopt new practices but don’t follow them themselves, their message will ring hollow. Real leadership comes from modeling the changes you want to see, which encourages others to follow suit. Kelly also points out that leadership is not confined to managers—it can come from anyone who is passionate about the change and willing to take action.

Creating awareness of the problem and opportunity
Sometimes, others may not even see the problem or opportunity you’ve identified. Before you can implement change, you need to help others see what you see. This could mean addressing problems that people have overlooked or pointing out opportunities for improvement. Kelly warns against overloading people with problems but encourages a balanced approach that highlights both problems and opportunities. By presenting change as an opportunity rather than just a fix for problems, you increase the likelihood that others will be receptive to it.

Feedback loops and barriers
Feedback is a crucial part of the change process. Short feedback loops—where people quickly see the results of their actions—are more effective than long ones. These loops help create awareness of problems and reinforce learning. Kelly emphasizes that feedback doesn’t just come from formal metrics or systems; it can also come from personal communication or informal channels. Additionally, barriers to change must be identified and removed. Some barriers are easy to see, but others are hidden within organizational culture or people’s mindsets. Removing these barriers is essential for progress.

Focusing the team on action
Once the problem is understood and feedback is in place, Kelly discusses the importance of focusing the team on what needs to be done. This requires clear communication, structured conversations, and breaking down large problems into manageable tasks. Whether the team is large or small, it’s important to focus on the solution rather than getting stuck in analysis paralysis. The team must agree on the actions to take and prioritize them effectively.

Kelly concludes by reiterating that leading change requires action, focus, and communication. It’s not enough to simply recognize a problem or have the right solution—you must focus the team, remove obstacles, and ensure that everyone is engaged in the process. Change is a continuous effort, and by building awareness, creating feedback loops, and leading by example, you can make meaningful, lasting change happen.

Chapter 10 – Individuals and Empowerment

Change is personal
This chapter opens with a powerful reminder: all change begins and ends with people. No matter how solid the process, tool, or plan may be, every change initiative ultimately hinges on the individuals involved. Allan Kelly highlights that each person has their own fears, passions, and experiences—and even when the same people are involved in different moments, they’re never quite the same. Because of this, there are no guaranteed techniques for managing change. What works once may not work again. But there are patterns and principles that can guide us, and respecting people as individuals is where it all starts.

People aren’t blocks—they’re the solution
Too often, organizations treat people as obstacles to change. Kelly warns this mindset quickly becomes a self-fulfilling prophecy: if we expect resistance, we’ll get it. Instead, we should involve people early, listen to their views, and see them as contributors. Motivation is key. Developers want to do a good job, complete meaningful work, and keep learning. When we give them opportunities to do all three, we unlock their energy and commitment. The message is clear: if we want change to happen, we need to work with people, not push against them.

Listening is leadership
Kelly emphasizes that leading change isn’t about giving orders—it’s about listening. Real listening takes time, patience, and attention. It means truly hearing concerns, not just waiting for your turn to speak. By asking for opinions—especially in one-on-one settings—we uncover insights, show respect, and build trust. These moments are often more impactful than big group meetings. Listening also allows us to identify mental blocks—those internal stories people tell themselves, like “It won’t work here.” By surfacing and questioning those assumptions, we help people shift their mindset and open up to change.

Coaching: guiding, not controlling
The chapter then explores coaching as a tool for change. Agile coaches often guide teams in adopting practices like test-driven development, but Kelly explains there’s more than one type of coaching. Directive coaching shares expert advice; non-directive coaching helps people find their own path. Both are valuable. The non-directive approach, in particular, encourages people to think deeply, build confidence, and solve future problems independently. It’s not about giving answers—it’s about helping people grow.

Empowerment means giving up control
Real empowerment isn’t just a buzzword—it means giving people actual authority and trusting them to act. That also means leaders have to step back, make time to listen, and resist the urge to take over. Empowerment encourages more brains to work on the problem, and when people help create a solution, they’re more invested in making it happen. It’s not about being hands-off—it’s about being supportive, asking good questions, and helping others succeed, even if their approach is different from your own.

Letting go and letting others lead
Kelly explores how empowerment applies not only to individuals but to teams. Empowered teams must have a clear purpose, a shared sense of ownership, and the authority to make decisions. But empowerment takes time—especially in organizations where it hasn’t been the norm. People may hesitate at first, unsure if the offer of autonomy is real. Leaders need to show consistency, patience, and follow-through if they want people to truly believe in their own power.

When empowerment creates tension
Empowering people means giving them the choice to act—or not act. But that can lead to conflicts. What if someone’s inaction blocks a team’s progress? Or if different ideas for solving a problem clash? Kelly suggests that in these cases, a neutral arbiter or higher authority may need to step in. Empowerment doesn’t mean chaos—it still needs structure and support to resolve disagreements and keep momentum.

Handling “difficult” individuals
Not everyone will be excited about change. Some will question, resist, or seem obstructive. Kelly urges us to avoid quick labels. These individuals may have valid concerns, see risks others don’t, or simply feel excluded. Instead of fighting them, bring them in. Ask what they’re seeing. Make them part of the process. And if they still can’t align with the change, it might be time for a respectful transition. But this should be the last resort, never the first.

Building leaders for tomorrow
As a change leader, you can’t do everything yourself. You need to develop the next generation of leaders—your lieutenants—who can carry the change forward. Delegating responsibilities, encouraging others to speak up, and giving them room to grow ensures that change survives beyond your direct influence. The real test of a successful change initiative is whether it continues after you’re gone.

Knowing when to step away
Kelly closes the chapter with an honest reflection: sometimes the best thing a change leader can do is leave. Whether because the initiative is complete, you’ve run out of energy, or you’ve become a bottleneck yourself—there are times when moving on enables the team to keep growing. The goal is not to lead forever, but to make yourself unnecessary.

This chapter is about trust, humility, and the human side of change. You can’t force people to change, but you can empower them, support them, and create an environment where change is possible. By doing so, you build stronger individuals, stronger teams—and ultimately, stronger organizations.

Chapter 11 – Rehearsing Tomorrow

Plans are useless, but planning is indispensable
This chapter opens with a striking quote from Eisenhower—and it captures the essence of Kelly’s message. We can’t rely on plans alone because the future is uncertain, but planning helps us think, learn, and prepare for action. The point isn’t to predict the future perfectly; it’s to shape our responses and stretch our ability to adapt. This chapter is all about how individuals and teams can “rehearse” change—like actors or musicians—so when real change comes, they’re ready for it.

Creating future memories
Kelly introduces the idea of “future memories,” inspired by Arie de Geus. Our brains are always running simulations about what might happen next. In teams, we need shared mental models of the future—shared expectations of how we’ll act when things change. If we don’t take time to build these as a group, we fall back on our individual experiences, and that can lead to confusion or friction when someone acts differently. So, rehearsing isn’t about guessing the future—it’s about building collective readiness and resilience.

Planning as a learning exercise
Planning isn’t just about schedules and Gantt charts. Kelly reframes it as a learning tool. From initial concepts to design discussions, every step of software development involves forming and refining mental models. But he also warns about the dark side of planning: when plans become rigid, when estimates are manipulated, or when planning is used to control rather than guide. These patterns kill learning, motivation, and flexibility. Planning should be collaborative and dynamic—not a trap that locks teams into outdated expectations.

Scenarios, not predictions
Kelly explores scenario planning as a powerful tool for preparing teams for different futures. This doesn’t mean forecasting exact outcomes but imagining a range of possibilities. That way, when something unexpected happens, the team isn’t caught off guard—they’ve already rehearsed similar situations. It’s about building options and responses, not just strategies. Scenario planning helps teams create more thoughtful software designs and uncover hidden assumptions early on.

Events that trigger and support change
Beyond planning, Kelly introduces several change events that organizations can use to rehearse and experiment with new ways of working:

• Improvement meetings: Focused discussions to generate shared understanding and actionable ideas.
• Improvement worksheets: Structured questions that prompt reflection and track progress over time.
• Process miniatures: Simulations of a development cycle (like a “59 Minute Scrum”) to help teams experience change in a safe environment.
• Retrospectives: Regular team reviews to reflect, learn, and improve.
• Workouts (from GE): Intensive, cross-functional problem-solving sessions that lead to fast decisions and empowered solutions.
• Kaizen and Kaikaku: From Lean thinking—Kaizen for continuous improvement, Kaikaku for deep, transformational change.

These events help shift teams from passive recipients of change to active participants in it. They build confidence, uncover blockers, and reinforce the habit of experimentation.

Bringing in outsiders wisely
Sometimes, external support can help accelerate learning. Kelly walks through the roles of consultants, trainers, facilitators, and coaches. Each brings value in different ways—by introducing new ideas, providing outside perspective, or guiding discussions. But they’re not a substitute for internal ownership. Consultants can seed learning, but the team must sustain it. Training can spark interest, but hands-on experience is where real understanding forms. And facilitators or coaches can unlock deep insight—especially when trust and safety are needed.

This chapter ties together many of the book’s themes: learning, experimentation, reflection, and change. The takeaway? If we want to be ready for tomorrow, we can’t just analyze or plan—we need to rehearse, to experiment, to involve others, and to act. We need tools and rituals that help teams build shared understanding of the future—not just what might happen, but what they’ll do when it does.

Chapter 12 – New Beginnings

The problem isn’t always unwillingness—it’s unawareness
The chapter begins with a thoughtful metaphor from Winnie the Pooh: sometimes we keep “bumping down the stairs” simply because we don’t know there’s another way. Allan Kelly uses this to highlight a central problem in many organizations: it’s not that people don’t want things to improve—it’s that they don’t know how things could be better. We’re often too busy doing the work to step back and rethink how we’re doing it. That’s where Agile—and learning—come in. This book has aimed to show how we can shift from how things are to how they could be, without needing to hit pause on everything.

Bottom-up change beats waiting for permission
Kelly reinforces that the most powerful change doesn’t always come from the top. In fact, most of this book has focused on bottom-up change—what happens when the people doing the work decide to improve how they work. Waiting for management to fix things is often just an excuse for inaction. Instead, use what you already have: your knowledge, your imagination, and your immediate circle of influence. You may not solve every problem, but you can always do something—and even small wins matter.

Start with yourself
True change begins with personal action. Kelly offers clear, humble advice: read more, experiment with new behaviors, ask for feedback, start a book group, or simply listen better. Don’t wait for permission. But he also includes some cautions: change is uncomfortable, people may resist your efforts, and not everything will succeed. That’s okay. What matters is learning, adjusting, and persisting. Don’t be discouraged by setbacks—use them to improve.

Be legitimate, but don’t wait for a formal invitation
Before diving into change initiatives, ask yourself if you have the legitimacy to act. Were you asked to do this? Does it align with your goals or responsibilities? Acting without support can create trouble, but sometimes it’s okay to stir things up—especially if it sparks productive conversations. Just remember: nobody gives you power. Sometimes, you have to take it.

You can’t change alone forever
Leading change can be lonely. At first, you may be the only one who sees the need. That’s why it’s essential to find allies and supporters—people who share your vision, encourage you, and help carry the load. Over time, you must also let others lead. If you’re doing everything yourself, you’re not spreading change—you’re bottlenecking it. Sustainable change needs a team.

Grow your influence from the inside out
Kelly brings in Stephen Covey’s concept of circles of concern and influence. We all care about many things, but we can only act on a few. The key is to start with what you can control, succeed there, and let that success grow your reputation and reach. Over time, your circle of influence expands. It’s tempting to focus on big problems, but often it’s smarter to pick small battles you can win and build from there.

Learning is the engine—nurture it
Making change happen means creating a culture of learning. That includes planting seeds (creating spaces for people to talk and reflect), removing barriers (like lack of time or tools), and turning learning into action. Just as importantly, turn action back into learning. Every experiment, success, or failure offers insight that can fuel more improvement.

Avoid the buzzwords—speak plainly and act boldly
Kelly urges caution with jargon. Terms like “learning organization” or “change agent” might make sense in books, but in daily work, they often create distance. Don’t talk about “transformation” or “continuous improvement”—just do it. Show people the benefits of small actions. Create change by example, not by language.

Have a vision—but expect it to evolve
If you’re not sure where to start, imagine a better version of your current work environment. Picture how it could feel to be in that space. Then start mapping a plan—pick something simple to try, test it, and build from there. The gap between where you are and where you want to be will guide your next steps. Your plan doesn’t have to be perfect, and it will likely change—but the act of planning itself is what prepares you to take real action.

The three pillars: better, connected, continuous
At the core of Kelly’s approach are three interconnected ideas:

1. The drive to do better – Never settle. Improvement is always possible.
2. Systems thinking – Understand how parts fit together, not just how they perform individually.
3. Continual change – Fix what you can now, then keep going.

These three ideas form a self-reinforcing loop. They help teams improve incrementally while still keeping an eye on the big picture.

Change never ends—but that’s the point
In closing, Kelly reminds us that change isn’t a destination. It’s a journey that never really ends because learning never stops. That’s both the challenge and the opportunity. You’ll always find new problems, new ideas, and new ways to grow. Celebrate the wins—but don’t get stuck in celebration. The next opportunity to learn is already on the horizon.

So… what now?
Kelly ends with a gentle but clear call to action: start today. Talk to your colleagues. Reflect on what needs to improve. Try something small. Don’t wait for a grand initiative or perfect moment. Real change starts with learning—and that starts with you.

4 Key Ideas from Changing Software Development

6 Main Lessons from Changing Software Development

My Book Highlights & Quotes

In the longer term, it is about making your team into a learning team, capable of learning, changing, and improving itself. Such teams are true Agile teams

Conclusion

Reading Changing Software Development isn’t just about learning how to “do Agile” better. It’s about seeing work—and people—in a new way.

It gives you the language and mindset to build real, meaningful change in your team or organization.

But more than that, it reminds you that you’re allowed to grow, to rethink, and to lead—wherever you are.

And maybe the most powerful part? You don’t need permission to start.

I am incredibly grateful that you have taken the time to read this post.

Support my work by sharing my content with your network using the sharing buttons below.

Want to show your support and appreciation tangibly?

Creating these posts takes time, effort, and lots of coffee—but it’s totally worth it!

If you’d like to show some support and help keep me stay energized for the next one, buying me a virtual coffee is a simple (and friendly!) way to do it.

Do you want to get new content in your Email?

Do you want to explore more?

Check my main categories of content below:

• Book Notes
• Career Development
• Essays
• Explaining
• Leadership
• Lean and Agile
• Management
• Personal Development
• Project Management
• Reading Insights
• Technology

Navigate between the many topics covered in this website:

Agile Agile Coaching Agile Transformation Art Artificial Intelligence Blockchain Books Business Business Tales C-Suite Career Coaching Communication Creativity Culture Cybersecurity Decision Making Design DevOps Digital Transformation Economy Emotional Intelligence ESG Feedback Finance Flow Focus Gaming Generative AI Goals GPT Habits Harvard Health History Innovation Kanban Large Language Models Leadership Lean Learning LeSS Machine Learning Magazine Management Marketing McKinsey Mentorship Metaverse Metrics Mindset Minimalism MIT Motivation Negotiation Networking Neuroscience NFT Ownership Paper Parenting Planning PMBOK PMI PMO Politics Portfolio Management Productivity Products Program Management Project Management Readings Remote Work Risk Management Routines Scrum Self-Improvement Self-Management Sleep Social Media Startups Strategy Team Building Technology Time Management Volunteering Web3 Work

Do you want to check previous Book Notes? Check these from the last couple of weeks:

• Book Notes #127: The Laws of Simplicity by John Maeda2025-04-04
• Book Notes #126: Inevitable by Mike Colias2025-03-24
• Book Notes #125: Revenge of the Tipping Point by Malcolm Gladwell2025-03-21
• Book Notes #124: Radical Candor by Kim Scott2024-09-04
• Book Notes #123: The Personal MBA by Josh Kaufman2024-05-09

Support my work by sharing my content with your network using the sharing buttons below.

Want to show your support tangibly? A virtual coffee is a small but nice way to show your appreciation and give me the extra energy to keep crafting valuable content! Pay me a coffee: