Two days does not a ScrumMaster make!

This Certified ScrumMaster is Still a Grasshopper

While I do have experience in what did and did not work for my situation, I was having a difficult time trying to find the right way to employ Scrum. I was looking for the right methodology, the proper technique, the right tools, the best framework; in short, all the wrong things.

What is Scrum anyway?
After meeting Victor Szalvay, CTO and co-founder of Danube, who was one of the trainers at my certification class, I started following his blog. In a recent post,Victor called attention to Ken Schwaber's definition of Scrum. Ken's point is that: "Scrum is really simple, barely a process, more a framework. The hard work in using Scrum is fixing the things that it exposes, actually inspecting the things that it makes transparent and adapting to optimize the results and the organization that produces the results."

It Doesn't Take An Einstein To Figure This Out
As Einstein said, "Everything should be made as simple as possible, but no simpler." Scrum itself is very simple. Yellow sticky notes and, as proven by the second trainer at my class Tobias Mayer, black electrical tape are about the only tools you need to Scrum. You can start simple, with four columns on a wall, board, or paper; the Backlog Item, the tasks of that backlog item, the work-in-progress, and what's been completed. In other words, Item (e.g. Use Case or Story), Tasks, WIP, Done. Go Scrum!

The Hard Part of Adopting Scrum
If Scrum is really that simple (and it really can be), then why isn't everyone doing it? The reason is again a simple one: The results which come in implementing Scrum can be really, really, really painful. How is it that such a simple process can produce so much pain? I believe it's another simple answer: Empowerment.

When you empower a Team to do whatever it takes, to make their own decisions, to remove all obstacles from the path to their goals, to set them free to do their work, you're going to feel the pain for awhile. It may be in the form of great discomfort at "letting go" and "second guessing". I know that pain personally. I used to be a by-the-book, and I mean a large book, of standards. I used to personally eyeball every line of code. I would sit on meetings and make the decisions because I felt there needed to be a one-voice, centralized responsibility and control, consistency, etc. After a very ugly and bad dose of being on the wrong side of that for almost two years in a contract, I came away with a very different perspective. On my most recent job, I took the point, but in a very different way.

My job is now to facilitate, to see that the Team has everything they need to get achieve their goals, and to remove any and all obstacles as quickly as possible. The daily decisions of implementation are theirs. I even took another step in empowerment recently by turning over every administrative password to every server to every team member. They need the flexibility to get their jobs done. Has there been pain in implementing this process? Absolutely! Would I willing go through the process again if I had to? You bet, no questions asked, in a heartbeat!

I'm currently managing several Department of Defense (DoD) contracts in my work at MTS Technologies, Inc. This Team, in just under two years, has built a robust, open, flexible, extensible Medical Knowledge Management System for the Navy and Marine Corps (NMKMS or NavMedKMS). There are still a lot of political hurdles and challenges, but we have made a significant contribution! The system is currently staged with the 1st Marine Expeditionary Force and the Army recently stepped up and requested the system for their own evaluation and use in-theater operations. As the Army put it after their initial evaluation, "you just put us two-years ahead of our own schedule." Would we have received that praise if we had not empowered the Team? Perhaps, but considering that there are several other initiatives who have done this or tried to do this in a centralized fashion without using Scrum, I honestly do not believe we would be where we are today.

Pain free Scrum
Now that I look at the Team's progress and Ken's statement, I can state without reservation that the pain is not in the Scrum process. The pain associated with Scrum is in dealing with the issues exposed by empowering a team to do whatever it takes to accomplish their job. Scrum itself is painless and once you've been through a few Sprints, the pain greatly diminishes as others begin to understand what to expect and productivity can go through the roof. It's well worth the effort, IMHO, to implement a Scrum process. Once you've empowered individuals to come together as a team and stood behind them with full and unwaivering support, there's nothing they cannot or will not accomplish! In a few short Sprints, you can be relatively pain free and Scrumming with the best of them!