Rethinking Agile Methodologies Part II: Scrum, but
In the last post, we looked at how I got into Agile and Scrum. Today we will take a look at how I started to break the rules.
After reading the Agile books by Ken Schwaber and obtaining my Certified ScrumMaster credential, I doubled down on Scrum at my start-up since it was working so well. As things progressed and our business evolved, I started to bump up against the “rules” of Scrum.
As I mentioned last week in Part I, the guidance was to only use Scrum locally, not with offshore developers several time zones ahead. I was also breaking many other “rules” most notably the sprint length, at that point the length was supposed to be one month, but I was using one week. I also changed the daily scrum to late in the day for the developers and inverted the questions to:
· What did I do today?
· What will I do tomorrow?
· What do I need from you?
We also had a very small team so we dispensed with the formal sprint retrospective and did it continuously. Then the big one hit. A business requirement came down where we had to develop thousands of Regular Expressions (RegEx) for sites that we spidered. Each RegEx would be considered a work item in our backlog. They came with a spec from the business (what to capture) and the end result was a few RegExes as rows in a database. We had to produce massive amounts of RegEx patterns so we hired a ton of “regex developers” or college kids in India looking for extra money.
We managed our backlog pretty easily but I struggled with applying the rules of Scrum to this process. Typically a developer would take the next highest high priority items from the backlog, work on it for a few hours and return it. They would work on two or three of these a day. I tried doing a daily scrum but it was boring for all involved. (Today I worked on RegEx. Tomorrow I will work on more RegEx. I need more Regex!) Also time boxing our iterations to a month did not make sense. We had to “release” or upload the patterns to our sider engine farm daily.
I asked Scrum experts and consulted the blogs and they all said not to change Scrum! They kept on about cross functional teams, a sprint backlog, 30 day sprints, daily scrums, etc. It was then when I decided that I would just apply the values of Agile and some features of Scrum to my process. I was labeled a “Scrum, butter” by Ken Schwaber (he even did this publically many years later at TechEd 2010.) I went back to the Agile manifesto and looked at the original four values:
· Individuals and interactions over processes and tools
· Working software over comprehensive documentation
· Customer collaboration over contract negotiation
· Responding to change over following a plan
I looked long and hard and realized that the current Scrum experts were too rigid. Scrum boxed me in and when I had a business need that required some creativity, I was not able to use Scrum. So I ditched Scrum and what I wound up doing was using an early form of Kanban. (More on this in the next post.)
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)