Joining Spotify


Well, after a whirlwind summer, I can proudly announce I have joined Spotify as an Agile Coach here in Stockholm Sweden. I just completed my first week, and before entering bootcamp I wanted to share some thoughts, observations, and comments from week one.

Surface observations

Spotify, for those of you who don’t know, is a music streaming company founded in 2006 which today has about 40M active users and 10M paying customers.

The best way to think about what they do is to imagine having access to all of iTunes for free. You don’t download the songs. They are streamed to you in real time on whatever device you happen to be listening. Then for $10/month you can get rid of the occasional add – this is called the premium service. Spotify competes with Google and Apple in the music service industry.

Being a music tech company Spotify has some pretty incredible engineering talent. They have music players, iOS/Android clients, embedded hardware in speaker systems, not to mention some enormous scaling issues for when it comes to streaming music to people anywhere, anytime around the world. Very strong engineering.

They are also the most mature Agile shop I have ever had the chance of working with. They have been innovating in the Agile space for some time. Most of their challenges are organizational. Like how do we scale this thing.

For a good video on Agile at Spotify watch this.


This being Sweden, there is a strong culture of building consensus (similar to Japan). But different also in that there very little formal hierarchy. Spotify stress autonomy, and empowerment at a level I have never seen before in a company of it’s size. Every team here truly is a startup and empowered (and expected) to make their own decisions and follow through.

So overall, a very high-level of self awareness, a great deal of maturity, but an understanding that they haven’t got it all figured out (despite the number of daily tours and requests they give to other companies visiting the office, and asking them how they do it). They answer of course is there is no one way – this just happens to be the Spotify way.

Great challenges

Working here is also like having a front row seat to one of the greatest battles our industry is going to see – who is going to dominate music. Going up against the likes of Google and Apple is no small thing. And Spotify is well aware of the challenges they face.

Organizational scaling, reduced friction, iterating fast, and discovering the future before others have real meaning here. There are going to be some real challenges. And I feel very fortunate to be a part of that.

Coming soon

For my friends and family back in Canada stay tuned. Spotify is coming! There were some regulations from the Canadian government that needed to be sorted out before Spotify could launch, that that being complete Spotify should show up sometime I hope this year.

So stay tuned. Sign up. And listen to the music.

Cheers – Jonathan


CEO Daniel EK Charlie Rose Interview

Personal blog of family life in Sweden

Where did all the developers go?


I am noticing a trend at Agile conferences. Fewer and fewer developers are showing up.

I guess I’ve noticed this for a number of years, but it really hit home recently at at a small American conference when someone commented on the lack of developer focused sessions, to which one of the organizers said: “We would add them except the developers never show up!”

What! I thought. That doesn’t make any sense.

Agile started with developers.
Developers (the ones I used to know) loved Agile.
Agile is software. How can you talk Agile without involving the people who create it?

So developers. Why aren’t we showing up at Agile conferences anymore?

Is it because we’ve been hijacked by Scrum professionals, certification wonks, vendors, and other ‘professionals’ who do everything but deliver software?

Is it because the Agile brand has become so diluted and meaningless that it doesn’t stand up for the things it once did? Like writing kick ass software and making customers happy?

Or is it because there has been no really innovations in Agile over the last 10 years and instead of catching up, everyone is falling backwards reverting to 30 day waterfall sprints under the umbrella of Scrum.

And to everyone else, does this even matter.

Does it matter that the people creating the software are no longer at the table?
Are Agile conferences no longer the best place to talk about innovating software?
And where will the next revolution in software delivery come from?

Where have the developers gone? Do we need them? And will they ever come back.

Update: Further comments can be found here on Hacker News.

Some Inconvenient Truths About Software


An essay for managers and executives who are not in the business of software, but rely on it’s in creation for their business’s success.

Software isn’t like conventional project work. It’s invisible. You can’t see it. You can’t touch it. And you sure as heck can’t measure it (at least by conventional means). Yet it powers just about everything around us and has become indispensable part of business today.

