We don't need software engineering religion, we need software engineering science!

During the Scan-Agile '09 conference there was a lot of discussion about why Agile works and if a specific flavor of it would be better than other flavors (you know, the Scrum vs Kanban fight).

Despite those surface issues, there was a deeper debate going on. Why does Agile work? And in what context should we use certain practices? The essence of this dialogue was, in my view about what we really understand or know about Software Development.

Many of us came to Agile from different backgrounds. Some of us are closer to the development disciplines (testing and coding), others are closer to project management/management or product management.

The common thing is: we believe, based on our experience and observation that Agile is a better way to develop software. But why is that so? Where is the evidence, and what parts of it work in certain contexts?

The core of this dialogue is about science. We need the scientific process and scientifically proven theories to learn. That's how we learn as a species!

That's why I found this presentation so important. Even if I disagree with somethings that are stated there. The debate must start, we must stop practicing blind religion with our industry. We need to get scientific!

Hopefully many of you agree...

Bits of Evidence

View more presentations from Greg Wilson.

Opera Mini 5 is the king of mobile browsing, proof inside

In a discussion with @james_cooper and @iramo on twitter we came to argue about the performance of some mobile browsers.

Now, if you are anything like me you hate propaganda as well as deceptive advertising.

I raved on twitter about Opera Mini 5 (which I think is the best mobile browser out there, bar none!) and @james_cooper made a comment that stopped short of making my blood boil.

I'm as much of a fanboy as anyone else, @james_cooper will testify to that, but when I rave about a product I do it for a reason.

So I took @james_cooper's challenge head on and went on to do an extensive performance test with a couple of web-sites that I visit often to prove that @james_cooper and all other Apple fanboys are just wrong and that we (the Opera Mini fanboys) are right! :)

So. First the result: I hereby crown Opera Mini 5 as the best, fastest and most responsive mobile browser of our times! And I have the data to prove it (not just fanboy-ism).

Test Method

I loaded the main page of the list of web-sites below on Thursday October 23rd around 21:00 EET. Each page was loaded at least 5 times. Some pages were loaded 6 times to account for the first load time being too long (due to the overhead of creating a connection).

All browsers were in devices that had wifi connection except for the S60 v3.2 browser because the device I had did not have wifi.

The times measured were from the moment the user presses "go" (or "go to") to the moment that the browser stops downloading and rendering. All browsers in the test included very clear visual queues that let the user know that the page is fully ready for browsing, so this was easy to measure.

Also, in the devices that allow for multitasking, all other applications were closed in order to allow for a fair comparison with the iPod Touch 2nd generation that I used which itself does not allow any other application to run at the same time as the browser.

Devices in test

• Nokia N97 with Opera Mini 5 Browser
• Nokia N97 with native browser
• Nokia 6730c with native browser
• Apple iPod Touch 2nd generation with OS 2.1.1 and later with OS 3.2.1

Sites visited for the test

• www.techmeme.com
• www.nytimes.com (not tested with all browsers because there was no way to make the server return the full desktop-version of the site)
• www.hs.fi
• www.engadget.com
• www.natgeo.com (not tested with all browsers because there was not way to make the server return the full desktop-version of the site)

Most of the sites included some scripting and flash adverts.

Test Results Overview

There was one thing clear from all of these tests. Opera Mini 5 is much, much faster than any of the other browsers. Opera uses what they call "proxy" which basically means that the browser will connect to specific servers that Opera manages and those servers will compress the data to be transferred to the browser making the amount of data to be transferred considerably smaller than the full HTML+FLASH that other browsers have to download. This makes Opera much faster on the download, but Opera still needs to render the same content and here Opera excels again.

Opera clearly blows all other mobile browser options tested out of the water. Here are some examples (times in seconds, error margin +-1 second)

	www.techmeme.com	www.nytimes.com	www.hs.fi	www.engadget.com	www.natgeo.com
N97 with Opera Mini 5	best: 7 sec worst: 8 sec	best: 9 sec worst: 12 sec	best: 11 sec worst: 23 sec*	best: 7 sec worst: 9 sec	best: 6 sec worst: 9 sec
Nokia 6730c with Native Browser (over 3G)	best: 19 sec worst: 19 sec	only mobile site available	N/A	best: 13 sec worst: 16 sec	best: 10 sec worst: 13 sec
iPod Touch 2nd Gen with 2.1.1	best: 24 sec worst: 24 sec	best: 27 sec worst: 28 sec	best: 34 sec worst: 36 sec	best: 20 sec worst: 21 sec	only mobile site available
iPod Touch 2nd Gen with 3.2.1 (test not completed)	best 38 sec worst: 47 sec	N/A	N/A	N/A	N/A
N97 with Native Browser	best: 36 sec worst: 47 sec	only mobile site available	N/A	best: 16 sec worst: 27 sec	N/A

