With all the stories I still continue to hear of failed agile implementations (often now called “digital transformations”), it feels like it’s time for an XP revival.

Extreme Programming (or XP) is one of the original agile software development methodologies, and it’s a shame I see it talked about less these days. It was pivotal in shaping agile practices, and crucially, focuses on engineering practices as well as ways of working, which none of the most popular agile methodologies do.

Why didn’t XP take off like Scrum, Kanban or any of the scaled agile frameworks? Two main reasons (my opinion):

1. Unlike the most popular methodologies it was never commercialised or marketed. There are no (highly profitable) training and certification programmes for XP. It’s the garage punk band of Agile!
2. It’s harder. Because of XP’s focus on engineering practices, unlike e.g. Scrum or SAFe, you can’t as easily get away with superficially plonking XP on top of your existing processes and not really change anything.

The second point is why, as often as not, there’s often little meaningful impact with Scrum, or especially the scaled agile frameworks (well, apart from adding a lot of bureaucracy to your processes).

I’m continually hearing of failed scaled agile implementations (often involving lots of very expensive consultants). These stories don’t often go public because, well, you’re hardly going to shout about it, but WalMart is one of them, as I found out from Dave Farley recently. How did they fix it? By focusing on the engineering practices over the process! You can watch Bryan Finster‘s excellent InfoQ presentation on it here.

For me personally, Scrum is OK (I’m not a hater). I prefer Kanban, or even ScrumBan – mixing the two. But XP as well. Following XP does not mean you can’t use or be inspired by other methodologies, but without the XP practises you’ll unlikely get any meaningful improvement.

However I’d argue you don’t need much more than XP in the first place, and it’s as good a place to start as any.

It’s time for an XP revival

I’ve watched as first, Scrum proliferated the industry, and then the scaled agile frameworks come along. They’ve had plenty of time in the sun and there’s enough evidence now indicating that these methods are regularly not delivering on the intended outcome, certainly not on their own, without focusing on the engineering practices as well.

It’s time for the latest generation of development teams to learn about XP. It may be over 25 years old now, but that’s also as long as I’ve been working in tech, and whilst the languages, tooling and platforms have changed markedly in that time, the fundamentals have not.

Appendix: What is XP?

For those not familiar, I’ll try to summarise XP’s Values, Principles and Practices, but I’d recommend getting a copy of Kent Beck’s masterpiece Extreme Programming Explained if you’re keen to learn learn more.

XP Values

• Communication: Clear and frequent interactions within the customer, stakeholders and  team
• Simplicity: Focusing on what is necessary at the moment and avoiding over complication.
• Feedback: Actively seeking feedback to continuously adjust and improve the product and processes.
• Courage: Being bold about making changes, trying new things, and facing challenges directly.
• Respect: Valuing team members’ contributions and creating a supportive environment for all.

XP Principles

• Humanity: Acknowledging the human aspect in software development, emphasising respect, understanding, and communication among team members.
• Economics: The need to consider the economic impact of decisions made during the development process, optimising people, resources and return on investment.
• Mutual Benefit: Encouraging practices and decisions that are beneficial for all stakeholders involved, fostering a win-win environment.
• Self-Similarity: The principles and practices of XP should be applied at all scales of the project, from the smallest code block to the entire development process.
• Improvement: Advocate for continuous improvement of the process, code, and team dynamics, always seeking ways to do better.
• Diversity: the value of having a diverse team with varied perspectives and skills to tackle complex problems creatively.
• Reflection: The importance of regular reflection on practices, progress, and problems to learn and adapt.
• Flow: Aim for a steady and continuous flow of work, minimising disruptions and maximising efficiency.
• Opportunity: Encourage viewing challenges and changes as opportunities for growth and improvement rather than obstacles.
• Redundancy: The value of having some redundancy in skills and knowledge within the team to enhance resilience and flexibility.
• Failure: Acknowledging failure as a natural part of the learning process, encouraging a positive attitude towards learning from mistakes.
• Quality: Placing a strong emphasis on the non-negotiable importance of quality in all aspects of software development.
• Baby Steps: Advocate for making small, incremental changes to manage risk and facilitate easier integration and testing.
• Accepted Responsibility: Responsibilities should be accepted voluntarily by team members, fostering ownership and commitment.

Core XP Practices