In this essay I am going to attempt to explain why software is different, why you don’t want to manage by conventional means, and some tips on how to survive it’s creation process.

How is software different

Here are some ways in which software is different.

  • The requirements change
  • It’s cost isn’t exponential
  • More people doesn’t help
  • No two projects are the same
  • Construction and design are rolled into one
  • One player can make a huge difference

Then there are the three simple truths that need to be accepted before you can successfully manage your own software project.

  1. You never have all the requirements going in.
  2. The ones you do have are going to change.
  3. You will always have more to do than time and money will allow.

And this is what we do, to deliver value, despite all the change and ambiguity that come with this kind of work.

  • Adaptive planning.
  • Flex on scope.
  • Keep our projects small.
  • Hire the best people.
  • Trust and empower the team and then get out of the way.

Let’s explore each of these in more detail and see what they really mean.

The requirements change

The first inconvenient truth about software development, is that as we build it, the requirements change.

For example, something that happens all the time on software projects is the customer will ask for a feature, the team will build it, and upon seeing it the customer has an ‘aha’ moment and discovers what they really need or want.

Normally, this would be seen as a good thing! The customer better understands what they want.

Yet by traditional measures this is seen as bad. A failure in planning. A failure in the requirements gathering process.

This sort of thing happens all the time on software projects, and you can’t manage this change the same way you manage capital projects, where change is shunned, and not allowed.

The inconvenient truth about software is that

  • Customers often don’t know, or can’t articulate, exactly what they want at the start of a project.
  • Upon seeing what they want, they change their mind.
  • You can’t plan for this discovery and learning upfront (at least not by conventional means).

The cost of change isn’t exponential

If you dust off your old project management books, or look into the latest version of the PMBOK v5, you’ll see a picture that looks something like this:

What this picture is telling us, is that the better we do at gathering the requirements upfront, the less expensive the cost of change will be later. That is sound advice if the cost of change is high.

But with software, the cost of change is low. And we’ve had to get very good at making changes on software projects late in the game. Why?

Because our customers are always changing their minds.
Businesses pivots and changes direction.
And new competitive threats emerge that we didn’t know about at the start of the project.

If you accept this premise, it totally changes how you manage projects.

For one you don’t stress about getting everything right upfront. You stress about getting started.

Secondly, it changes how you do requirements gathering. Instead of investing huge sums of time upfront, you keep your powder dry and save your analysis dollars till later, when you really need them.

We call this just-in-time analysis, akin to just-in-time manufacturing. Just like you don’t want to incur the costs of keeping inventory around your factory floor, you don’t want to incur the cost of carrying around out of date requirements. That’s a big form of waste.

More people doesn’t help

Like the pharaohs of Egypt, I often see traditional project managers attempt to meet unrealistic deadlines by throwing people at software projects. It doesn’t work.

Software isn’t ditch digging. You can’t just parcel it up and throw people at it like conventional work. You may want to do this for optics (to show your bosses you are really trying). That’s fine. Just don’t kid yourself.

More people will slow you down initially. And you should only expect marginal increases later (usually paired with lower quality and higher maintenance costs).

No two projects are the same

Every software project is different. No two have the same:

  • requirements
  • team
  • technology
  • priorities
  • business context
  • operating environment

So you need to treat them as a such. That doesn’t mean you can’t make broad comparisons between groups of projects in terms of size and scope. But don’t be fooled into thinking that because one project went a certain way, the others will to.

Construction and design are rolled into one

Software is one of those neat activities where art, science, construction, and design are all rolled up into one. This has the advantage of requiring less people. But it also means that you have a lot of work going on in one persons head.

I only make this point to reinforce the notion that software development isn’t ditch digging. Not all developers are created equal, and in no other industry that I know of does productivity vary the way it does in software.

Worker productivity varies

I hate using that word ‘worker’, but I use it by design to contrast and highlight the difference even further between programmers and construction workers.

As I said, software isn’t just construction. It’s design and construction rolled into in. You also can’t measure it by traditional means. It’s not lines of code. Some of the best software written uses very few lines of code. It’s one of the few forms of work where you can add value by taking product away.

