1. Make a business decision without consulting the partners in the business.
2. Find a buffoon who has never heard of Agile and make him Project Manager.
3. Task the Project Manager with making the business decision a reality, using the Product Owner’s team.
4. Don’t brief the development team or the Product Owner on the situation.
5. Put a distance of half a continent between the Product Owner (and team) and the Project Manager.
6. Watch as the Project Manager drowns the Product Owner with outdated waterfall documents and processes.
7. Watch as the Product Owner tries to stay afloat and keep the Scrum process happening.
8. Watch as the Project Manager contradicts himself as he struggles to employ waterfall properly.
9. Watch as the Project Manager fails to understand even the basic principles of Agile methodology.
10. Watch as the Product Owner struggles to meet the waterfall requirements in the Scrum environment.
11. Watch as the Product Owner lacerates himself on the rocks at the bottom of the waterfall, pulling the team with him.
12. Watch as the Project Manager follows his Gantt chart like a blind man with a guide-stick, and tries to demonstrate the product which wasn’t made to the company owners.
13. Listen as the Project Manager points fingers, blames, attacks team members on a personal level, and tries to play the Scrum Master against the Product Owner.
14. Listen as the Scrum Master gives in and allows the Project Manager to dictate deadlines and content of sprints.
15. Watch the mutant team stretching themselves around ’scrumfall’ methodology.
16. Listen as the Project Manager burns everyone’s ears with stories of his own success.
17. Watch as the team grows hatred for the Project Manager.
18. Watch as the Product Owner abandons the company.

Did I mention the word ‘buffoon‘? It doesn’t feel right to limit the description to a single word, but, as I’ve learnt, using many words to describe nothing is one of the traits of such a person.

Before too long we were all seated around the table-tennis table in the meeting room.

“Where’s Artur?” somebody asked, and a peal of giggling erupted from Dima following a joke involving the toilet and food from the local shop.

Artur entered  the room some minutes later, to be shunned by more comments and witty remarks. He quickly stepped out and returned again, grinning and carrying a chair.

Spreading the printouts in front of him, Erik began. “So, we have some stories here from Jacob. And maybe Jacob can explain the business value of these stories to you all briefly.”

Jacob explained the stories, what the value of implementing them is, and provided examples on how such features would be used.

The team listened, downcast, with barely a comment and seemingly little interest. Erik interrupted a few times to ask important questions such as ‘Why?’, and ‘Do we need it?’, and these questions were duly answered.

Ending by collapsing the house of cards Artyom had been building beside him, Jacob handed the stories back to Erik. Now it was time for a proper, in-depth analysis and discussion.

Tuning in and out as the developers argued, complained, and worked out technicalities in their native Russian language, Jacob remained in the meeting, hiding behind a laptop and carrying on with work.

From time to time the discussions became heated between Artyom, Erik, and Artur, with Andrey taking the more gentle approach of never-say-anything-unless-directly-asked-something.

After a lunch break a further three hours was spent getting estimates and planning the work. Numbers and English notes were written all over the stories, with fancy circles instead of dots above all the i’s.

“Ok Jacob we have estimated everything. In hours. But that doesn’t matter we have story points as well.” Erik said, suddenly switching back to English. “And, ah, we have thirty-four story points up to here,” he indicated his notes. “So, question is, do we do up to here or do we move something away and go till here?” again he indicated his notes, asking not just Jacob but for a commitment from the team in general.

It was clear from Jacob’s angle that there would be several new features worked on, regardless of which ‘here’ the team targeted. It was clear, too, that Erik was pleased with the team’s estimation work.

“It’s really for the team to decide.” Jacob said, looking around at the tired faces who sat around the table with their estimating cards in various patterns and logical piles in front of them.

“Well team?” Jacob said. “You tell me! I am not here to say how much work you should commit to, but I will say that last sprint we did thirty story points, and this sprint we have Erik working with a bit more velocity…” He let the thought hang in the air for the developers to either duck away from or grasp for themselves.

Switching to Russian, Erik said something to encourage the team to decide something. This went on for several minutes, before Erik announced that the team would target twenty-eight story points, instead of thirty-four. There was a general murmur of acceptance from the rest of the team.

Stretching, yawning, and pleased to have reached the end of the meeting, the team shuffled out of the room.

Tomorrow, the sprint would begin.

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

… that is all…

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.

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.

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.

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.

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.