• Sit Together: Promote team collaboration and communication by working in the same space.
• Whole Team: Everyone who’s needed for the success of the project is a part of the team.
• Informative Workspace: Create a work environment that visually communicates the team’s progress and status.
• Energised Work: Encourage working only as many hours as you can be productive and no more.
• Pair Programming: Two programmers work together at one computer, enhancing code quality and knowledge sharing (add mob or ensemble programming these days).
• Stories: Use of customer-defined user stories to guide development and ensure the product meets needs.
• Weekly Cycle: Planning, development, and delivery cycles on a weekly basis to adapt to changes quickly.
• Quarterly Cycle: Long-term planning sessions that set the direction for the next three months.
• Slack: Incorporating extra time into schedules to account for the unexpected and foster creativity.
• Ten-Minute Build: Keeping the build process short to encourage frequent integration and testing.
• Continuous Integration: Regularly merging all developers’ working copies to the shared mainline several times a day (add Continuous Delivery these days).
• Test-First Programming: Writing tests before code to clarify the requirements and ensure correct behaviour.
• Incremental Design: Evolving the design over time as the system grows and changes, instead of doing all design upfront.

Your regular reminder that Spotify don’t use the Spotify model, they never really did.

Don’t attempt to blindly copy practices from other organisations. Especially not big tech like Google, Netflix, Spotify, Facebook etc.

You’ll most likely just end up cargo culting if you do – going through the motions without real benefits.

Especially don’t simply try and graft “Tribes”, “Squads”, “Guilds” and “Chapters” onto your existing organisational structure. The original content on the model was about a lot more than team structures. But this is normally the only thing that orgs adopt.

Frameworks and models are appealing as they feel like a shortcut, but they usually miss the nuances of your specific challenges.

Be inspired, but don’t copy.

I regularly encounter start-ups and organisations who’ve built things they didn’t need to, when there are many readily available platforms they could have used instead.

A key principle of doing less, better and being able to stay small, is to only build what’s unique to your proposition.

Creating software can be like buying a pet – it’s a big commitment. It’s not just about building it; you also have to care for it constantly. This includes making sure it stays safe, up-to-date, and working smoothly – much like tending to a garden to prevent it from becoming overgrown (and why, with 3 young kids, there’s not much more than grass in mine 😅).

Here’s some examples of common system components, where numerous platforms exist which you can use instead of building them yourself 👇

📄 Content Management
🆔 Identity & Login
🛒 eCommerce
💳 Payments
🗨️ Social features
⚙️ Admin panels
🔍 Search

While these platforms aren’t free, they’re often far more cost-effective than building and maintaining your own. They also have modular components and integrate via APIs and SDKs, allowing you to maintain control over the unique aspects of your service.

And unless you’re in the business of providing one of these platforms, they’ll also do it better than you.

Trade offs? There will be limits to what the platforms can do, you’ll be beholden to their roadmap and costs can rise significantly at scale. However, it’s typically quicker and cheaper to start with using common platforms and only consider building something yourself when you can really justify it.

Before adding any new feature to your product, first check if there’s an existing solution that eliminates the need to build it yourself 👀

The answer is probably not.

Many jump in too quickly before nailing down the problem they’re solving.

You have an idea, have you defined your proposition? Who are your users? What problems are you going to solve for them? What’s your value proposition? Is anyone going to pay for it? How have you validated any of this so far?

Somewhat ironically as a technologist, I spend a lot of my time advising people not to build things… yet.

It’s crucial to validate as much as possible around your assumptions and your users, first.

What’s the best way to do this? Speak 🗣️ to your potential customers! Do user research, surveys, and market studies 📊. Use tools like Marvel or Figma for quick and easy prototyping.

Remember, this is all quick and relatively cheap (unlike building software!)

Even then, you may /still/ not need to build something yet. Laura Pomfret (Financielle) 💸 and Holly Holland (Financielle), the co-founders of Financielle are a great example. They started with a WhatsApp group, selling PDF guides and spreadsheet templates to help women take back control of money. The Airbnb founders started by renting out air mattresses in their living room!

Before considering building something for real, ask yourself: Have I really validated enough? It could save you more than just time and money.

Of all the “agile” practices, Retrospectives are the only one I advise ALL teams should be doing regularly. Why? It’s the most effective way to figure out what works best for your team and to ensure you’re continually evolving and improving the way you work.

I love them so much I built the Agile Retrospective Wiki! Still going strong with thousands of visitors from across the globe every week 😊 (link in the comments 👇)

However, too often, retros aren’t much more than “improvement theatre” Chris Parsons (edit) – transactional, energy draining and nothing changes as a result of them.

