Karmængine

…

You can tell which GAACs have no clients by observing their activity on the GAAC mailing list.

… that is all…

… was pretty good, but the case studies were like a ‘case’ of taco-bell-expulsion.

Overall I felt that the summit was great, and a lot of information was circulated to those who could stop bloody twittering for five seconds to listen.

I really don’t understand 70% of the people who attended the summit. That 70% sat through every single day with their laptops open – blogging, tweeterizing, facebooking, skyping, etc. The guy in front of me was litteraly writing Twitter stuff like “I am sitting in the GAAC summit listening to Avinash.” Well, no, you stupid twerp, you are not listening to anything, you are wasting your company’s money and using pointless antisocial media tools in order to increase the size of your ego. And by golly, you would bloody realize it if you actually WERE paying attention.

And yes, there’s me, advocating actually paying attention, meanwhile observing the person sitting in front of me instead of the actual speaker. Classic, eh?

But it really riled my nerves to see so many people who ‘live’ on web 2.0. You are all a bunch of vegetables. If you have 200 friends on facebook and spend all day telling them what you’re doing – I think you’re pathetic (and damnit NOT becaue you ‘only’ have 200 friends on Facebook!!!). If you’re spending thousands of dollars on attending a summit at Google, and your activity there is limited to describing the free food you get on the internet  - then, I think you’re worthless as a human being.

Thanks to all who created the summit. I personally got a lot of value from it, and I hope the format doesn’t change much for next year.

… Stop it.

Good Evening.

A question, if you’ll permit me.

What happens at the end of every single day?

Answer: Sunset.

And, what happens at the end of every Sprint, grasshopper? Something beautiful, multi-coloured, and romantic?

No! What happens is hectic, important, and the most valuable things which Scrum has to offer.

That is:

• Retrospective meeting(s)
• Deployment of completed work

That’s right. The time between Sprints is the only moment of the development cycle which is important to me, the product owner.

But why do I make this outrageous statement? Because I’m interested in value. I am interested in what new features I can give the users, and how we can improve the team’s performance for the next sprint.

I don’t care what the team does during the sprint. They can play monopoly on the ceiling wearing chicken-suits and it won’t make me worry. They could establish their own company selling exclamation marks on ice cubes; it would make no difference to me. What I care about is what happens at the end of the sprint. I expect results, and if the team produces them, they are making me happy. I am ecstatic if they then find a way to improve themselves for the next sprint.

So, dear scrum practitioner. If you feel that your product owner is ‘looking over your shoulder’ during sprints, and poking you in the fork to keep you visibly working – tell him/her to get stuffed! The result is what the product owner should be interested in, and the process should only be addressed during the retrospective meeting, which occurs outside of the sprint.

If you’re going to be prodded in the gullet by anyone during the sprint, it should be your Scrum Master.

These days, when you pay for CPC traffic, you set a bid for the click, and the advertising engine, using a bunch of wild and whacky factors, awards the click to whoever’s bid is the highest.

That bid is only partly a monetry value for Google. Some of it is Quality Score – which is Google’s interpretation of how valuable your site is for the person who might click. Other engines are squeezing themselves into this model too, lately.

But, as a CPC marketer, do I care about the value to the visitor? No, I care about the value to me. I want to get the best quality visitors, because they will make me the most money.

The whole CPC model can be approached from the other side – that is, awarding the click to the advertiser who will get the most value from the click.

How can this be done?

Well, for starters, I can put it another way: I would pay more for visitors who are more valuable to me.

How can this be measured?

It seems the most classical way to describe visitor value is by directly linking it with revenue produced by this visitor. That is, if he clicked, did he then go on to convert, and if so, for how much revenue?

How do I get more money?

What if the CPC engine understood that some of your traffic converted, and other traffic didn’t – then reduced the cost of the non-converting traffic, increased the cost of the converted traffic, and meanwhile adjusted their targetting system to maximize the amount of conveting traffic, and minimize the amount of non-converting traffic?

Such technology is already in use. With Google? No.. Bing? No…

In fact, none of the major search engines are using such technology.

So who is?

Well, look towards the largest affiliate neworks and you’ll find an answer.

Product Owners come in most shapes and sizes. Some of those shapes and sizes don’t quite fit into the development process – and here’s some suggested points from which you can conclude whether or not you have a dud PO.

You have a dud P.O. if:

