ZendCon 2016

It's just past 5AM as I start writing this. I'm sitting downstairs in the ZendCon hotel, with a view on an empty bar and brightly coloured gambling machines. Since I woke up at 3AM (don't you love jetlag?) and today is the day I travel back home, I've been reflecting on the conference. I'll be missing a few sessions because I had to leave early, but I've already gotten a lot of new stuff to ponder about, my head is pretty full. Time to let it sink in a bit.

As I was pondering the lessons of this conference, I thought back to the last talk of yesterday, Exploiting the brain for fun and profit by Alena Holligan. One of the things Alena talked about was how you can improve your learning. One of the things she mentioned was teaching others. Teaching others really helps you to learn stuff yourself. But the other thing was: Write it down. Writing things down will help you to not forget stuff. She even mentioned the situation I've been in a couple of times: Googling for a problem only to end up on your own blog, where you discuss the solution. As such, I'm writing down some of my lessons of ZendCon. So I won't forget, and hopefully to help others learn about this stuff as well.

Let's start with the opening keynote by Andi Gutmans and Rod Cope. Andi and Rod looked back at where we came from and where we're going with technology. While the picture for the future that was painted sounded awesome for users, it sounded horrible for privacy. I'm really curious to see where this will be going.

I also attended the Composer for corporate use talk that Stephan Hochdörfer did. One of the things I learned from that talk is the composer license command, which gives you an overview of the licenses used by your dependencies. Related to that, I also learned about VersionEye, which seems like an interesting service. That is now on my list of things to check out.

I was really looking forward to see Uncle Bob do a keynote at ZendCon, and this turned out to be an amazing keynote. He gave a nice overview of some common patterns from the past as well as the present. It also taught me that at my current project we're doing pretty well for some of these topics. There's always room for improvement, but we're on the right track. It is good to get that kind of confirmation.

Next to the talks I also had a nice chat with some of the sponsors at their booths. My most important lesson there was the Clean Coders video platform. Before ZendCon I was not aware it even existed, but with a lot of material delivered by people like Uncle Bob, Corey Haines and Michael Norton on topics such as architecture, technical debt, testing, SOLID etc it looks like an amazing opportunity.

It has been another amazing ZendCon, and I'm bringing the lessons back home with me.

On Priority

I got a private message on one of the Slack networks I'm on on August 2nd. Mike Bell invited me to write something for Geek Mental Help-week. As usual, I delayed to the last moment to write that, and the Geek Mental Help-week was last week. I'm publishing this now, a couple of days too late.

For quite a while I was thinking about what to write about. I had quite a few good topics I could possibly write about, but I just hadn't decided yet. I've thrown out all those topics (for now at least) because I am too late, and that actually gave me the best topic.

Last Thursday was a horrible day. I felt my mind being tricked into depression. I specifically use these words because I can not really control when it happens, or what happens. I've had cognitive behavioural therapy to recognize when it happens and to try and counter it, which usually works, but on Thursday I had a really hard time actually doing so.

I had a full-day training session scheduled on Friday, a training session I had already postponed earlier. I could not cancel that. So I set my mind to delivering that on Friday and was able to do so, in a way I feel was good. It went much better than I had anticipated, which made me feel a bit better. It was also incredibly exhausting, and I've found myself to have an extra hard time keeping myself out of depression when I'm tired. I succeeded though, but again, I struggled.

Over the past years I've tried to force myself to have actual weekends more than before. I try to stay away from the computer a bit. During therapy I learned that one of the ways to try and stay out of depression is by staying active, doing things, going out. And so when the idea came up to head into the nearby city to catch Pokémon, that sounded like a good plan. It worked. It kept my mind occupied enough, distracted enough. It was still hard work to keep my head straight though. On Sunday, this resulted in me sleeping quite a bit through the afternoon. Unsurprisingly, I may add.

And now it is Monday. The day started just as bad as the previous days, but somehow as the day progressed, my head cleared. And for the first time in 5 days, I started feeling quite well again. By the end of the day, my head had cleared. What's left is this tired feeling in my head. I'm pretty sure that will clear though.

It's been a long 5 days, but I've survived. And while I never can tell for sure, I'm pretty sure it had to do with me setting priorities. Going out with the family on Saturday, not working on either this blogpost or my keynote for PFCongres next Saturday or my talks forZendCon the week after. And while I'm sorry that this blogpost is a bit too late, it illustrates all too well that it is important to set the right priorities. The great thing is that many people had their priorities right last week. This list of articles is the proof of that.

PHPStorm & OSX: Mouse Stopped Working

This is just as much a post for future me as it is for the rest of the world.

While I was working on preparing a training for the end of the week and was using PHPStorm to create some example code, all of a sudden my PHPStorm stopped responding to my clicks. I could click whatever I wanted, it just would not work anymore. As you can imagine, this is quite frustrating when you're trying to get some work done. The weird thing was: My trackpad worked anywhere else in OSX, just not in PHPStorm.

I took to Twitter to vent my frustration, then tried the more constructive approach of tweeting to @PHPStorm with this problem:

@phpstorm somehow my PHPStorm does not respond to mouseclicks anymore, just to keyboard strokes. What can I do to fix this?

Kevin Boyd quickly responded with a link to the Jetbrains forum. The problem seemed similar, but aside from "reinstall the IDE" there was not really a good solution there. While I was searching for other people that may have the same problem, another tweet came in, from Damon Jones:

@skoop @phpstorm Mac? You've zoomed the window slightly (pinch to zoom). Zoom back to normal and you should be okay.

OK, that seems very weird, but let's see what happens if I "unzoom" while in PHPStorm. WHOA! This was it! Apparently, while using my trackpad in PHPStorm I had accidentally pinched to zoom just a little bit. Not enough to be noticable, but enough to make PHPStorm stop responding to any mouse interaction.

Thank you Damon. I owe you a beer at a conference some time.

Win a FREE PHPNW ticket

I've said it before and I'll say it again: PHPNW conference, every first weekend of October in Manchester, is the best PHP conference I've ever been to. I buy my ticket blindly as soon as they go on sale every year. I've been accepted to speak very regularly in previous years and then raffle off my ticket. I was not expecting to need to do that this year, since I did not get accepted to speak. I was looking forward to experience PHPNW as a delegate this year.

Things have changed though. Unfortunately one of the speakers had to cancel their speaking and I've been asked to be the replacement. Of course I said YES! Speaking at PHPNW is a fantastic experience, and I'll gladly help them in a situation like this. But this also means that I don't need my ticket anymore.

This means, however, that I have a spare ticket. As it has become a tradition by now to raffle my conference ticket once accepted as a speaker, I'm again raffling my PHPNW ticket. The ticket has full access to all events of the main conference, including the hackathon on Friday, the social on Saturday and the Sunday conference day. The only thing is: The conference is THIS WEEKEND!

So: If you want to win my ticket, the only thing you need to do is send me an e-mail: stefan@ingewikkeld.net. Please only send an e-mail if you can actually make it this weekend. On Wednesday I'll do a random draw of the winner and send them an e-mail.

PHPNW will be awesome again. See you in Manchester!

The Speaker Package

I've been meaning to write more about speaking recently, so after I wrote about my personal CFP rule, let's write about a very related topic: The Speaker Package.

What is it?

The speaker package is the term used for the package of reimbursements and other advantages you have as a speaker. This may (or may not) include a free ticket to the conference, travel and/or hotel reimbursements, a speakers dinner and some other things.

Why is it important?

When submitting to a conference, it is important to realize what the speaker package consists of. For instance, if you can not pay for your own travel or hotel and don't have an employer that does so, you need to be sure that the conference can cover this. Also, for planning purposes it may be useful to know about speakers dinner, so that you block your calendar so you are able to attend it.

I made the mistake once of making assumptions about the speaker package (in this case: I assumed travel was being reimbursed) when submitting proposals to a conference. I got accepted, but then found out my flight was not covered by the conference. Because of that, I had to cancel that conference. Cancelling a conference is never fun, but especially not because of something like this.

Speaker package unclear? Ask!

If something is unclear about the speaker package, do not hesitate to contact the conference about it. I've found that many conferences these days use OpenCFP for their call for papers. The OpenCFP standard template contains some information about the speaker package, including:

Complimentary airfare/travel (according to conference policy)

Unfortunately, conferences usually do not elaborate on what this conference policy actually is. Since some conferences only give partial reimbursements for airfare, you're never really sure how much of the flight you're going to pay for yourself. If a conference has this standard text and no additional information on their reimbursement policy, just get in touch with them! Get them to clarify this before submitting to their CFP.

Another personal rule

In my previous article I explained about my personal rule to not submit to a conference unless I'm sure I can make it if I get accepted. I have another personal rule, this one concerning the speaker package:

I will not submit to conferences that do not make an effort to reimburse their speakers

Unfortunately, there are conferences out there that do not offer to pay for anything for a speaker. These conferences mostly seem motivated by the idea that "you're already coming to this conference anyway, so become a speaker while you're here". I can sort of understand this sentiment, but I personally feel like this implies a certain lack of respects towards the speakers.

Speakers invest a lot of their time in a conference. They spend hours, sometimes days on preparing a talk, creating slides, rehearsing it, finetuning it, submitting it to conferences. They also spend a lot of time on the conference: car trips or flights, actually being at the conference, talking to people before and after their talk. They even spend money because they come to the conference: They need to eat and drink, park their car, etc. If the speaker is a freelancer or entrepreneur, they'll also miss income because they can not make billable hours while at the conference. All this is a huge investment, to be part of the conference. Speakers are usually passionate and willing to do this, but when conferences do not even make an effort to reimburse at least part of this, this is a reason for me to not submit to a conference.

It is the effort that counts

I'm not saying that all costs should be reimbursed. As I mentioned before, speakers are usually passionate and willing to invest in conference speaking. I know I am more than willing to do this. I've spoken at conferences where travel is not being reimbursed (the best PHP conference in the world does not reimburse travel) and I've spoken at conferences where I offered to pay for travel (because the conference offered sponsorship packages in return for covering travel). All of these conferences have one thing in common: They all offer to pay for (part of) the cost of speaking. And in case of PHPDay, they even offer a valid way out of their reimbursements by offering sponsorship in return for not having to reimburse. It is the effort of trying to cover expenses that counts to me.

So now what?

Next time you open the CFP page for a conference, look for the speaker package information and make sure that it meets your requirements. If you have an employer, talk to them to figure out if they can perhaps cover part of the cost, so you can help make the conference an even bigger success. If anything is unclear in the speaker package information, get in touch with the conference to clarify before submitting. And if it doesn't meet your requirements, simply don't submit.

On submitting to CFPs

One of the first things you do if you want to speak is that you submit to a CFP (Call for Papers) of a conference. Most conferences use this system to get a nice selection of talks out of which to compile the schedule for a conference. The idea is that speakers tell the conference what they want to speak about and the conference can make the selection of speakers and topics for their conference.

Having been a conference organizer as well as a speaker, I've seen both sides of the CFP process. Because of that, I've made some decisions as a speaker on how I handle CFPs. Since I've discussed this with several people in the past year but it keeps coming up, I've decided to document one of my decisions here.


Today I tweeted:

#firstworldproblems #speakerproblems call for papers closing before other conferences in same period have announced their speakers

To give this some context: I was looking at the currently open CFPs (thanks to the awesome CFP Report newsletter) and noticed that the CFP for PHP[world] is closing today. Now, I submitted some talks to ZendCon, which is in the same period, and I can't really handle two North-American conferences in such a short time period so I need to make a choice. However, ZendCon has not sent out acceptance/rejection e-mails, so I don't know if I get accepted there yet.

Andreas Heigl responded with:

@skoop apply and then see what happens. First one calling wins ;)