Anyway, here’s my guide 👀

📚 Facilitation is a skill

Ensuring meetings are not being driven by whoever shouts the loudest, or ending up as a long ineffectual debate takes thought and practice.

Facilitation is an art. The first three chapters of Derby and Larson’s book, “Agile Retrospectives: Making Good Teams Great,” is a must read IMO.


🔄 Rotate the facilitator

It’s common to be one person’s role to lead retros. This is the best way to make sure they stagnate! It prevents teams from feeling engaged and empowered to solve their own problems, and risks bias to one persons’ agenda. Whilst it may be one role’s job to make sure they happen, that doesn’t mean they have to run them all.

Get everyone to take turns facilitating.


✅ Achievable actions, clear ownership and tracking

Common failings 😥
– Not taking any actions
– Taking on too many actions
– Actions that are too big or vague
– Not following up on actions

Do this instead 😃
– Make actions small and precise (see SMART)
– Ensure actions have owners
– Track the actions just like any other work (e.g. on your work tracking tool).
– At the start of the next retrospective, review outstanding actions


🖖 Embrace “The Prime Directive”

You don’t have to remind people at the start of every retro, but this has to be front of mind, to set the right tone:

“Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”
–Norm Kerth, Project Retrospectives: A Handbook for Team Review


🎲 Mix it up! Try different retrospective plans

Doing the “Start, stop, continue” retro every time? 🥱 Try something different! The Agile Retrospective Wiki is full of different plans you can try (other sources are available!)

If you’re an early stage startup thinking you need to hire a CTO, what you probably really need is a “Founding Engineer”*. Startups have a tendency to over-inflate titles. While a fancy title might seem appealing, it’s important to prioritise the actual needs and growth stage of your startup.

What’s the Difference? 🔍

– Founding Engineer: A dynamic, hands-on developer, driving your product development, adept at turning ideas into tangible, market-ready realities and shipping at pace.
– CTO: A strategic executive-level role. Aligns technology with business goals, demonstrates commercial acumen, brings extensive leadership experience, and shapes key strategic decisions to enable sustained growth.

Why Start with a Founding Engineer? 🏗

– Immediate Needs: Early-stage startups need to focus on product development.
– Budget-Friendly: You typically cannot afford, or justify an experienced full-time CTO (consider a part-time or fractional CTO instead 😉)
– Flexibility: Calling someone a CTO when that’s not really what they are could cause problems down the line (e.g. when you do actually want to hire a proper CTO).

What to Look for in a Founding Engineer 👀

– Full Stack Expertise: Versatile in both front-end and back-end development, capable of handling a broad range of technical tasks.
– Experience: They’re seasoned, they’ve walked the walk. They have a proven track record (e.g. as a senior or lead developer)
– Adaptability and Problem-Solving: Comfortable with ambiguity, able to adapt to change quickly.
– Strong Communication Skills: Effective in articulating technical concepts and collaborating with both technical and non-technical team members.
– Entrepreneurial Mindset: A self-starter with a strong sense of ownership, driven to build and innovate in a startup environment.
– Cultural Fit and Resilience: Aligned with the startup’s values and culture, and resilient under the high-pressure, fast-paced startup conditions.
-Growth potential: Many Founding Engineers can (with the right support) evolve into CTOs as the startup matures and the need for strategic tech leadership increases.

I was reminded of this after our panel talk @ hashtag#dtxmcr23 yesterday, when someone spoke to me afterwards who’s accountable for the digital workplace strategy at his org.

The great thing about paper, pens, spreadsheets and WhatsApp groups is they’re ultra flexible and the technology works for /you/.

If you have a broken process, invariably, adding more technology makes the situation /worse/. Why? Because you’ve now sealed the process in concrete and making changes is 10x harder (and more expensive). Your users are now beholden to the technology. You’ve probably not made their lives better, or their work more efficient.

Where do you start? I fell in love with Service Design (see comments for Wikipedia link), after seeing folks like Katherine Wastell, Kathryn Grace and Elisse Jones use it at the Co-op. Start by mapping your end to end process – people, systems, tools, workspace – and identify the pain points.

When you do this, more often than not, you find technology is /not/ the answer to the biggest problems.

And if you do choose to add new tech into the mix, you’re doing so with a much better understand of why and what problem it’s going to solve.

To me, that’s the heart of Digital Transformation.

n Agile circles we talk a lot about autonomy, and good teams being autonomous. However, there’s a common misconception. No team is ever fully autonomous. No team lives in a vacuum.