• The P.O. doesn’t come to the Sprint Planning Meeting.
• The P.O. comes to the planning meeting without a crystal clear idea of what needs to be developed next.
• The P.O. estimates or influences the team’s estimates for stories.
• The P.O. commits the team to the work, instead of the team committing to the P.O.
• During the Sprint the P.O. interrupts each developer several times a day to ask “how’s it going?”
• During retrospectives the P.O. is the only one talking.

Now, of course there are other points, but these seem to be the most revealing. But how to ‘do scrum’ with a dud P.O.?

Should you?

Yes. You should.

The P.O., no matter how much of a dud he is, is still an important part of the process. At worst he is still a human shield to protect the developers from the stakeholders.

A pitbull of a stakholder, shaking with anger, asks: “You developed an unusable pile of crap! Who’s responsible?”

“The Product Owner!” they all shout, pointing their wavering fingers at the P.O.

At best, he is the sphere around which the whole development cycle revolves.

Don’t.

To me, there’s not confusion on how to handle incomplete stories – and yet, there is a huge range of different approaches hanging around in the Scrum community.So, I’m going to address some of the common claims being made.

Some people make claims that you have to credit some ‘done’ story points.

Ridiculous. Scrum is not a game – you don’t ‘get points’. Story points are not awarded. They are a measurement of scope. “Congrats, you win fifty centimeters” is about what these people are saying.

So no, there’s no credit – and to make an even plainer point – if a story is not done – it is not done. I don’t know how much simpler this could be.

Remedy your brain by:

• Revising how you think about story points.
• Getting/revising your Definition of Done.

Some people claim that you can keep the same estimate for the story

Yes, insane people. Put it this way. If I am asked how long it takes to fill my bucket, and I say one hour, then after one hour it’s three quarters full – should I really answer with ‘one hour’ when I’m asked again how long it will take to fill? No, damnit. And this is not rocket science. It’s filling buckets!

Be wary – the re-estimated value could be either higher or lower than the previously-estimated value.

Things to remember:

• The story was not completed, therefore it’s not done.
• Factors relating to the reason the story is not completed should be discussed during the retrospective meeting.
• There could be either less work remaining that originally estimated, or there could be more work remaining.

The bottom line

Simply put:

• Story not completed? No story points completed. Simple.
• Work to be done? Estimate it.

Mr. Ronald E Jeffries is trying to drum up support for a certification process for agile developers, because, “Ken Schwaber, co-creator of Scrum, says publicly that perhaps only 25% of Scrum teams get the full benefit of Scrum.”

Now, the real point he’s trying to make here is that his bank balance is could do with a top-up.  That’s my initial view. But that’s highly cynical.

1. Ron (and others) believe that Scrum and other Agile practices only get their real value if the practitioners are fully trained and ‘know how to do it properly’.
2. Those believers in certificates think that the only way to use a tool properly is to get a certificate saying so.
3. Certification process will not be free.
4. Developers mostly don’t care about whatever methodology is followed to give them things to do.
5. Ron and his mates will be the certified teachers of the course, and therefore be certifiably lining their own pockets.

With these points in mind I cannot help feeling that this is just a growing trend from the Scrum Alliance to earn money from people who want to ‘do Scrum’.

We already know about their claims to the words ‘Scrum Group’ and the financial implications that has.

I suggest we break the bonds and free Scrum from the evil clutches of these money-oriented swindlers.

I mean, what’s next, Scrum Certification for Testers? Trademark on the word ‘Scrum’?

As Tobias Mayer says: I believe the idea of a “certified developer” has nothing to do with Scrum. Scrum is not a software methodology, not a prescribed way of working. It is broader than that. Scrum is a framework for “transforming the the world of work”. It is “…an iterative, incremental framework for developing any product or managing any work”. Creating a certified software developer certificate will push Scrum into a tight corner where it will not be able to grow to be all the things it is capable of being. I find that to be very sad.

Yes, let’s break the bonds. Someone start the ‘Free Scrum’ club please.l

Dramatic title, I know.

The point I wanted to make is that in more traditional software development, you would have a scenario like the human body. There would be the eyes which send signals to the brain, the brain which interprets these signals and controls the arm, which controls the hand, which makes the product.

Now, though, we have Scrum. There is no central lump controlling everything.

There are still eyes, arms, and hands. But, the hands are not told what to do. They decide for themselves what to do, based on what the arm says is possible to do. And so on up the chain.

Scrum has no brain.

And yet, the very point I’m making is that scrum practicioners are blessed with the opportunity and requirement to think for themselves.