This is actually what I used to do, and I know other people do this as well. And from the speaker perspective, this makes sense. Having been on the other side, however, I've decided not to do this anymore. Let me explain...

The CFP process

Most conferences get hundreds of proposals, where they have between 5 and 25 slots to fill, depending on how big the conference is. You may already notice the problem: You'll have to make a very small selection out of a big pile of proposals.

My experience with a CFP is that it is usually pretty easy to discard the first 10% of the proposals. They are one or more of the following:

  • Unclear
  • Not appropriate for the theme of the conference
  • A single talk for an international speaker (too expensive for most conferences)
  • Just plain bad

I must admit that the last reason is actually becoming more rare. Speakers are putting much more effort into their proposals and talks than they used to, but it sometimes still happens.

The biggest problem with this is: After removing 10% off the big pile, you still have a pretty big pile of appropriate, high-quality talks left. You'll have another 70-80% of the talks to reject.

The process of going through all these talks is hard. It usually involves a lot of reading, research, trying to find a balance in the offered subjects, deciding on how many international speakers you can afford to fly in and trying to find the right talks to accept for those international speakers (international speakers usually need at least two talks to be accepted to make it financially viable to invite them).

I've been involved in the CFP team for a lot of conferences. This whole process is usually a team effort of between 2 and 20 people. Imagine the amount of time that goes into creating a balanced schedule out of the CFP. Hours and hours of work.

