I want your tests!

Programmers usually dislike testing.

With waterfall projects it was easy for them to just disregard testing as it was done at the very end of the project and usually by different teams.

Martin Fowler came up with a great analogy to explain the importance of testing. It's called technical debt.

Put in a few words, test early or it will cost you.

Think you are making a loan to your bank to build this house you want. You'll be able to get it quick but you'll end up paying twice the price once you add the interest.

Testing is the same, you can disregard it to go faster, but in the end it will be much more expensive.

This is rather natural when you think about it.

If you test your code just after having written it and it fails you'll know which part is involved. It will be fresh enough in your mind that fixing should be done in a matter of minutes.

If you do that at the end of a waterfall development you'll have no idea which part of the code is involved and you'll probably won't remember how you did the trick.

There's a programmer's joke which says:

//When I wrote this, only God and I understood what I was doing
//Now, God only knows

Your probably get the idea what you'll be facing...

The good thing is that testing early is now more and more widely accepted as a good practice.

What I'm more interested in is automatic testing. I've met quite a few teams finding that hard to do and not getting the point of doing it automatically.

The fact that Scrum says nothing about engineering practices explains testing is quite often overlooked.

This is the reason why the teams getting the best results are often complementing Scrum with XP.

Well the first argument for automatic testing should please most programmers.

If you dislike testing then why not let the computer do the task?

Actually you wouldn't be testing any more but writing testing code. You could go back to the beauty of pure coding...

The true argument though is tied to what you want to achieve with Agility.

With Agile projects you want to get two things:

A working software (which is the reason why you want to test early and often)

The ability to respond to change (which is the reason why you want to automate testing)

Indeed if it takes you a full day to test your whole software each time you change something, your ability to embrace change will be quite limited.

The more frequent changes you would make, the more danger you would add to the project. You could end up being in a situation where you don't have working software anymore very fast!

However with automated testing (part of the build process and ideally no longer than 10 minutes) you are safe from side-effects of change.

Now you see how you can be flexible, fast and still maintain working software!

Credits: Original design by N. Lochet (based on J. M. Flagg 1917' poster)

Addiction in games, almost there

I love addictive games.

I know it probably hurts the industry. 

When looking for reasons of society failures, people prefer to find excuses rather than looking at their own faults.

Movies used to be blamed for the violence in society. But this isn't trendy, people needed new excuses and video-games were a perfect one.

Think about it: people playing rather than working? Surely that must be evil?

Nevermind that playing is universal and part of all cultures, video games are just wrong!

So when I say that I love addictive games I deliver new excuses for the ones willing to blame everything on others.

Depiction of violence in video games transforms us all in serial killers.

Addictive games will get us all in serious need of psychological therapy (or not).

That being said, I still love addictive games.

When I am in front of a video game, I am playing. I'm not trying to educate myself, I'm not trying to escape reality, I'm just seeking entertainment.

A good game has to deliver fun or it misses the point. Fun is an essential characteristic of games as defined by french sociologist Roger Caillois in his book "Games and Men".

An addictive game is a game that knows how to distillate the fun so that we keep coming back for more.

That's not easy task, as it is not only a matter of delivering good emotions.

A linear emotional curve is not a good experience.

For emotions to be interesting they have to vary in kind and in intensity.

A good game will have you experiencing frustration.

But contrary to a poorly executed game, a good game will know how to pace the emotions it delivers so that you experience the right amount of frustration at the right time.

Creating addiction in a game brings one kind of emotion. This is not sufficient for the game to be enjoyable but it is a really good step towards it.

To create addiction you have to really understand two things: rewards and staging.

Neither rewards nor staging by themselves are sufficient to create addictive games. It is by successfully using both that you get the best results.

When speaking of these game design techniques there is one name that gets quoted a lot an that is Blizzard Entertainment.
Blizzard is a company which has taken addictive game design at the heart of many of its products. If you want to try good examples of addictive game design, you only need to play Diablo 3 or World of Warcraft.

In addictive games, rewards have three qualities:

Firstly, they are frequent.
It's rare to spend more than a few minutes (sometimes even seconds) without getting some kind of reward. Knowing this, the player is often tempted to play longer in the hope of better rewards.

Secondly, they are varied.
If the game keeps giving you the same reward over and over again, things will become dull soon enough. The player needs to know that a reward is close, but he still needs to be surprised when it comes. The more often he gets the same reward, the less interesting the reward. The more different kinds of rewards you can give, the better.

And finally, they are meaningful.
Rewards need to make sense to the player. They have to be useful for the game at hand (coherent with the universe). They need to be relevant to the challenge to overcome (proportional to its difficulty and intensity).
In this regard, context has a lot of influence.

For instance you are designing a racing game and want to give the player a car as a reward. Depending on situations this could be a good or very bad idea.
If the player only has a few cars and the car given is better, this is a good reward.
If the car given is less valuable than the ones he has, this will be perceived as a poor reward.
If he already has a lot of cars, getting a new car (even a good one!) isn't very interesting.
If the car given is of low value to the player and is coming after a great effort (say after a difficult and lengthy race) this could actually be resented.

This makes it very difficult to design meaningful rewards because it is quite complex to know which is the player's situation.
Indeed, no one player will play your game the same way (players have different skills and playing behaviors). People will go through different playing experiences, especially if your game is non-linear. What can be meaningful for someone may have no value for others.

Addictive games do not only offer good rewards, they also stage them in a way that motivates the player.

This is what I call the "almost there" concept. 

It takes two forms: gameplay staging and visual staging.
Gameplay staging is the idea that the player is presented with several gameplay loops (objective > challenge > reward) of various lengths  simultaneously.
The goal is that he always has something to do and that he always is almost finished with a specific gameplay loop.
Erich Schaefer in his postmortem of Diablo II puts it this way:

"There's always a quest that is almost finished, a waypoint almost reached, an experience level almost achieved, and a dungeon nearly cleared out."

This puts the player in a situation where he enters a never-ending streak of rewards.
There's always something coming and always a chance of getting something big: this creates addiction.

Visual staging is probably less well-known and used than gameplay staging but is equally important (if not more) to motivate the player to move forward.
The idea of visual staging is to graphically stage the progression towards a reward so that the player sees he is close from getting it.

The experience bar in World of Warcraft is a very good example of visual staging.

Instead of putting an interface that only shows your progress towards your next level in XP points, Blizzard displays a graphical way to see your progression.
The bar visually shows you where you stand.
When the bar is nearly full, chances are that you won't be quitting the game because you not only know that a big reward is close, but you also see it.
Actually the bar is even divided in small bubbles for a finer sense of progress. Back when I played people where often chatting messages such has "one bubble left" to tell others that they were close to their next level.

World of Warcraft ™ visual display of level-up progress - © 2013 Blizzard Entertainment, Inc.

Visual staging can not only help you to see your progress towards a reward but also what to do next.
This is a bit like in "Hop-o'-My-Thumb" (Little Thumbling), pick up a stone and the next one is immediately visible to you.
Translated into games, as soon as the player finishes a gameplay loop, he sees the next one right in front of him.
Again, in World of Warcraft when you finish a quest, a big exclamation mark usually pops on top of a nearby NPC's head.
This is your rather obvious clue to what to do next!

I could go on discussing tips for designing good rewards for quite some time. This post only briefly touches the surface of good addictive design.
But hey... my game is waiting.

My quest is almost finished...

Credits: Unknown

Has Scrum made us forget what is Agility?

According to Ken Schwaber, in 2009 about 84% of the organizations using Agile processes were using  Scrum.

However most people using Scrum were in fact using what was described by Martin Fowler as Flaccid Scrum. That is to say: inadequate variants of Scrum which were not yielding the full benefits of the methodology (when not actually making projects worse).

Now that we stand 4 years later, the figures are probably even bigger and the number of Flaccid Scrum even greater.

Scrum has been widely embraced in IT projects. And, indeed, that's quite understandable. Scrum methodology is lightweight, easy to understand and easy to practice. When compared to industry heavy methodologies such as PMI practices, Scrum offers a breath of fresh hair most welcome by project managers.

More and more often when we speak of Agility, we tend to really speak of Scrum. The line between the two is increasingly getting blurry.

This is problematic as it is easy to fault the whole of Agility for badly executed Scrums.

Scrum became dangerous to Agility as it was used by more and more people not knowing Agility in the first place.

Agility is a state of mind (for some it's even a philosophy), it is not a tool or process.

No tool will ever make you Agile, it is the way you look at things that will.

Scrum is a framework for project management. 

It is nothing more than a tool. Scrum, by itself, is not inherently Agile. 

As all tools it won't work if not used properly.

Following Scrum, even when done perfectly, does not make you Agile.

When starting on the Agile journey, you first need to understand the philosophy before learning how to use the tools.

If you want to get the full benefits of Agile tools, you need to understand their purpose. 

To learn that, you need to know what are the roots of Agility.

It would be easy to limit the roots of Agility to the signature of the Agile Manifesto in 2001.

That would be forgetting why experts met in the first place.

People only remember outcomes, not the path to discovery.

When the experts met in 2001, software development was getting more and more complex. 

With increased complexity, the rate of project failure was becoming higher.

Although improvements had already started (Scrum was initially published at the 1995 OOPSLA conference), software development project methodologies were still largely based on project methodologies initially developed for industries (such has the infamous Winston Royce waterfall model, which incidentally he never recommended). 

We were using methodologies suited for stable environments in an unpredictable world.

So the question that guys behind the Agile Manifesto really wanted to answer was:

How do you lead a project in a complex environment?

That is, how can you drive a project in a fast changing environment when all parameters become unpredictable?

In unpredictable contexts, traditional project management proves useless. It only offers techniques to increase predictability and can never be 100% successful.

The only thing you can do is to adapt to new events you couldn't predict. And you want to do so the fastest you can so that it doesn't cost you.

The purpose of all Agile methodologies is to increase your adaptability to change so that the impact of unforeseen events remains constrained.

Scrum is in fact trying to offer a framework that will make it easier, quicker and less costly for you to adapt to change.

For instance, the Daily Stand-Up is nothing but a tool to increase communication, so that you know about change the minute it occurs.

If, in the Backlog, you prioritize tasks according to their added customer value, it is in an attempt to keep project costs at their minimum. This way, if you need to change your plans (and you will), you won't be throwing away work you could have dispensed to do.

You could find similar benefits for all components of Scrum. One way or the other, they all help putting the project in a situation where change is easy, quick and not costly to make.

Now, it's pretty easy to understand why most Agilists recommend the XP practice of tests automatization.
Indeed, it's the best way to decrease the cost of quality when change becomes the norm.
With automated tests, your full work can be instantaneously checked. Defects introduced by change can be spotted at next to no costs.

In the end, I'm not saying we should never adapt Agile practices or that we should follow them all, quite the contrary.

As we've seen, in a complex system, you want to increase your adaptability and that includes adaptability of your tools.

What is important, is that you adapt your tools for the good reasons. 

Today, people look towards Agile methodologies as a way to increase productivity. 

Remember that at the heart, Agility is not about being more efficient.

The winnings in productivity (or costs) are only byproducts.

It is because you diminish waste (by being better suited to the environment) that you are faster, not because you increased the pace of execution.

So if you are looking at adapting Agile methodologies for productivity reasons you are probably getting it wrong (chances are you'll diminish your adaptability to change).

But if the adaptation you want to make actually makes embracing change easier, faster or less costly, then, by all means, feel free to do so!

"Science sans conscience n'est que ruine de l'âme" Rabelais, Pantagruel
"Science without conscience is nothing but the ruin of the soul" Rabelais, Pantagruel

Credits: Anthony Gatto by Dirk Franke

Climbing over the ladder of innovation

Not that long ago, I was challenged with the task of designing something innovative.

As you often do in such situations you collect ideas you've seen on numerous projects and see if you could bring them together in a new way. You don't try to reinvent the wheel, but rather to present existing things with a new twist that makes them interesting.

I thought I had done a good job of it.

I was wrong.

What I presented was not judged to be innovative enough and I was criticized over the fact that the individual elements I had used had already been seen before.

But then I asked myself: what is innovation?

Is it still possible to think of something that would be ground-breaking? Something never seen before?

On the 4th of July 2012, the CERN announced it probably had discovered the Higgs Boson that was predicted in 1964.

Despite the Boson being called Higgs, after the british physicist Peter Higgs, you may be surprised to learn that Higgs wasn't its inventor.

Or rather, he wasn't alone.

The mechanism conducting to the existence of the Higgs Boson was in fact proposed by several physicists at about the same time.

Indeed, Wikipedia credits several physicists along Peter Higgs for the discovery (R. Brout, F. Englert, P. Higgs, G. S. Guralnik, C. R. Hagen and T. W. B. Kibble).

Incidentally, not only this theoretical discovery was a shared discovery but also the concrete discovery of the Higgs Boson itself is a team work.

To find evidence of the Boson, scientists used particle accelerators such as the Tevatron at the Fermilab and the LEP (later replaced by the LHC) at the CERN.

Such accelerators are huge pieces of engineering. 

In fact over 10,000 scientists and engineers from over 100 countries worked on building the LHC responsible for the CERN's discovery.

Discovery as it seems, isn't the matter of one person anymore but rather a collaborative work by brilliant minds all around the globe.

For the story, that doesn't prevent such events to be a fierce competition between scientists! Since the LEP had to be shut down before the LHC could be operational, people at the CERN were in fact quite worried that their colleagues at the Fermilab would make the discovery. The willingness to be the first was strong enough that, just before they shut it down, they went as far as pushing the LEP beyond its designed limits in the hope of catching the Higgs Boson.

You could think that collective discovery is a recent phenomena due to the development of communication and the easiness of sharing knowledge almost instantaneously.

You would be wrong.

In 1439, Joannes Gutenberg, contrary to what you learn in school (or at least to what I learned), did not invented printing.

What he did was improving over existing techniques (namely movable types, ink and screw presses) so that printing could become a mass market product.

Thomas Edison did not invented the electric light bulb. He perfected it, making it long-lasting and practical.

I'm sure you could find numerous other examples and you probably have your own.

My theory is that invention as such does not exist.

I consider it something made possible by a succession of steps above which you build so-called "new" things.

It is not that much about being innovative than it is about being creative.

It is not that much about having a stroke of genius than it is about looking at things differently.

I believe it's about assembling existing elements to build the unexpected.

Did you know that there are more than 915 million possible combinations for six 2x4 LEGO® bricks of the same color?

Credits: Fotolog Bureau Robin, http://goo.gl/Z8VS8

Gaming on the go, press pause

Mobiles expanded the video game market to a whole new audience.

People who didn't use to play suddenly started spending a huge amount of time playing on their mobile devices.

Angry Birds from Rovio Entertainment was downloaded by more than 1.7 billions people (yes, you read it correctly, billions...).

Quite impressive knowing that a game reaching 1 million sales can be considered a best-seller. All the more taking into account that there isn't more than a few such games a year.

But apart from changing consuming habits, mobiles introduced some important variations in the way we interact with games.

Good mobile games make those inherent to their design.

The main two are quite well known:

- shorter playing sessions ( a few minutes compared to half an hour and more on console games)

- more frequent sessions (as often as 10 times a day on games relying on energy such as city builders)

Apart from that, there is an important concept that I found to be too often overlooked by designers.

Mobile gaming is, guess what, mobile...

That is to say that people playing will be in situations where they can't give their full attention to the game.

They may be in a bus, paying attention not to miss their station.

They may be walking in the streets, having to watch for traffic.

They may encounter friends and pause to say hello.

All kind of situations where they are not watching their mobile screen.

There are lots of ways for a designer to take that into consideration, but what I prefer is what I call "the never ending pause"

It's really quite simple and can be done with one rule only:

Nothing should ever happen within the game without player interaction

This means that whatever action that has been planned into the game will only happen at a suitable time for the user.

It means I can look up and check the next bus station without fear of loosing.

I am not penalized for not giving my full attention to the game.

When you think about it, that's a big difference from hardcore gamers' titles.

That doesn't imply fast-paced action games cannot exist on mobiles and Real Racing 3 does a pretty good job.

But while, at times of writing, it is ranked 31 among top grossing apps in the French iPhone App Store. It is ranked 6 on iPad.

Meaning it is better ranked on the device used on the couch, in non-mobile situations.

Remember Angry Birds?

This is a nearly perfect example of a "never ending pause" (you could argue, that some Birds require interaction after you shot them. Given that's about 1 second of your attention though, you can safely consider it a "never ending pause").

Still not convinced? Check the iPhone App Store top grossing rankings and just count non-action games.

At times of writing all the games from the top 10 grossing iPhone French App Store are non-action games...

Credits: Original design by N. Lochet (based on Space Invaders start screen)

We don't need no Scrum Master

I see more and more comments from Agilists complaining that, more often than not, Scrum Master is yet another name for Project Manager.

Agility (and Scrum) promotes self-organized teams.

In such teams there is no hierarchy.

Team members organize themselves as they wish and efficient communication ensures it works.

Self-organization and communication are the true roots for emergence, something all Agilists should aim for.

Contrary to that, traditional projects are hierarchically organized around a Project Manager.

He is the leader of the project and team members report to him or her.

He is the only one to decide about the organization and the processes followed by the team.

The task is daunting. When you add control over the dreaded tryptic of quality, budget and schedule, you can guess what usually happen...

As widely quoted, 1994 Chaos Report from The Standish Group shows a shocking 16% rate of success among IT projects.

Their figures are much debatable, as proves J. Laurenz Eveleens and Chris Verhoef article, "The Rise and Fall of Chaos Report Figures", published in January/February 2010 issue of IEEE Software, but you get the idea.

If you have a minute or two I widely encourage you to read it.

If you ever wondered why statistics do not show much sign of an improvement over the past few years despite the wide adoption of Agile, there is your answer!

You may guess that with such heavy duties, project managers have long been a role of great importance in organizations.

When IT projects costs millions, it's no surprise (and I dare say quite natural) that you want to be sure to have the best control you can (now you understand why some fear self-organized Agile teams).

The quick rise of Agile put all those guys at risk. What is their value if teams no longer have a leader? What if people start self-organizing? Would they have to quit?

But as said, they are smart...

Soon enough, projects managers started becoming Scrum Masters.

Nothing had changed, only the title.

Brilliant, but when you think about it that could have been predicted.

Why is it that Scrum invented the role of Scrum Master but for providing a role for former project managers?

The Scrum Master is there to vouch for the good use of the methodology, has final say on backlog elements, and keep trackers up-to-date.

But when you think about it, why would you need that?

Isn't a Scrum team self-organized?

When I coach Agile projects, I encourage the teams to switch roles so that the Scrum Master is not always the same person.

It helps people both to embrace the methodology and to start self-organizing.

It's rare to truly reach a state where the team is self-organized, but for such teams:

We don't need no Scrum Master...

Credits: Original design by N. Lochet (based on The Wall CD cover and Scrum Alliance logo)

Xbox One, despite the bashing why Microsoft could really well have won the war.

People love bashing. There always have been companies who, for one reason or the other, have been a designated target for criticism.

Usually the larger the corporation, the bigger the bashing. 

Google used to be cool, now they just are the internet Big Brother we wish we could avoid. Even Apple, now that they are not anymore under the protection of a Steve Jobs, are not immune to critics.

Bashing is fun and social. Aiming at the same target as millions of others, we feel part of a superior community, looking down on others and being the only ones to have the holy grail answer to all questions.

Given that, Microsoft has, not surprisingly, been a favorite target for bashing since quite some time.

The recent announcements regarding Microsoft's Xbox One at E3 have given people a lot of ground for criticism. Video game journalists and internet forums all conclude that Sony has won the war and that Microsoft Xbox One is a stillborn product. 

Or is it?

I don't want to comment on Microsoft communication and I'm not going to speculate whether or not it was done on purpose.

Gamers mainly complained about three things: the always connected enforced policy, the new controls over pre-owned and the console price tag.

Microsoft stroke off the first two. 
Most should have been happy, but being the social haters that we are, we bashed them for not being consistent...

Now, I don't know if the Xbox One development followed Agile process but sounds very much like Agile to me.

Remember what the Agile Manifesto says? 

That there is more value in:

- Customer collaboration over contract negotiation

- Responding to change over following a plan

Isn't that what Microsoft just did?

They don't suddenly believe that being connected do not offer extra value or that the pre-owned market shouldn't be controlled. 

But they realize it is better to cooperate with their audience rather than entering heated discussions. Better to adapt than to follow a plan nobody wants!

Granted, the price tag remains.

I'm not giving all that much importance to that for three reasons:

- Release is still a few month away and there's still plenty of room for a price adjustment if need be. I can't seem to find reliable figures, but with a war chest above 60 billions dollars, they certainly have the financial room to allow it.

- Most day-one buyers are hardcore gamers and price elasticity is traditionally quite high for early adopters. And yes, of course, price will decrease over time...

- When released, back in November 2006 (March 2007 for us lucky europeans!) the PS3 was 599€. That did not prevented it to meet its audience. 

At 499€, you could call the Xbox One a deal (even more when you take inflation into account).

Xbox One and PS4 actually have pretty similar hardware.

In fact most of the price difference can be pinpointed to the Xbox One motion recognition technology, Kinect 2.0, being included in the base pack.

Kinect 2.0 is Microsoft evolution of its motion sensor technology first introduced in November 2010 on Xbox 360. It will be precise enough to read lips, recognize emotions and even strength you exercise.

Now, has past history has shown (remember the Sega 32X?), no peripheral will get wide developers' support unless being part of the original bundle. Indeed, in times of increasing development costs (and stable RRP), why would you limit your audience, that is to say your potential market, to a fraction of the whole?

By removing the Playstation Eye from the PS4 bundle, Sony actually kills it as a mainstream development platform.

Gamers have always been attracted by impressive graphics and in this regard both consoles offer solid choices.

However gaming has much evolved over the past few years. Mobile gaming and freemium products have changed the way the larger audience consume entertainment.

Not all people are hardcore gamers, Kinect 2.0 promise of natural interactivity could really well be the right argument for the mainstream.

I don't know if Kinect 2.0 will be a success. It certainly has the potential. Its promises of natural interactivity is well in line with people demands for simplicity.

What's certain though is that from a developer's perspective, Microsoft made the right move by adding it to the bundle.

Credits: http://www.xbox.com