XP Days at Spotify

2 Comments

Screen Shot 2015-10-30 at 1.08.46 PMToday I had the pleasure of hosting the second day of a two day XP style workshop with some incredible developers at Spotify. Here’s what we did.

Build something fast!

We kick things off by asking the class to build a Reverse Polish Notation (RPN) style calculator. In 10 minutes.

We do this partially by design – to create a little stress. But it’s also an ice breaker. Just to verify everyone’s machine is up and running. As well as gauge the experience level of the class.

We then have a discussion about what some of the challenges are when building software. As well as what quality means, and how we can shoot for that in our software.

The birth of XP

This then segues into the birth of XP. Here I share Kent and Ward’s original vision of what XP was. Talk a little about the C3 project. And basically explain the XP attitudes behind if certain things are hard, we are going to continuously do them, all the time. Testing, integration, pairing, design, etc.

I also draw the cost of change curve and share how Kent wanted a way to develop software, such that the cost didn’t increase exponentially over time.

Screen Shot 2015-10-30 at 1.08.55 PM

Elephant Carpaccio

Partly because smaller stories are a good idea, and partly because it helps them with the project they do on day two, we then do an Elephant Carpaccio story slicing exercise.

https://docs.google.com/document/u/1/d/1TCuuu-8Mm14oxsOnlk8DqfZAA1cvtYu9WGv67Yj_sSk/pub

This is great because it reminds people about what makes stories valuable in the first place, while also giving advice on how to slice. Basics, but really good stuff for people who may not have read or had any story training.

TDD together

This is where we formally introduce TDD, and revisit the RPN calculator we built at the beginning of the course.

As a class, I start with one other person, showing them the mechanics behind writing the test first, making it pass, and then … sometimes refactoring. Sometimes I don’t refactor, just to let the duplication build up and save for conversation later.

But we do this as a group, and it gives students a nice intro on a codebase and a problem they already know.

Refactoring

Something that’s surprised me as a middle aged programmer (cough) is how many people still haven’t read Martin Fowlers seminal book on refactoring. I have a lot of fun with this.

Refactoring, even in really tight circles of programming, is still a very misunderstood term. Usually it just means rewriting code. But people don’t appreciate always that when you are refactoring you aren’t adding any new value. You are only improving the existing design.

So I really hit home that the reason why that word appears in a menu at the top of your favorite ID is because of this book. And then I ask how people refactor without unit tests.

It’s a trap of course. Because you can’t. But a lot of people still do. So we talk about that.

So that’s day one. And during the day we also sprinkle in discussions about YAGNI, production readiness, and other XPisms and attitudes.

Code me a game

Day two is all about putting TDD, unit testing, refactoring, continuous integration, collective code ownership, and pairing all into practice. In teams of four, the class then goes about building a text based adventure game.

Screen Shot 2015-10-30 at 1.12.24 PM

Text based games are great for learning TDD. They are fun, most people understand how they work, and they don’t contain a lot of hairiness. But they contain enough hairiness to give a taste of what applying TDD in the real world is like (like how do you handle all those input output streams?).

We have a few rules for the text based game we are going to build.

  1. No production code without a failing unit test.
  2. No code not written in pairs.
  3. Refactoring happens continuously while the code is being developed.
  4. Check in early and often.

Screen Shot 2015-10-30 at 1.14.34 PM

It’s really fun seeing how teams of x4 tackle handling a new code base. We also have the challenge that many people come from different parts of the world. So everyone has their own keyboard which can make pairing tricky.

But people overcome. We have lots of discussion about how to test, how to design, and how to tackle all the hairiness that seems to come with coding, even on a simple text based game.

We usually do x3 one hour iterations. With a demo, code review, and discussion at the end of each.

We also track number of commit, number of stories, and code coverage.

After three to four hours people are pretty pumped and exhausted. We then sit back and reflect on what we’ve learned.