Now, imagine what happens when you finally send out the acceptance e-mails, and one or maybe even two or three speakers respond with "sorry, I can't make it".

That response means (part of) the above process begins again. I know it happens, but it is not a nice experience as a conference organizer. So...

My personal rule

As a result of the above, I've set a personal rule only to submit to the CFP of a conference when I know for sure I can make it (emergencies and such are the exception to that rule of course). It seems only fair to conference organizers that I can make this guarantee when I submit to their conference.

Now what?

I'm not saying all speakers should adhere to this rule, but I hope this blogpost will give a better perspective to new and existing speakers about "The Other Side" of the CFP.

Command or Controller

A couple of weeks ago while walking towards lunch with Jelrik we were having a bit of a discussion about the use of the term Command. Not long before that, Jelrik had asked a question about naming of Commands in our Slack channel, which led to some confusion.

The confusion of the term Command

The confusion of the term Command in the Symfony context is not strange. Jelrik was talking about a Command class, and since we're working with Symfony, both me and other colleagues assumed Jelrik was talking about console commands. Funny enough, he wasn't.

We're also using an implementation of command bus in our project, and Jelrik was actually talking about that instead of Symfony console commands.

What is a command?

This triggered a conversation about the confusion and how this can be avoided, which led to the question of what a Symfony console command actually is. The answer seems to be quite easy:

