Diary of a heretic Scrum practitioner
Dear diary, I have a terrible secret. I do not believe in Scrum Methodology.
You see, I have been practicing Agile and Scrum for the last 10 years. I read the gospels and I can recite the Agile prayers from memory. I happily enjoyed many of Scrum’s blessings, until recently, when I joined a new company that follows a slightly different Scrum denomination. First I did not make much of it, in the end, Scrum is very liberal and we are often told to do whatever works for the team. Except, this time nothing worked for the team and I hat to ask for help.
I looked for salvation inside the company’s Agile Temple - I spoke to Scrum Cleric after Scrum Cleric, but the more theory I learned the more confused I was. One day the High Hierophant could not take my questions anymore and arranged for me to attend a Certified Scrum Training organized by Certified Scrum Preacher from the holy Scrum Alliance (.org). I was thrilled to get a new certificate for my CV, paid for by the company!
But it did not go well and I am the one to blame. Imagine this: just when the preacher started singing a gospel to the advantages of Scrum, I asked — in from of the whole congregation — if there is an empirical evidence for Scrum being superior to other methodologies. Empirical evidence!
I can not say I did not learn anything: I always knew that Agile works differently for everyone but now I also know that if something does not work it is because my company does not really understand Agile and did not implement it on all levels of management. Which is, of course, true, I am not trying to deny that my projects usually contain legal and contractual requirements, which is against Agile. Because, you know, when you need to test specific requirements, you need specific Acceptance Criteria, instead of defining requirements only as Conditions of Satisfaction. Acceptance Criteria are not (N)egotiable!
What does not help either is that our Scrum Team is not self-organized and not cross-functional — our managers stubbornly prevent teams from self-organizing and no matter what we do, the lazy QA people will never write good code. So we at least mix the QA guys’ velocity with developers’ velocity when planning for a sprint. And we ask them to estimate coding tasks too. At least our Scrum Team owns the Scrum Processes. I mean, we may not be allowed to change them, but owning is 90% of ownership, right?
But as I said, there is bad news too. I no longer believe and my stubborn head is the one to blame. You see, I have been splitting User Stories for 10 years now but I never understood the “Sprint Goal” and the “Delivering Value Every Sprint” mantras. More often than not, when we split a Story to be small enough to pass through a Sprint it ends up looking like a Technical Subtasks. Of course, we would never call it that. We would recite the “As a“ prayer and pretend it brings a Value to the Customer.
As a “company” I want to do this necessary programming task, so that I can deliver a useful feature in 3 sprints from now.
Now you can see why we struggled with meaningful Sprint Goal? It turns out we did it all wrong!
The solution is truly magical, but before I fully reveal it to you, let us chant the INVEST prayer together one more time. The canon says a good Story must be:
(I)ndependent, as in “…be able to schedule and implement them in any order…”.
(N)egotiable, as in “…not an explicit contract for features; … A good story captures the essence, not the details.”
(V)aluable, as in “We don’t care about value to just anybody; it needs to be valuable to the customer.”
(E)stimable, as in “We don’t need an exact estimate, but just enough to help the customer rank and schedule the story’s implementation.”
(S)mall, as in “Stories typically represent at most a few person-weeks worth of work.”
(T)estable, as in “…being able to test the Value, not the code, you silly.”
I was again trying to cause trouble, telling my Certified Preacher that my team repeatedly runs into issues trying to keep stories (V)aluable, (I)ndependent and (T)estable while breaking them down to (S)mall. (Now, you could be petty and say that almost no story is independent, because you can hardly implement any new User feature before you have implemented the User itself. But you would be wrong. The Preacher already said how to do it and she is not going to say it again.)
Anyway, here comes the magic: It turns out that you can split Stories into smaller pieces infinitely many times and they will still be (V)aluable, (I)ndependent and (T)estable. In other words, it can never happen that a Story is too big for a Sprint but breaking it down would make the pieces not Valuable to the Customer, dependent on each other or unable to test their Customer Value. The Preacher did it many times during her career and it always worked. I mean, how amazing is that? Scrum truly is a religion!
That being said, I lost my faith, because I do not know how to do miracles. What is worse, I cannot tell anyone but you, my diary. My colleagues believe in Scrum. My boss believes in Scrum and his boss does too. My whole industry believes in Scrum and I am not going to be the one to stand in front of everyone and tell them that INVEST methodology is self-contradictory.