This means software developer productivity can vary by factors of x2 – x4. In extreme cases x10. Just think about what that means. How do you plan, or set expectations, not knowing the productivity rate of your team? You have to guess.

Three simple rules

There are three simple truths, that need to be accepted, before you begin any interesting software project.

  1. It is impossible to gather all the requirements at the beginning of a project.
  2. Whatever requirements you do gather, are guaranteed to change.
  3. There will always be more to do, than time and money will allow.

These facts, inconvenient as they may be, are what create much of the drama and dysfunction we see in our industry. Traditional project management methods do well with the known. In software we deal with the unknown.

The very act of delivering software changes the requirements. – Kent Beck

Now this is where most projects stumble. They resist change. On software projects you can’t. Change is in your face every day. So we need a way of managing the change which is completely different from what we have done in the past.

Dealing with change

So here are five strategies for dealing with change.

1. Adaptive planning

When reality disagrees with our plan, we change our plan. Not reality. You’d be surprised at how many people fight this.

Instead of ignoring change, we change the scope all the time on our projects. New scope can come in, so long as old scope of equal size goes out. In other words, the way we keep our plans real and our commitments firm is we flex on scope.

2. Flex on scope

To much to do? Not enough time? Flex on scope.

It’s easier than asking for more money.
It’s less risky than perpetually pushing out dates, or cutting quality.
When push comes to shove, we do the same thing you do when faced with a busy weekend with too many things on the to do list. We do less. And cut scope.

3. Keep your teams small

Seymour Cray (the founding father of the supercomputer) once said that the perfect team size for building a computer is one. But he couldn’t do it with one so he bumped it up to twelve.

The same is still true today like it was back in 1976. Smaller teams are better when it comes to software. So keep your teams small.

4. Hire the best people

Developer, tester, and analyst productivity varies. You get what you pay for – this is knowledge work. So if you want a good product, pay your people above average and get good people.

5. Trust and empower

Finally, the people you are hiring are smart, motivated, and want to do good work. Trust them. Empower them. Show them the goal. Ask them what they need. And then get out of the way.

Don’t manage software the same way you would your capital projects

Are you still here? Good. I hope I’ve been able to give you some feel for how software projects are different, why the traditional PMBOK, PMI project management methods don’t work, along with some tips on how to set them up for success.

Software is a risky business. You never know exactly what you are going to get until you reach the end. However, like any creative process, we have ways of delivering great product, while working within our means.

All we ask is you work with us, together as one team, and forgive us when we occasionally do screw up and make a mistake. We want to serve business as best we can. This article is just one attempt at explain how.

Update: Big thank you to Clare Macrae for proof reading and improving the quality of this essay.

The Agile Samurai Bootcamp


It is with great pleasure that I proudly pronounce the unveiling of my latest course: The Agile Samurai Bootcamp.


Based on The Agile Samurai book, this course is the perfect intro for people wanting to get into Agile, but unsure of where to start.

The course is super expensive, a whopping $25 (take that Scrum certification), and I challenge you to find a better introduction to Agile out there.

You can learn more about the course at here, but if you act now you can save 25% by clicking the link below:

I hope you enjoy the course.

Jonathan Rasmusson

You Can’t Plan Learning

1 Comment


A question I sometimes get from executives when I showing them where key insights, innovations, and breakthrough occurred on projects is: “That’s great. But why didn’t you just plan a little more and discover those before you started the project?”

I get where they are coming from. They want certainty in an upfront plan. They don’t want any surprises. And they want their software projects to execute just like the power plants and factories they’re use to building.

Except software doesn’t work like that.

You can’t plan the upfront learning that comes from iterating a product or service with a customer, and helping them discover what they really want.

Some customers can tell exactly what they want. But many others don’t. They know they have a need. But they don’t know what is possible, or how to get there.

It reminds me of this story about pottery making (from the book “Art and Fear”).