A controller for commandline requests

If we start thinking about console commands in this way, the next question is easy:

Why call it a command?

If a console command is actually a controller, why do we still call it a command. The main answer to this question would be:

My GreetBundle\Command\GreetCommand is automatically recognized up by Symfony

Of course, this is extremely convenient, but on the other hand we're perhaps breaking with our best practices and application design. When I do code reviews for customers, I often find a pretty good design for the "real" controllers, but the console commands are sometimes 100's of lines long and completely ignore best practices. Somehow the fact that they are executed on the commandline instead of through a webserver means one can quickly hack together a script.

Let's call it how it is

So here's a little proposal for you: Let's name our console commands for what they are: Controllers. Perhaps then we'll actually offload the business logic to services, and keep our commands controllers clean. While this does mean we'll have to manually register our commands, it creates a much clearer overview of what our code is doing.

Let's go for an example

And what better example than Hello World? ;)

So I've created a new Symfony application, and created my fantastic new IngewikkeldHelloWorldBundle inside that application. The bundle has the default directory structure:


This basic setup gives me a nice web-based Hello World, but I also want a nice console Hello World. Instead of creating a Command-directory with a new Command class in it, I just create a new Controller:


namespace IngewikkeldHelloWorldBundle\Controller;

use Symfony\Component\Console\Command\Command;
use Symfony\Component\Console\Input\InputArgument;
use Symfony\Component\Console\Input\InputInterface;
use Symfony\Component\Console\Input\InputOption;
use Symfony\Component\Console\Output\OutputInterface;