Autonomy needs boundaries to be effective.

Look at a top-flight football team, where high performance is essential. They need to be empowered to self-organise, so they can adapt to what the opposition is doing.

But their autonomy has clear boundaries – how many players you can have on the pitch, the playing area and many other rules. Without them it would be more like the Royal Shrovetide Football game, an early form of football dating back to the 12th century which is basically just a massive fight (the main rule is, somewhat bluntly, no killing).

A team is an example of a complex adaptive system. Every successful complex adaptive system is bound by rules, even in nature. A flock of birds works on 3 simple rules, allowing them to self-organise, avoid crashing into each other and leading to mesmerising patterns like murmurations of starlings.

To enable autonomy, it’s important for teams to have clarity about what they’re responsible for and the boundaries around what they can make decisions on.

Defining boundaries is a delicate act. Overly rigid and you can inadvertently limit the very autonomy you aim to foster. Too much leeway can lead to misalignment and inefficiencies. The goal is to offer enough structure, while preserving the space for creativity.

Like a conductor with an orchestra 🎻: set the tempo 🎵, but let the musicians shine ✨

Your proposition might be bleeding edge, your tech doesn’t need to be. Go with well-known, battle-tested technology.

Both start-ups and established orgs frequently fall into the trap of chasing the latest trends and opting for cutting-edge technology. More often than not, they later find themselves burdened with complex stacks that are not fit for purpose and hard to maintain.

Here’s the thing: unless you’re operating at a mega scale or working in a very specific niche, you can accomplish nearly everything you need with tech that’s been popular for decades. The benefit? They’re well-known, well-supported, and it’s easier to find engineers who are familiar with them.

🚨 The Trade-off Trap 🪤
When assessing new tech, many developers overlook the trade-offs. They get caught up in the allure of the problems the new tech will solve, without understanding the new ones it might introduce.

🚨 The Re-write Trap 🕸️
When the opportunity to re-write something arises, the temptation to choose shiny new tech is strong. However, more often than not, the tech stack wasn’t the core issue. The main reasons are typically out of support frameworks and languages, and an architecture and codebase that have become too complex to maintain. By opting for unfamiliar tech, you risk complicating your re-write even further. 🚧

Common examples 🔍
– Choosing NoSQL databases over traditional relational databases
– Overcommitting to a microservices architecture
– Going all-in with a serverless architecture like AWS Lambda
– Opting for GraphQL over more traditional REST-like APIs
– Dare I even begin when it comes to front end web frameworks 🥺

While all these choices have their merits, they are best suited for specific use cases and you need to know what they are.

Innovation 💡 in your product or service is where your focus should be, not in the technology that supports it. By choosing reliable, common technology, orgs can avoid unnecessary complexity, freeing up more time and resources for what really matters: solving real-world problems and growing their business.

It may seem paradoxical, but you often get more done by doing less, better.

Delivery slow 🐢? Expectations and deadlines regularly being missed 📅? All too often it’s because teams are just trying to do too much at the same time.

Think of a congested motorway, frequently caused by nothing more than too many vehicles trying to go too fast. Smart motorways solve this by reducing the speed limit, meaning everyone gets where they’re going more quickly.

Larger organisations trying to do too much can be very inefficient, further exacerbated by dependencies between teams and complex org structures creating competing initiatives, akin to a city gridlocked at rush hour.

Why better as well as less? You didn’t plan for misunderstanding requirements, didn’t plan for code becoming more complex and harder to change, didn’t plan to fail QA, didn’t plan for it to break something in production.

These are all things more likely to happen when you’re juggling too much work at the same time (and they all slow you down), but won’t necessarily improve by just doing less. If you’ve been working this way, bad practices are probably baked in culturally.

📉 Doing less 📉

⚠️ Reduce and limit the amount of work in progress at any one time (see WIP limits)
🔪 Break work down into the smallest possible deliverables
✅ Focus on getting things done before picking up new work

🌟 Doing less, better 🌟

🎯 Ruthless prioritisation to ensure you’re always focusing on the work that will have the most impact
🤝 Make sure outcomes and requirements are clear and agreed before you start new work
👩‍👩‍👦‍👦 Take collective ownership and work as a team rather than passing tasks between silo’s
🔧 For engineers, focus on writing maintainable and well unit tested code, so it’s easy to change and reduces the likelihood of introducing bugs.

What practices have you found help create better focus, streamline delivery and get more done as a consequence?