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)

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

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