Is the scrum agile methodology a great success or a horrible waste of time?
About two years ago, Pica9 introduced the Scrum framework as a way to implement the Agile methodology. The Agile Manifesto offered more efficient means for developing software, and we wanted in. We started small with just one engineering team and, like water seeping into crevasses, the framework practices found their ways to all other engineering teams (heck, rumor has it that some Scrum techniques even leaked to non-engineer teams). We religiously adopted all the bells and whistles of Scrum: daily standups, a task board, two weeks sprint cycles, user stories, retrospectives, etc. We track, we evaluate, we learn and we improve processes in an ongoing manner. In multiple surveys, we found that our engineers are all much happier with the Scrum practices as a way of tracking work and “doing” work - it feels good. Yet, as the person responsible for the introduction of Scrum, I recently wondered: Is Scrum a waste of my time?
As the teams got better at Scrum practices, we saw improvements in various areas. Tracking the progress of work is easier and more transparent, we are able to switch quickly to new tasks as business needs change, and the inspect-and-adapt feedback loop has improved our processes -- enabling us to adapt new ones and drop or optimize the mediocre ones.
However, in one critical aspect Scrum does not help. Scrum does not offer any guidance of what work should be done, and more so how should we judge progress beyond the ‘technical’ aspects of marking work as done? As a small company that is still optimizing it’s product functionality, deciding how to prioritize work is critical. How do we know we are making choices that are valuable to our clients? Sure, we get more work into the pipeline but to what end? Is it worth the effort? How can we be sure that using our human resources is creating real value for our users?
I started pondering these questions for a very simple reason: Scrum really does work. Before the adoption of the framework, the efforts of completing, testing and deploying code consumed so much energy that -- to a large extent -- completing the work became the goal. Whether it brought value to customers or not was an afterthought. For me, Scrum enabled ‘seeing’ the work, and by seeing the work clearly, I started questioning the value of each prioritized effort. It became very clear that we can do work that is valuable or invaluable, but how could we know which type we were spending our time on? I also started questioning the role of developers as code writers. What lessons were they learning and what interactions should they have with our clients? Was I wasting my time, their time, and company resources by just ‘doing’ work and not measuring its value to our end users?
While I had numerous doubts, there are still a lot of positives regarding Scrum both for the teams internally as well as for our clients. The framework allows engineers’ days to be more consistent, and as a result clients’ requests can be attended to fast. There are very clear start and end goals, and communicating progress to our internal and external partners has become a breeze. Additionally, work which directly comes from clients is now scheduled and processed in a very clear manner. Scrum is good for us, and better for our clients!
About a month ago - whether by serendipitous wind or pure boredom – I happened to stumbled on Eric Reis Book ‘The Lean Startup.’ In the book, Eric tries to systematically answer some of my questions with respect to valuable work! Needless to say, I made a cup of tea and started reading! In my next few blogs I’ll explore what I have found, and how I’m planning to integrate these findings to my team, and into my company.