class GreetController extends Command
    protected function configure()
            ->setDescription('Greet someone')
                'Who do you want to greet?'
                'If set, the task will yell in uppercase letters'

    protected function execute(InputInterface $input, OutputInterface $output)
        $name = $input->getArgument('name');
        if ($name) {
            $text = 'Hello '.$name;
        } else {
            $text = 'Hello';

        if ($input->getOption('yell')) {
            $text = strtoupper($text);


To get this Controller to be picked up by Symfony, I register it as a service:

        class: IngewikkeldHelloWorldBundle\Controller\GreetController
            -  { name: console.command }

The tag here is the magic key to recognition as a console command. It's not that hard, is it?

Avoid confusion, improve your code

The more I've been thinking about this approach, to more I'm starting to like it. Optionally, we could make a subnamespace inside Controller to communicate the purpose even more. Something like:

\IngewikkeldHelloWorldBundle\Controller\Cli\GreetController \IngewikkeldHelloWorldBundle\Controller\Web\DefaultController

For bundles with a lot of different logic, this could make working with the difference between CLI and web controllers a bit easier. The main idea to call it a controller stays the same though. It makes sense, doesn't it?

Lessons From ConFoo

ConFoo 2016 is over. The past days a huge amount of developers, most of them from Canada but also from the USA, The Netherlands, South Africa, France and quite a few other countries came to Montreal for ConFoo. I know I had a lot of fun, and I surely learned a lot. One of the keynote speakers said on Thursday:

“As you learn, share it”

This is something I've been saying as well, but not doing enough of. So as I sit here (local time 4:42AM and awake because at home it's nearly 11AM) I'll share some of the lessons of ConFoo.

Polyglot conferences are the best

This is an overall lesson and something I've learned before and even say in my Level Up Your Team-talk. Going to a Polyglot conference gives you a fantastic amount of extra information. Just talking to people with different backgrounds will teach you a lot about how other languages solve things, and will give you some additional information on when to choose which tool. While my main weapon of choice is still PHP (and I don't see that changing any time soon), I always feel inspired by seeing how other languages handle things. So get your ass over to ConFoo, DomCode, 4Developers or any of those other polyglot conferences. It is certainly worth it.

We can do so many cool things with technology

On Thursday, I attended the talk "Unlocking Data Trapped in Audio and Video Files" by Keith Casey. Now the stuff he talked about in his talk is not something I've really had to do in any of the projects I've worked on, but the one thing I took away from that talk was: We can do some really cool and crazy things with technology. In his talk, Keith talked about not just converting spoken word into text, but also recognizing emotion, identity and more. We can, in varying forms of correctness, actually do stuff like this already. Isn't that amazing?

I also learned something else: Quite a few companies still don't offer APIs. This is scary.


Friday morning started (for me) with a talk by Gemma Anible called "When All You Have Is An Elephpant..." which was, predictable, about choosing the right tool for the job and how PHP is not always that. This is a lesson I learned a long time ago, but what made me come to this talk was that Gemma was going to talk about Go. I've been interested in the Go language for quite some time now, but have never really had a reason to actually look into it, so this talk was a great way of at least getting a bit more information about it.

I have certainly come to the conclusion that I need to check out Go. The examples Gemma gave are quite nice. Though a slightly different syntax, I don't think it would be hard to learn the syntax of Go, but the concepts are certainly different, and it's those concepts that make the language quite interesting, especially for running a lot of stuff concurrently (for instance when writing workers that process stuff in the background). Gemma recommended the Go Tour, so I need to check that out soon.

The power of lightning talks