The ceramics teacher announced on opening day that he was dividing the class into two groups.
All those on the left side of the studio, he said, would be graded solely on the quantity of work they produced, all those on the right solely on its quality.

His procedure was simple: on the final day of class he would bring in his bathroom scales and weigh the work of the “quantity” group: 50 pounds of pots rated an “A”, 40 pounds a “B”, and so on.

Those being graded on “quality”, however, needed to produce only one pot — albeit a perfect one — to get an “A”.

Well, came grading time and a curious fact emerged: the works of highest quality were all produced by the group being graded for quantity.

It seems that while the “quantity” group was busily churning out piles of work-and learning from their mistakes — the “quality” group had sat theorizing about perfection, and in the end had little more to show for their efforts than grandiose theories and a pile of dead clay.

So by all means plan. But don’t count on planning alone to get you there. The best results come from building, iterating, and learning. And you can’t plan that.

The Agile Mindset


Agile has been around for over a decade, a lot of people are doing it, and that’s great.

But I see a lot of organizations struggling. Not so much with the tools and practices. But mostly in the mind – the head.

Here are a list of thoughts and attitudes companies need to get if they are going to truly adopt Agile as a means of delivery.

The plan is going to change

Plan the work, work the plan. That’s the mantra traditional project management has been teaching PMs for years. Except that it doesn’t work. Companies that expect software projects to be straight lines. But they look a lot more like this:


and it’s this unwillingness to change the plan that kills them – Agile or not.

Everyones has a plan until they get punched in the face. – Mike Tyson

Software projects are a bit like getting in the ring with Mike Tyson. They punch you in the face. And if you can’t take a hit, or are so tightly boxed in a corner that you have no room to maneuver, you are going to get knocked out.

Adaptive planning enables Agile teams to roll with the punches, take advantage of opportunities when things don’t go their way, and avoid much of the drama and dysfunction traditionally seen on projects that refuse to adapt.

So get used to changing the plan.

You don’t have all the requirements

Accept it. You don’t.

You might think you’ve got them all. You may read books telling you to gather them all before you start. But you can’t. Why? Because like Kent Beck once said:

The act of delivering software, changes the requirements.

Which means no matter how hard you try, you’re not going to have them all before you start. And the ones you do have are going to change. Just accept it and plan accordingly.

There is no change control board

This concept is so foreign to Agile delivery I almost cringe in bringing it up.

On an Agile project the only person who decides whether a feature gets implemented is the customer. They don’t need to seek anyones permission or approval. It’s their money. They can spend however they like.

Agile sides with the customer. If the customer wants a change, they can have it. Agilists believe this leads to better decisions, better products, and puts the responsibility for deciding how to spend the money where it belongs – in the hands of the customer, not the PM.

The cost of change isn’t high

Traditional thinking is that the cost of change on projects is high. That’s why this picture is still printed and promoted in modern project management bodies of knowledge.


This used to be true in software. But not anymore.

With the advent of the personal computer, just-in-time compilers, and phones with more processing power than older mainframes, we can make changes to software at extremely low cost.

We’ve also gotten a lot smarter. We have software engineering practices today that allow us to make changes with confidence at speed. That changes the game.

Instead of fearing and resisting change, you are now free to embrace it. And use it to your customers advantage.

There are no predefined titles or roles

Roles blur on Agile projects.

I know you have narrow, clearly defined, titles, roles, and responsibilities. Agile teams don’t care about any of that. What they do care about is doing a good job and removing anything that gets in the way.

So don’t get discouraged when your developers want to test, your testers what to be involved upfront in the analysis, and your Project Managers what to contribute and program. You are going to have happier people, most engaged teams, if you don’t limit them with a formal title or narrowly defined role.


You are going to fail

There’s a price to pay for all this progressive, initiative, risk taking way of working. You are going to periodically fail. It happens.

You can’t build innovative software or create great products without periodically going over the edge. Good companies will forgive you. The bad ones won’t. The good news is you get to choose which you would rather work for.

They are not requirements