* includes time to create a connection as the device had no active connection to the network at that time
N/A: either the device did not render completely the site or the test was not done for the specified site
Only mobile site available: There was no obvious way to request the full-website from the server through the mobile-site interface. Test could not be carried out.

Conclusion

If you actively use your mobile device to browse the internet, there's only one conclusion to take from this test: get yourself the Opera mini 5 Beta and stop worrying about the native browser. Opera has consistently beaten all others to the punch and even though the test was not on the features, it is clear that the Opera Mini 5 Beta is a feature-rich browser that puts all of the native browsers to shame.
I have, just like all of you have, heard how cool mobile safari is and how it has this crazy good WebKit engine... Well, Opera Mini 5 is Java (yes!) based and is still miles ahead of the competition!

All I can say is that I hope that the mobile browser wars does not end like the PC browser war ended with one crappy browser built-in into every OS/device.

Here's the link to the Opera Mini 5 site. Go there and start enjoying a proper desktop-like browser on your mobile device!

PMI vs Agile, the debate continues

Prompted by a comment by Murray on my first blog in this debate I wanted to expand some of the ideas that have not yet been explored.

Here are the key excerpts from Murray's comment:

PMBOK V4 is compatible with and supportive of Agile processes. Here are some relevant quotes from CHAPTER 2 − PROJECT LIFE CYCLE AND ORGANIZATION

"There is no single way to define the ideal structure for a project"

"it is up to the project manager and the project management team to determine the most appropriate method of carrying out the project"

"There are three basic types of phase-to-phase relationships:

• A sequential relationship (...)

• An overlapping relationship, where the phase starts prior to completion of the previous one (...)

• An iterative relationship, where only one phase is planned at any given time (...)

The PMBOK v4 is quite recent and I have to admit I'm not familiar with it.
However, PMBOK v3 completely omitted the discussion about phase-to-phase relationship in the way described above.

Another aspect that is seldom discussed is that in IT projects (specifically Software Products) we are very quickly distancing our methods from the project-concept. In companies where I've worked, projects no longer represent in any meaningful way how the company works.

Another caveat is that Linear-iterative projects (like RUP proposed) are significantly different from the Incremental-iterative project structure that Agile methods in general and Scrum specifically propose.

All in all, there are significant differences that warrant a very skeptic look at what PMBOK has to offer.

If you want to check some other views into why the "project" pattern is not necessarily useful for software product development take a look at this blog post by Ari, who has quite a long experience in product companies: "Focusing on projects ruins your business"

Photo credit: Dunechaser @ Flickr

We have Open Space for learning at Scan-Agile

I've been in many conferences, and without an exception the best part of every conference was the time I had to talk 1-on-1 or with a few people about some subject that really interested me.

This normally started in the hallways, during the coffee breaks. We started talking and suddenly we realized that we had just missed the start of the sessions. The conversation would go on and eventually some of those would continue over dinner.

I've met more people during conferences this way than by any other method. Conferences are excellent for this. You have lots of people with the same interest in one place, start talking and before you know it you have found people with which you can discuss the most difficult problems you've faced. Sometimes others pitch in with a solution, sometimes you just get a bunch of friends that share the same interest.

This effect, of getting to know people you did not know before, is what we are trying to create in this year's Scandinavian Agile Conference. That's why we have an Open Space (aka Open Space Technology) day in our schedule. Open space is the format that allows for the best networking to happen.

In the Open Space anyone can suggest sessions in the morning's "marketplace of ideas". This means that those people are committed to host a 50-55 min session about a specific subject. That does not mean that they want to explain the subject. The best Open Space sessions I've been in are those where the host just asks a question and the conversation flows from that.

For those more technically inclined an Open Space session can be an opportunity to explain a hard technical problem you are facing and have others pitch in to help you solve it or explore possible solutions that you were not aware of.

The Open Space sessions where I've participated have all been excellent learning opportunities for me, but some have been breakthroughs! Most importantly, in each Open Space session where I have participated, I've been positively surprised how people that may be reluctant to participate at first, end up participating actively and having lots of fun in the process.

Come to the Open Space in Scan-Agile. Listen. Teach. Meet your community!

You can start building your Scan-Agile community today! Just go to Twitter and use the tag #scanagile. All of us on twitter will be able to find you and, who knows, maybe even create a joint-Open Space session before the actual Open Space day!

Come on, join the community!

Photo credit: Peter Kaminski @ flickr

What can Science teach us about Agile? (or why you must come to Scan-Agile)

I'm sure that you've heard many things during your life that made you think: "Boy, that guy/gal doesn't get the basics of (put your favorite subject here)".

Well, there's a reason for that. People make assumptions and claims that are false because they have a faulty model in their head. They simply don't know better!

For example, Aristotle made a claim that we now know is ridiculous: "objects of different weights fall at different speeds". That's just plain wrong!

How come a serious, intelligent guy can make a claim like that? What makes us make false claims and sometimes even live according to those false principles?

