Last week I had the chance to attend a training sessions related to the Scrum Methodology that was taught by Michael James from CollabNet. I had been searching for a while for someone who was not only knowledgeable in the real world application of Scrum, but I also wanted someone who could provide me with insight into why I had experienced some failures when utilizing this specific Agile approach to software integration and design. Mr. James has an outstanding reputation that met both of my criteria so I signed up for his class.
Unfortunately his class was only two days long. I would have loved to have learned from him for five days, but that was not one of my options. While I am well read on Scrum and I have both participated in Scrum teams as a Product Owner and lead teams as a ScrumMaster, I never really felt comfortable with the process. For some reason there always seemed to be some sort of disconnect between our team the the intended outcomes of our efforts. It is sort of hard to explain, but if you have used Scrum to manage your SDLC or software integration, you probably know what I am talking about.
My personality is such that if I don’t know what I am doing in a particular situation, I spend the time to educate myself and acquire the skills needed to complete a task. But that never really worked with Scrum for some reason. But as I sat through the class taught by Mr. James, the weaknesses in my “game” if you will were exposed. I started to understand why some of my projects were not being completed as quickly or efficiently as I thought they could. After all, doesn’t Scrum remove the perceived BS of project management and strip it down to its bare bones?
I already knew the processes, but I was missing some of the more basic points of Scrum implementations. By missing the fundamentals, my projects were not completed as quickly or nimbly as they could have been. Here are the two fundamentals I missed:
- Projects are approached vertically and not horizontally. While this is a fundamental in Scrum, I think unless you attend a training or apprentice under someone who knows what they are doing. This was my mistake. On my teams we tried to apply Scrum horizontally, meaning we would build the framework in the first sprint, code in the second sprint, test in the third, and so on. This is using scrum principles in name only. To properly use Scrum, you need to produce a shippable product or feature at the end of each sprint. That is applying the methodology vertically and when you do this, Scrum will produce the flexibility you need to successfully deliver the product your client wants.
- Product Owners have no real power. This is a huge problem and can be a major impediment to successfully using Scrum to manage your development process. C level executives need to empower the Product Owner who is assigned to the project with clearly defined decision parameters. This should also include budgetary decisions. If the Product Owner is more of a product supervisor, your team will not have the direction required at the moment of decision, which means it will slow way down and your team will get frustrated. A frustrated team is a slow team.
If you want to use Scrum to guide the SDLC in your company, you need to have everyone buy into the methodology from the very beginning. It represents a deviation from the traditional project management styles of most companies and does not produce the same metrics executives like to monitor the progress of the project in achieving its goals. I would suggest if you are looking to transition to Scrum, have everyone who will be involved in the process, including the C level executives, watch this video that Mr. James developed to educate on the essentials of Scrum.
Is training in Scrum principles worth the money it will cost you or your company? If you take a course from Mr. James at CollabNet or another reputable company, I would answer with a resounding yes. To realize the benefits of Scrum, it must be applied and implemented correctly and completely. The best way to educate yourself is by sitting and listening to an expert who has been there and done that.