Let’s think about this word. Requirement. It rings of something completely necessary. Something we absolutely must have.

So if we can deliver 80% of the business value from 20% of the requirements, what are the the other 80%? They’re not requirements. We didn’t need them.

Drop the word requirements from your software project vocabulary. It’s the wrong word. Instead use features, and treat them as things your software project may or may not have. Not requirements.

They are estimates

You know what an estimate is right? It’s a guess.

Guess how long it would take you to roll ones with a pair of dice. How long would it take you to find a missing card in a deck of cards.

Guess. Try it out. And then compare your actuals to your estimates. Think you are going to be within 10%. Care to make a wager on that?

The way we size software projects isn’t all that different. We estimate, or guess.

Except instead of treating these estimates as guesses, we treat them as commitments (and that’s where we get into trouble).

Agile estimates aren’t commitments. They are best guesses based on limited knowledge.

We turn them into commitments the only way we know how. By building something, seeing how long that takes, and then extrapolating that for the rest of the project (it’s not rocket science, but it works).

Working software is the definition of success

For a lot of companies getting projects in on time and on budget is the overriding definition of success. And Agile would agree that projects have to work within their means.

But rather put so much attention on the plan (which by itself does nothing) Agile takes that time and energy and puts it back in the one thing that does add value – the software itself.

That may sound obvious, but we deliver a lot of projects that are on time, and on budget, but deliver no value. It’s gotta stop.

Chaos is the norm

In 2004 Doug Decarlo wrote an article I really liked contrasting the different mindsets between the traditional and extreme (Agile) project manager.

Newtonian – Stability is the norm Quantum – Chaos is the norm
The world is linear and predictable Uncertainty reigns
It is controllable Expect surprises
We can minimize change We should welcome change
Add rigor to the process to increase the feeling of security Relax controls to increase the feeling of security
Deliver on the planned result Deliver to the desired result
Use the plan to drive results Use results to drive the plan
Aim, air, fire Fire, then redirect the bullet
Keep tight control on the process Keep the process loose
Manage to the baseline Manage to what’s possible
Get it right the first time Get it right the last time

I think this hits it bang on. You either believe everything can be planned, controlled, and thought of ahead of time, or you don’t.

Agilists think Quantum. And their practices, management and expectation setting techniques reflect that.

Three simple truths

Once you accept these three simple truths, leading agile projects becomes a lot easier.

You don’t stress as much about schedules (we know we’re already late!) You stop trying to own problems that are outside your sphere of control. And you just accept that there is always going to be more to do than time and money allow.

You stop taking things personally.

And software is personal. You put a lot of yourself into a software project, and it’s easy to take feedback, criticism, and things like schedule pressure personally.

But accepting these simple truths frees you from all that. It allows you to see that which is clearly, and to not try and change something that can’t be changed.

OK. That’s it for now. I plan on referring back to this article in the future, but I wanted to get some stuff out there on paper, so when when helping companies get better at software delivery, I can direct them here for a conversation starter, and then get to work.

OK – let’s talk.

XP is the Mac of Agile


When Apple released the Macintosh it changed the face of computing. Graphical user interfaces, drag and drop icons, clickable menus. Since its release, the personal computer has never been the same.

The same thing happened with the release of XP. Like an earthquake, it shook just about everything we traditionally believed and practiced in software delivery down to its core.

And then both failed.


The Mac got displaced by the cheaper IBM PC Junior.
And XP was pushed to the side by the less threatening Scrum.

In this article I would like to explore why Scrum has become so popular, the challenges this popularity brings to Agile, and why, like the Mac, I don’t think we’ve heard the last of XP.

Maintaining the Status Quo

One reasons I believe Scrum has grown so popular, is because unlike XP, it struck the right balance between maintaining the status quo and change.

The first version of XP was threatening. If you weren’t a developer or a customer, it wasn’t really clear what your role on an XP project was. With developers and customers joined at the hip, XP teams delivered at a speed and level or quality, seldom seen outside of startups.

(Note: In reality we did many XP projects with analysts and testers but I want to make a point, so bear with me).