ConFoo ended with lightning talks. Now the lightning talks I'm used to are usually 10-15 minutes long, but the lightning talks at ConFoo were only 5. I was a bit sceptical at first, but this works extremely well. It is amazing how much information one can put into 5 minutes when challenged to do so, and the talks were a nice variation of funny and serious talks. I am seriously considering doing an event in The Netherlands now purely based on lightning talks. If you're interested in this, drop me an e-mail.

Share your lessons

When I decided to try and blog a bit more again, I wanted to try and share more information again. There had been months where I had not blogged, or only blogged once. Looking at my archive I see an increase in blogposts since January 2015, and though there have still been months without blogpost and months with only one blogpost. I will be trying to increase that again. I'm not sharing enough with the world, and I feel I need to improve on that.

While I try, perhaps you should also try. Blog, speak at usergroups, join community Slack channels, speak at unconferences and conferences, tweet, exchange information and knowledge at the office. Share your lessons.

Three Months Of Patreon

Tomorrow it is three months ago that I launched my Patreon page. As I mentioned in my blogpost about launching my Patreon page, it was mostly an experiment to see how that would work out. I've seen a bunch of artists use Patreon very successfully, but the world of PHP, open source and software development, while it has some parallels, is different from the world of art, music and books. I was curious about how Patreon would be received in this world.

Since it was an experiment, any outcome would be a good outcome. I went without real expectations. Of course I was hoping it to be a major success, but with me being the only Patron of Rafael, I wasn't expecting much.

Now, three months later, I have two patrons. I am very grateful to Malte and Rafael for their support. I've promised to only charge them a maximum of once a month, and so far I've charged them twice. This does not mean I get a lot of money. With those two charges, I can now buy me a beer.

We are not used to paying for free content

I found out about Patreon through Amanda Palmer, who successfully uses Patreon to fund music she gives away for free or sells for a very low price. Most of her music is available for "name your price" (basically, $0 or more) on her bandcamp page. Her most recent release, the David Bowie tribute EP Strung Out In Heaven has a minimum of $1, but that's mostly to pay for the royalties she owes the Bowie estate. Yet for every Thing she releases, even though it is available for (nearly) free, she gets paid nearly $34000. I think that's awesome! And it makes sense, because this is her life. This is how she makes her money. From her music.

Through Lorna I found out about an article on A List Apart by Rachel Andrews on the high price of free. In that article, Rachel says some really important things. For instance:

As an industry we have become accustomed to getting hundreds of hours of work, and the benefit of years of hard-won knowledge for free.

This is what open source has done for us, and it is fantastic! If you run into a problem, you're a quick Google search away from finding the solution. If you come by a new piece of tech, most of the times there's already tons of documentation and blogposts on how to work with this tech. This is extremely valuable and one of the main reasons why open source is awesome: There is virtually no barrier of entry to get into programming, aside from the need for a computer and an Internet connection.

While this is awesome, it also means that we've grown accustomed to getting all this information for free. We gladly consume all this labour of love by passionate developers and content creators and expect things to be free. And of course we should, that is why the creators made it. What I do think, however, is that we should consider to show our appreciation a bit more.

We are used to paying for paid content

We consume free content without any problem, and we also consume paid content without any problem. Sure, there is a small problem of piracy for paid content, but mostly people will gladly pay for their php[architect] subscription, their copy of Chris Hartjes' books or one of the many awesome publication of Lorna Mitchell. We seem to be fine with paying for content that has a price on it. This is, obviously, a good thing. The people who create this content spend a lot of time on it and are, partially or fully, depending on the sales of their content for their income. I can recommend you a shitload of content that is very much worth the money (seriously, ask me if you need anything).

So about that free content

We're used to paying for content, that much is clear. So why not show your appreciation of the free content out there by paying for that as well? Patreon is only one way of doing so. Last December, I went into my Steam account and through my friends list, and randomly donated some games from the wantlist of those friends to them. Many content creators also have Amazon wishlists. Sometimes, people also have some paid product aside from their free work. For instance, Jordi has Toran Proxy and an Amazon wishlist. And without wanting to do too much self-promotion, I have a Patreon page and a Paypal page for donations. Derick Rethans also has an Amazon wishlist. And these are just a few examples. If you consume a lot of free content (whether it is code, documentation/blogposts or anything else), please consider showing your appreciation.

Enabling people to show their appreciation

One does not work without the other: If you are a content creator and you supply your work free of charge, please consider adding a way for people to show their appreciation. Whether this is an Amazon wishlist, a Paypal page or a Patreon page, your Steam wishlist or something else does not really matter. What is important is that you enable people to show their appreciation. If more content creators do this, perhaps more people will get used to somehow paying for free content. And those who are less fortunate and simply can't pay will still be able to access all the free content out there.

Let's make one thing clear: I don't expect any content creator in the open source world to start earning $34000 for each piece of content they create, but it would be nice if people could just get that extra bit of money in that may allow them to sometimes just buy an extra ticket to a movie or concert, or that one bottle of whisky they really want. Let's try to change the mindset a bit and allow people to pay for free content.

The Sprint Demo

The new year also brought a new customer for me: At the start of January I started at the Digital Solutions Center of Schiphol Airport. They have an awesome project going on, and I operate in one of the two scrum teams there.

When you're starting with a new customer that has adapted Scrum (or any form of agile), it is always interesting to see how they adopted it. Interpretation and implementation of scrum and other agile methodologies differs greatly amongst different customers. I've had customers where it worked really well, and I've seen customers where scrum was only an excuse to be able to switch priorities or scope whenever they felt like it. No, I won't mention names ;)

Overall Schiphol gets agile. Not just the developers, but throughout the organization you'll see scrum boards in the hallways or in offices. It is awesome to see this work not just inside development teams. But there's one thing I've been most impressed with from the start: The sprint demo.

To give you some context: Just about every scrum/agile project I've worked on in the past had the same form of demo: One person would start in front of a crowd of stakeholders, team members and other interested people and run through the features that were delivered in the most recent sprint. The meetings were usually boring and one-way traffic: There was little interaction because of the way the meeting was set up.

In some projects, this was recognized and stakeholders were encouraged to speak up and give feedback. So now we got feedback, which was good, but the meetings could still sometimes be really boring, or break into useless discussions between stakeholders about implementation details or even worse: internal policy decisions.

Sprint Demo, photo by Paul Nieuwdorp

Schiphol got this and took on a new style of sprint demo. Instead of having a single person present the new stories that were delivered, stakeholders are split up in smaller groups. Several team members work together (or split the group up even more) to present the stories that were completed. Some of the team members present the features while others are standing there with sticky notes to write down any feedback from the stakeholders. Stakeholders are also encouraged to take the mobile devices that are on tables throughout the area to test all of the delivered mobile stories. Throughout the demo, the groups switch to other screens/devices to see other new features. At the end of the demo most people have seen all new features and have been able to give feedback on them.

Sprint Demo, photo by Paul Nieuwdorp

One of the most important reasons to take an agile approach is to have a good, short feedback cycle: To gather feedback from the stakeholders, the business owners, and possibly even your users. By taking this more interactive approach, it is much easier to get good feedback from all parties involved. But it also ensures a good, informal contact between the development team(s) and the stakeholders. Because the groups are smaller and the whole setup is not about one-way communication, people (even team members) feel free to offer their comments, to give that feedback that you as a team need to improve the product and to ensure you build the software according the expectations and wishes of the stakeholders. And that is eventually what the agile approach is about: Building the things that people want, not what they think they want. Because the groups are smaller, there is also less useless discussion. If a discussion happens, it is usally about the new feature and not about internal policies or decisions.

I've found this form of sprint demo to be much more in the spirit of scrum and agile, and I've been impressed at the way both teams handle the demo, and the way it is received by the stakeholders. The feedback we get is valuable and the time we spend on the demo feels well spent.

So have a look at your sprint demo. See how it works right now, and have a good look at how you can improve. The above may not work for every organization, but I sure am impressed how well it works within Schiphol.