Monday, June 18, 2012

Code quality Vs productivity

I will not discuss the importance of code quality, we all agree that having code quality is a very important thing in any project. Recently, our manager has decided to take into account KPI's for code quality. Is this a good idea?


Monday, March 5, 2012

The man-day and the story point relativity.

In scrum, we no longer calculate the total work in a "static" way, we rather use a relative approach, the size of each story is calculated based on other stories. Usually the smaller story serves as a baseline to calculate the rest.

This is an excellent way of making progress visible, depending on how many story points you burn per sprint, you can see when all stories could eventually be finished. Measuring work this way also helps business see what is the impact of them changing their minds by adding or reducing scope.

It also helps in giving a comparison between sprints, knowing if you're improving or, inversely, reducing your velocity, thus allowing the scrum master to take proper action.

But in every project there is a very important variable, budget. So, how you convert story points into budget needed for your project, or better, can you?

Tuesday, February 14, 2012

The Agile Tester

Analyze, develop, test, deliver .... still sounds familiar?

Getting rid of the waterfall mentality is difficult within some roles, specially when it comes to testers, they will always tell you:
 "How can I test, this is not finished, the story is halfway done, there is no point in me testing anything!"
 Well, actually there are quite a few...


Monday, February 6, 2012

The Agile Analyst

When I first said there was no need to do up front analysis, I was looked at as if I was totally crazy...


"Developers can't think! they need to be told what to do, they are mostly Junior, they do not know the application, it's the first time they work here !"... 


I still have to see a developer that found use for an analysis done before the beginning of a sprint.

Friday, February 3, 2012

Agile Product Owner

The product owner, the person that wants your team to provide him with a working product.

In most corporations linking Agile to Business strikes directly to one's mind as an oxymoron. Business takes ages to make a decision, most of the time they do not know what they want, and more often than not, they just expect IT to deliver what they want in time and they forget about it until the release date is upon them.

So how do you convince them to get involved into an Agile process?

Wednesday, February 1, 2012

Closing the water taps

Waterfall...or is it "Waterfail"?

Since the first time I've been in contact with a project, there has always been one single common factor for each of them:

Failure
(bigger or smaller, but always failure)

Scrum in a big corporation

I started as Scrum master less than one year ago, I'm working in a big Telco company in Europe with no previous scrum experience.

As soon as I was introduced to the Agile philosophy and the scrum methodology, I felt completely identified with both.

Quickly, I was given the chance to become Scrum Master for a team within a bigger team of Web developers, suddenly I became a sort of guide in something I had very few experience with! On top of it, our projects are pilot projects to asses the value of Scrum within the corporation.

It is still a big challenge, learning the inner workings of Scrum, the good, the bad, and then facing the stiff resistance of some of the more ancient guys in the team and the corporation itself.

In this blog I would like to share with you my experiences, my success stories, and of course my failures.

Maybe some of the entries will help you not make the same mistakes I'll be doing through the challenge, of course, your input is very much appreciated!

Have a nice day!