But this speed and efficiency came at a price. It radically changed the status quo.

  • Testers felt threatened because developers were writing tests.
  • Analysts questioned their role if developers were speaking directly with customers.
  • And Project Managers were perhaps the most disrupted. XP trivialized their best laid plans, and had them embrace the one thing they had been trained to eliminate on all software projects – uncertainty and change.

Scrum on the other hand was different. Instead of insisting developers and customers sit together and build software, Scrum said: “Why don’t you guys form a team, and ship something of value every 30 days.” It didn’t say how to do that. Only that working software every 30 days was the goal.

This was music to the established players ears.

  • Analysts could analyze.
  • Testers could test.
  • Project Managers could PM.


I call this Corporate Scrum. Everyone could pretty much do exactly what they did before, but now in shorter 30 day cycles. Much less radical. Way more status quo.

Where XP alienated. Scrum embraced.

The challenge with Scrum

This of course lead to some challenges. Scrum is all about planning. It doesn’t talk engineering. This lead to a lot of Scrum teams doing the easy stuff (daily standups and Sprint planning), while failing on the hard (consistently delivering high quality working software).


Planning is easy. Delivery is hard.

And I think the Scrum community itself could do more here. Not highlighting, or actively promoting the XP practices around unit testing, refactoring, TDD, and continuous integration runs the risk of seeing the term Flaccid Scrum grow in popularity.

The Tribal knowledge of XP

And I think us XP’ers can do our part by sharing our stories and wisdom around practices like:

These euphemisms are too important to forget. And the spirit and technical excellence that contributed to XP’s early success will be necessary for Scrum too.

This is the beginning. Not the end

So while XP feels like the Apple Macintosh of the 90s, it would be premature to write XP off. Many of its ideas are only now becoming widely accepted. And many more are only just beginning to re-emerge.

It may never reach the heights today’s Mac, or displace the IBM PC Junior that is Scrum, but its influence and spirit are still being felt, and will be, for years to come.

Corporate Scrum


Corporate Scrum is a term I use for companies that do traditional Waterfall in 30 day sprints.


Instead of blurring the roles, and making things like quality a team responsibility:

  • analysts analyze
  • testers test
  • programmers program
  • and PMs project manage

There’s nothing inherently wrong with Corporate Scrum. For many it’s a big improvement, and a necessary first step into Agile.

But once teams get the basics of Scrum planning, they should look for opportunities to broaden their skills, and discover their natural abilities, and play more than just one role on projects (for example The Automated Tester).

The book that changed the game


I miss XP. It hit me hard how much when I read Uncle Bobs Ode to Kent’s White Book.


Man those were good times. We were going to change the world. It was us against them. It was the tyranny of the traditional against the brash, naivety of the new. And It was the programmers who finally stood up and said “Enough!”.

And man did XP make waves.
Test first? Ridiculous.
Recipes cards for requirements? You gotta be kidding.
Simplest thing that could possibly work? Grow up.

It’s unfortunate that people don’t talk about XP like we used to. But it’s practices are alive and well practiced everyday by thousands around the world.

Let’s take a look at why this book has so influential, the impact it’s had on our industry, and why we still aren’t all using it today.


XP tipped testing on it’s head.
No longer an after thought, left till the end, XP made testing the center of the universe on software projects
You didn’t write code until you had a failing test on XP projects
You didn’t check code in until all the tests ran
The tests needed to be continuously passing – 100%
You weren’t done, until all of your customers tests passed
Customers wrote tests. Developers wrote tests. Everyone tested on an XP project.


XP challenged a lot of what we traditional thought was good (upfront) design.
Taking more of an options approach, XP recommended not adding complexity until you absolutely needed it (YAGNI).


This was XP’s way of pushing back against the over engineering going on in the late 90s. XP taught us to design continuously (not once) while introducing us to the importance of language, and the power of a good metaphor.

Requirements & Analysis

The story card was XPs greatest innovation.
Instead of trying to get everything written down and get everything right upfront, XP said jot the idea down on one of your mom’s recipe cards, and have a conversation later with your customer if it ever comes up.
You wouldn’t believe the howls of protest.
How this could possibly work!
Where’s the tracability?
Where are the requirements?
How are you going to fit all those requirements on that one little index card?


1000s of books had been written on how to manage and plan software projects. XP pretty much blew them all up.
XP trivialized what it took to plan software project.
It punted on the whole ‘plan the work, work the plan’ thing by telling the truth (we don’t know exactly when we are going to be done), and rejecting static plans. Instead it said, we are going build something, see how long that takes, and then feed that back into the plan. Then we’ll tell you how are date is looking. No wishful thinking or management by miracle here.

XP was the first to suggest that when you have too much to do, and not enough time, you should do less. Rocket science. I know.


You can see where all this is going.
XP disrupted just about every traditional role on the software project.
It showed how dysfunctional things in our industry really were.
And not everyone appreciated that.
XP’s problem was it’s lack of inclusiveness.
It was great if you were a programmer or a customer.
But it was terrible if you did anything else.
It threatened testers (developers were now writing the tests)
It threatened analysts (developers were now talking directly to customers)
And it especially threatened project managers (small groups of professionals don’t require much in the way of management).

For these reasons many attacked XP and the Agile movement. And that might have been it if it wasn’t for the emergence and soft sell of Scrum.

Scrum to the rescue

For all of XP’s divisiveness, Scrum was the exact opposite.
Scrum was for everyone.
Small, self organizing teams made up of multi-disciplinary people delivering software every 30 days. Sounds great.
Traditional testers could test
Analysts could analyze.
Everyone had a spot at the table and was a large part why so many flocked to it.

PM’s were perhaps the most happy. Not only where the back in change. They finally had a means to ‘control’ these Agile projects, while simultaneously gaining a new title themselves – Scrum Master.

This was of course maddening to XPers and felt like a huge step backwards. Not only did Scrum not bring anything new or innovative to the party (from the XPers point-of-view). It completely left the most important parts out – the software!

But despite all these things, Scrum was hugely successful in one area where XP failed. Scrum was Agile’s beach head in enterprises and organizations.

Scrum made it safe for people to talk Agile. I am also extremely grateful to Scrum for promoting the concept of the self organizing team – no titles or roles on projects.

Ripples for years to come

Some to the largest organizations in the world are applying XP at a mass scale. XP had a huge affect on how Google tests software. And, not sure if anyone has noticed, Kent spends a lot of time these days at Facebook. I don’t know what the arrangement is, but that place reeks of XP. And for anyone who wants to see world class engineering and problem solving on a global scale check out how Facebook releases software or how they do development and deployment (hint – there is no QA department).

But love it or hate it, it’s hard to deny how much this book has affected our industry. Apparently it’s now recommending reading for management gurus. While on the other hand I know many in our industry would be quite happy to see it quietly die.

XP matters. This book matters, and many of us wouldn’t be where we are today if it weren’t for Kent and Ward. That book took courage to write. Let us hope we can show the same courage and continue talking about it in the future.

For more information checkout:
My recommended reading list (XP Books near the top)
The original IEEE Paper
Good ol Wikipedia

The Quantum vs Newtonian Belief System

1 Comment

In 2004 Doug Decarlo wrote an article I really liked contrasting the different mindsets between the traditional and extreme (Agile) project manager. I think this hits it pretty bang on.

Newtonian – Stability is the norm Quantum – Chaos is the norm
The world is linear and predictable Uncertainty reigns
It is controllable Expect surprises
We can minimize change We should welcome change
Add rigor to the process to increase the feeling of security Relax controls to increase the feeling of security
Deliver on the planned result Deliver to the desired result
Use the plan to drive results Use results to drive the plan
Aim, air, fire Fire, then redirect the bullet
Keep tight control on the process Keep the process loose
Manage to the baseline Manage to what’s possible
Get it right the first time Get it right the last time

Older Entries Newer Entries

%d bloggers like this: