This blog has moved. Go to SoftwareDevelopmentToday.com for the latest posts.

Monday, February 22, 2010

We need Proof!: Talk at Agile Saturday in Tallin

Last week I had the honor to present the keynote at Agile Estonia's first public event. Agile Saturday was full of people from that community and it was great to learn how that community is being developed.

The organizers also filmed the event, so here is the link to my talk video and slides.

Enjoy!

Agile Saturday #1 Keynote by Vasco Duarte from Anton Arhipov on Vimeo.



Labels: , , , , , ,

at 09:07 | 1 comments
RSS link

Bookmark and Share

Saturday, February 13, 2010

We need proof! For a better understanding of our business, without religious arguments


Whenever you hear someone talk about Agile being better than X or X being better than Y don't assume they are right. Ask for proof.

For many years our knowledge and society at large have advanced through the tried and often questioned, but always upheld view that it is not sufficient to merely claim something convincingly to have it accepted. Sure, in politics that happens all the time, but would you trust a politician to pilot the next aircraft you fly on? I thought so... It is not enough to be convincing or to tell good stories, you actually have to know what you are doing!

The point is that our knowledge, human society's knowledge, evolves by having many people look at the same issue, over and over again, doing experiments to prove an hypothesis and then learning from it.

An important point in this context is that success in the experiment is not needed to learn and advance knowledge. Failure in the experiment often yields as much learning as success would. Take the most famous failed experiment in history:

The Michelson–Morley experiment was performed in 1887 by Albert Michelson and Edward Morley at what is now Case Western Reserve University. Its results are generally considered to be the first strong evidence against the theory of a luminiferous aether. The experiment has also been referred to as "the kicking-off point for the theoretical aspects of the Second Scientific Revolution".
-- wikipedia


It was, in part, thanks to this experiment (a failed experiment) that we got the theory of relativity, arguably one of the most important advances in science in recent times.

But there are more examples of how science delivered progress. How it created knowledge that helped create the world we live in today.

What does this have to do with Agile SW development? You ask. After all, that's why you are here, right? Well, it just so happens that Agile SW development and our SW development industry have a lot to learn from science and the scientific process. We have to start taking the responsibility for the development of our craft/art/science.

Despite all of the buzz about agile, we don't have much in the form of evidence for us to say, yes agile is the way to go. Don't get me wrong, after having worked in this industry for 12 years and with Agile software development for 6 years. I would not want to go back. But as an industry we are making transitions to agile SW development that cost us millions of Euros every year. Most of those transitions will have been the result of a successful visit by a high-flying, expensive consultant that told us some stories we already knew we wanted to hear.

Are we betting our industry on a bunch of stories? Do we want to fly in that plane piloted by a politician?

I refuse to believe that's what we want to do. I refuse to believe that we want to go and bet our entire industry on a bunch of unsupported ideas that some good story tellers have come up with! I want facts, I want the evidence. I refuse to believe without seeing the evidence.

So, if we chose to be coherent with the growth of knowledge as opposed to the beauty contest that the Agile consulting world has become, we must start questioning the received knowledge that Agile "just works". The statement "it works for me" is utterly useless if what we want is to learn and to improve! The fact that it worked once for someone and that led to a successful consulting career has no statistical significance! Or do you believe that the waterfall consultants don't say the same? Of course they do.

So this brings us back to the key question I want to raise in this post: "How can we improve the state of our industry in a consistent, long term and sustainable way"?

The answer, which should be clear by now, is in the numbers. Or as a famous person once said: "show me the money!"

Show the numbers as they are so that we can have a conversation about the real results and can learn, ultimately improve.

Feel free to add your data to this blog post. I hope this can be the beginning of the real advancement of our industry. Show us what you learned, we will show you what we learn, and from this a conversation can emerge that will hopefully take us forward, make us more professional, deliver more value to our customers.

Share the data. "Show me the money"!

Photo credit: mr.beaver @ flickr

Labels: , , , ,

at 13:00 | 2 comments
RSS link

Bookmark and Share

Saturday, February 06, 2010

User Stories are representations of a conversation, not a list of requirements!




Great post by Martin Fowler about a hidden aspect of the User Story flow within a team. 

Many times I see teams that expect the Product Owner to behave just like a Requirements manager did in the past. Come up with the content, put it in the tool and stay out of the way! That's wrong!

In this article Fowler calls our attention to a key aspect of Agile SW development: the fact that it is a constantly ongoing conversation between the team (that implements) and the person/people that hold the product's vision (typically: product owner):

This notion of product owners coming up with DecreedStories is a profound misunderstanding of the way agile development should work. When we were brainstorming names at Snowbird, I remember Kent suggesting "conversational". This emphasized the fact that the heart of our thinking was of an on-going conversation between customers and developers about how a development project should proceed.


Photo credit: jakuza @ flick

Labels: , , , , ,

at 20:24 | 0 comments
RSS link

Bookmark and Share

 
(c) All rights reserved