No matter how good we are today, there is some way in which we could be better. Let's consider how...

My first exposure to anything Agile was with eXtreme Programming (XP) back in 1999. While it had many process steps similar to what Scrum and Kanban offer today, the thing that really differentiated XP was it’s focus on technical practices. It’s those technical practices that we are usually referring to when we talk about XP today.

Yet, the practices themselves weren’t intended to be end-states. They were merely the best practices that we knew about at the time, and today we know about a number that are even better. Continuous delivery and ensemble/mob programming weren’t even a thing at that time and yet they’re both completely in line with what XP advocates.

The really important thing about XP is really in understanding where the “extreme” in the name comes from. The basic idea is that if we believe that a practice or approach is good then instead of doing it a little bit, let’s turn it up to extreme levels and do it all the time.

When we introduce some of these practices today, we often get push-back on the specific practices, while missing the intention behind it. If you don’t like the specific practice that we’re doing, then find a different way to turn the good up to extreme levels.

XP is “extreme” because it doesn’t settle for “good enough”. That seems like a positive to me.

Since we’re talking about the XP technical practices, let’s look at the business value from them. From my perspective, the business case for all the technical practices boils down to two main things:

As a secondary benefit, both of these combine to lower risk. When we get better feedback, sooner, we are able to make directional changes that lower risk. When the quality is high, there is less risk of things going wrong.

Why might we want to use Test Driven Development (TDD)? Its focus on design results in a higher quality product. It also encourages smaller, more granular, automated tests which will provide faster and better feedback.

Why might we want to aggressively refactor the code? It results in higher quality.

Why might we want to have multiple people working together in pairs on an ensemble? Higher quality. Faster and better feedback.

Why might we want to continually integrate the code? How about releasing frequently? Faster and better feedback.

So if you’re asking yourself whether you need the agile technical practices, ask instead whether you need faster, more actionable, feedback and high quality. If you don’t care about those things then no, you don’t need any of this.

If you do care about being able to make better and more timely decisions and do want to deliver high quality solutions to your customers, then it’s time to focus on improving your technical practices.

For more information on anything I normally discuss or you'd like to know how to reach out to me, then see my follow up page. I offer training and consulting services around all of the things I discuss here and would be happy to help your organization.

Also, if there's something you would like to see in this newsletter or would like me to share insights on, feel free to reply to this email, and I'll see what I can do. 

Was this newsletter forwarded to you and you'd like to sign up for your own copy? Sign up here.

Reminder that all your products, including Flow Metrics Basics can always be found here.

Mike Bowler