It’s really interesting watching people try TDD for the first time. On the surface, when you see other people do it, it looks really easy. But it’s not. At least at first. It’s hard. It goes against everything not only everything you’ve been taught in school. It also not the natural state for people who are just used to hacking.

But once people get it, you can see a light go one. They design their code differently. They find they need less code. And it takes a lot of the guesswork away. They only end up creating what they need. And for many that’s a revelation.

Of course TDD is only one leg of the XP stool. And all the other practices also come into play – particularly pairing. People often ask how do you keep the discipline up. You play a big part of that I say. But your pair can help you too.

Insights, Actions, and Histories

We wrap up the day with Insights, Actions, and Mysteries. Here we ask people what they learned, things they want to do, and things we still wonder about.

Screen Shot 2015-10-30 at 5.09.06 PM

Screen Shot 2015-10-30 at 5.09.15 PM

Screen Shot 2015-10-30 at 5.09.22 PM
Big insights today were the awesomeness of pairing (you can learn a lot working with someone else). Actions were YAGNI – try hard not to over engineer. And mysteries were things like how fast to move when doing TDD vs going really slow and gearing down to really really small tests.

Overall it was a great day. I always learn as much if not more than the attendees. And this was a great group to work with. See you out there!

Screen Shot 2015-10-30 at 1.13.53 PM

Advertisements

XP Tech Practices Workshop at Spotify

1 Comment

Last week, a group of us did an XP Tech Practices workshop here in Stockholm. We covered Test-Driven Development, Refactoring, Unit Testing, Pair Programming, and a host of other Old school XP practices. Here are some notes and a write up about the course.

xp1

What is XP

XP (Extreme Programming) was the first really popular Agile method. Not only did it introduce Agile planning concepts such as user stories, adaptive planning, and iterative development. It helped popularize engineering practices such as unit testing, refactoring, test-driven development, and continuous integration.

It isn’t as widely practiced today as it was in the early 2000’s (Scrum has largely taken over). But it has many wonderful practices and ideas that deserve repeating and are still very much relevant for software teams today.

This workshop aimed at revitalizing some of software these practices, showing participants who they were originally meant to be performed, and then discussing how they can be introduced into their workplace.

How do you feel about your work?

We start off the course by asking participants how they feel about their work. Specifically around quality and design. We do this to start a conversation around what quality is, how we know when we have good design, and what obstacles prevent us from reaching them in our software.

Build something!

We then break the ice by asking participants to code something up (like a calculator). We do this to get the juices flowing, engage the participants, and just get them hacking. This helps us see where they are coming from, their familiarity with the programming language, and how comfortable they are writing code.

We don’t judge or do anything with the code that we produce here. We simply park it, and revisit it later. We then introduce XP.

XP Intro

XP can best be described as the software methodology that turns the knobs up to 11.

If code reviews are good, we will review code all the time (pair programming).
If testing is good, we will test continuously (acceptance tests, unit tests, TDD, demos).
If design is good, we will design continuously, every minute and every day (refactoring).
If simplicity is good, we vow to always leave the system in its simplest state.
If integration is good, we will integration continuously (continuous integration).
And if iterative development is good, we will iterate from day one, continuously getting feedback on our product, plan, and ability to please our customer.

XP Demo

Once we’ve covered the spirit and intent of XP, we demo the practices. We pair program up a sample problem, applying TDD, refactoring, unit testing, and pair programming in an extreme way, just to give the participants a sense of how all the practices work.

We then revisit the exercise they did in the ice breaker, and try it again, this time using the XP practices, specifically writing the tests first.

Build a game!

We then unleash them on their own codebase – specifically a game. They take what we’ve covered, and apply the practices in as an extreme a way as they can, and we build a fun interactive game over the course of several iterations.

XPisms

Over the span of the course we look for opportunities to introduce XPisms. Things like:

YAGNI – You aint gonna need it. A reminder to keep things simple, and not add excess functionality / code unless absolutely required (a good test is whether you can write a failing test first before adding the new code).