Aristotle could have easily known that different weight objects do fall at the same speed. He would just need to take two rocks of different weights and drop them a few times from a high place and measure the arrival of the two stones. He would have found that there's no difference. The two rocks fall at the same time.

It took more than 500 years to discover this simple truth. Galileo proved that objects of different weight do fall at the same time and he established Gravity as a constant force with a precise value.

Why am I talking about this in a software blog? Because in the software industry we still have a lot of Aristotles running around and telling us that rocks of different weights fall at different speeds!

In the Scan-Agile Conference we will have an academic session where presentations from different researchers and Universities will try to make us understand what is true or false based on concrete research. We will have our own Galileos to tell you all about the latest findings in research.

For example:

• Dr. Nilay Oza from VTT Oulu will present results related to aligning Innovation and Agile Software Development.
  
• Dr. Burak Turhan from the University of Oulu will tell us a dirty little secret about TDD. The truth is that we don't yet know what the impact is. You'll have to attend the session to find out what he means by that!
  

Among other sessions we will have a panel lead by Pasi Kuvaja on the status and direction of Agile Software Development. You can expect some news from this panel. Don't miss it.

There are other very interesting sessions in the Academic track.

Check out the full schedule at www.scan-agile.com/schedule and when you are ready go and register here.

Photo credit: jurvetson @ Flickr

Why learning is *still* so important (or why you should attend Scan-Agile '09)

Last year I wrote a very personal story about how learning made a huge difference in the life of two people of similar age and in a similar context.

Check out my story about Grandpa Tony and Grandpa Frank (BTW: it's a real story!).

So, this year I thought of finding a different way to talk about how important it is to learn continuously to ensure our best options to survive in our jobs.

I'll pick a few sessions from the Scan-Agile '09 conference to explain how you can actually use what you will learn in those sessions to improve your skills and your career.

Let's take the example of the workshop "Executable Requirements in Practice" hosted by Pekka, Juha and Janne. In this session you can learn about one of the most important practices in SW development today.

Making sure that you continuously develop software that meets needs that are identified throughout the life of a project is a basic success criteria. How do you do it practice? And how do you do it in a way that does not transform the test specialists into click-robots?

Executable Requirements is a simple term to describe what tests should cover in practice: Requirements. Executable because we need to be able to run those tests 100's of times in a typical project and people are not very good at doing the same thing 100's of times, therefore we need to have those in a executable form to be able to run them over and over again.

In this session Pekka, Janne and Juha will explain how they've actually done it! Not theory, but experience.

In many aspects their work is quite unique world-wide and we are very lucky to have them present this in Scan-Agile. Look-out for this "Executable Requirements" to become a trending topic in Agile circles and come to Scan-Agile '09 to learn all about it!

Check out the complete schedule here and register here.

Photo Credit: David Den @ Flickr

About when I stopped worrying and embraced Engineering!

Product Managers often forget that they can make or break a project. If your team is using Scrum that is even more true, because Product Managers are (or should be) involved regularly in the planning of the work with the team. Either as Product Manager or in the role of Product Owner.

It is therefore very important to carefully craft the messages that the Product Manager gives the team. It took me a while to understand this simple message, and this is my story.

As a Product Manager I was eager to give the team direction and clarity on the goals for the product. I communicated regularly with the team with more information on the market, the product, the customers and generic feedback on the direction they were taking.

Eager to achieve the goals we had set for ourselves the team was churning new features at a very good pace. Then the bomb hit. Every time we were supposed to go to production we faced major hurdles. The Retrospectives did not point to anything that could cause the quality problems we had, so I went on an investigation. Why was deployment to production so hard to this team that was delivering features at such a good pace (uncommon for other teams at that time)?

As a Product Manager I had to forget about what I wanted and had to concentrate on finding the root-cause for the problem. I interviewed the developers but nothing I found would explain the situation. The team was testing regularly in their environments and they were practicing Scrum "by the book".

It was then that it hit me. Having a conversation about the development process with one of the developers I understood that they were neglecting their unit and integration tests, which in turn led them to have a long feedback cycle for integration (some days only, but still too long).

After I heard that, it was fairly easy to trace the deployment problems to the lack of automated, fast-cycle integration testing. In their eagerness to deliver more features the developers would be developing up to the last day and would not have time to do the integration testing for those last changes. In turn, that led to many problems when it came to deploy.

Through that conversation I realized that the problem the team had was that they were being implicitly rewarded for delivering more features every time I praised them about the new feature they delivered. However, they were not being rewarded for building the unit and integration tests that would prevent the quality problems.

The end result was that quality-sustaining practices were being neglected. Having understood that, I changed my communication with the team. From that time on I started asking them if they had the integration and unit tests for every feature they delivered and started giving them praise for delivering tested features, not just any feature.

Before this happened to me I was not aware of how strong an influence the Product Manager's message can have on team behavior. "They are the engineers" - I thought - "they should know what they need to do". It's not that simple!

Photo credit: pcalcado @ Flickr