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.

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.

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.

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

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.

And which do you choose?

Well. It depends. It depends on who is ordering the meal, and who is standing behind the chef with his notepad and a stern look on his face. It also depends on what ingredients you have in the larder.

So, do you want to be a Product Owner or a Product Pwn3r?

What’s the difference?

Well, here’s a hint. One plays the role, and the other creates the role.

More to come…