xp2

Production Readiness – A system spends a lot more time in production than in development. So why don’t we start treating it that way, and write code as if we were in production from day one.

Doing the simplest thing that could possibly work

There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult. – C. A. R. Hoare

xp3

Test everything that could possibly break – We can’t test everything. But we know we can’t test nothing. So we start by testing everything we think could break. And evolving our suites from there.

Dials to 11 – XP’s take on hard problems is to take them head on. Taking this approach takes many of the traditionally hard problems on software projects, and breaks them down into much smaller, easier to digest pieces.

xp5

Courage – Have the courage to write that failing unit test. Have the courage to say no to the hack on your finger tips. Have the courage to say no to the unrealistic schedule, and help another team out when they really need it.

Why we feel this is important

It may seem that XP is all about engineering. It’s not. It’s just as much about culture. But the culture XP wants the team to operate under doesn’t happen if certain practices aren’t in place. This course is about explaining the practices, showing how they work, and then helping teams adopt them their work place.

A special thanks to Henrik Kniberg for the initial course outline and for his support in making this course happen.

Quotes

“I was supposed to have a Hackday today, but this is WAY better”

“I found the course to be a lot of fun, and learned a lot about TDD/XP in the process. The exercises, particularly the four-part exercise to build a game for a customer, were a very good balance of difficulty and fun, and allowed me to learn at a good pace without being bored by trival tasks or overwhelmed by difficult ones.

In fact, the game task actually, perhaps accidentally, was almost tricking me into learning stuff. You know you give a kid a toy that’s actually teaching them maths without them knowing because they’re having fun with the flashy lights? It was kinda like that.

★★★★★ Five stars, genuinely one of the best in-house workshops I’ve attended.”

“Got a good amount of new perspective on XP and TDD. Got into the habit of writing unit tests during instead of after development. And it was a lot of fun!”

XP Customer and Developer Bill of Rights

4 Comments

To help customers and the development team work together, XP came up with a customer and developer bill of rights.

Customer Bill of Rights

  • You have the right to an overall plan, to know what can be accomplished when and at what cost.
  • You have the right to get the most possible value out of every programming week.
  • You have the right to see progress in a running system, proven to work by passing repeatable tests that you specify.
  • You have the right to change your mind, to substitute functionality, and to change priorities without paying exorbitant costs.
  • You have the right to be informed of schedule changes, in time to choose how to reduce the scope to restore the original date.
  • You can cancel at any time and be left with a useful working system reflecting investment to date.

Programmer Bill of Rights

  • You have the right to know what is needed, with clear declarations of priority.
  • You have the right to produce quality work at all times.
  • You have the right to ask for and receive help from peers, managers, and customers.
  • You have the right to make and update your own estimates.
  • You have the right to accept your responsibilities instead of having them assigned to you.

The bill of rights were a powerful means of setting expectations with folks, and letting them know who was responsible for what.

For example, XP made it pretty clear that developers shouldn’t be making calls about business priorities. That was the domain of customer.

In exchange, customers would stop telling engineers how long it would take to do there jobs. Or anything technical in nature (like how to build the system). That was the domain of the developers.

You may not have this problem today, but if you do, pull these out and put them infront of your team to ensure everyone knows what role they are planning, and what they should be entitled to on your project.

And if these rights don’t work for you. Create your own. Just don’t let the issue fester. Get everyone together, get into a room, and make it clear who gets to own what.

Making this clear could be the most important thing you do for your project.

Where did all the developers go?

23 Comments

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.

The Agile Samurai Bootcamp

2 Comments

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

course-splash-page

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

XP is the Mac of Agile

16 Comments

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.

mac-xp

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).

xpv1

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.

corporate-scrum

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

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.

The book that changed the game

6 Comments

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

xp-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.

Testing

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.

Design

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).

ddd

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?

Planning

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.

Controversy

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

Older Entries

%d bloggers like this: