I often get asked about my job and what in the world it means to be a ScrumMaster. So I thought it’d be worthwhile to take the time and explain both: Scrum, and my job at CR as a ScrumMaster.
What is Scrum?
Scrum is a project management framework which is especially suited for software development projects. Most big hitters in the software industry such as Yahoo!, Microsoft, and Google are taking up Scrum (or something similar to Scrum) as the framework in which they manage their software projects. Scrum’s also seeing a large uptake in the financial sector. Check out the Firms-using-scrum-wiki to see just how pervasive Scrum has become.
What makes Scrum different from other project management frameworks?
Traditional styles of project management involve long phases or steps through which a project moves over its life-cycle. During my senior year at CSUS we spent two full semesters walking through a classic SDLC (Systems Development Life Cycle): Planning, Analysis, Design, Build, Test, Implement (and Maintenance). In theory, the project would move linearly through each phase in a single cycle. The desired result is a well documented and fully functional application.
Scrum is going to argue that the above model breaks down when the requirements are not fully understood and will likely change and morph throughout the life of the project. By the time the project has moved through each phase and is delivered to the customer, it may not look anything like what they had originally envisioned (think of the whispering telephone game we all played as kids).
In essence, Scrum takes the entire SDLC and calls for a small, cross-functional, and well-disciplined team to compress it into short iterations (cycles) called sprints. A Scrum team on two week sprints will attempt to deliver slices of shippable functionality to the customer every two weeks. A sprint will have concurrent analysis, design, and testing, always taking into account the changes and feedback given by the customer(s) at the end of each sprint. In this sense, compared to traditional methods, Scrum is much better suited for software projects where customers often don’t know what they want until they see it and play with it.

The above diagram by Mike Cohn (from whom I received my ScrumMaster certification) illustrates the cyclical fashion in which Scrum teams take building blocks of functionality and iterate through them to arrive at a shippable product. A traditional SDLC might better be illustrated as a Waterfall (its nickname), in which each phase of development represents a step in a cascading waterfall.
What Mike taught me about the role of a ScrumMaster:
In Waterfall, it’s the Project Manager’s job to stand behind the team, crack the whip, and ensure delivery. The PM identifies the tasks, deliverables, timelines, etc, and then dictates to the team the manner in which they will deliver. In most cases, the PM is an authoritative figure to whom the team reports and answers. Mike refers to this style of management as Command & Control.
A ScrumMaster is the exact opposite of a PM. The ScrumMaster is described as a servant-leader / facilitator as opposed to a figure of authority. Scrum encourages team ownership, self-organization, team mentality, etc. For example, a ScrumMaster doesn’t give the team deadlines, the team gives the ScrumMaster their best estimates. Some examples of ScrumMaster duties:
- See that the team follow the Scrum framework (various processes, meetings, templates, etc)
- Encourage scrum-like behavior (team mentality, team ownership, cross-functional disciplines, etc)
- Facilitate the team’s ability to deliver software — this can mean anything from ordering lunch to chasing down requirements.
- Represent the team to outside stakeholders (such as management, customers, etc). It is my job to know how the team is doing, their timelines, their impediments, and what they need going forward. Often this aspect of my job is manifested by numerous meetings outside the team — which in turn leaves them free to get their work done.
- Examples of ScrumMastery things I’ve recently done for my team:
- Having a background in development, I knew how productive having dual monitors can be. When I saw that the majority of our developers were stuck on single monitors, I put through a request for dual monitors.
- We were having a hard time keeping track of our sprint tasks in our project database. So I wrote a web-based reporting application which sends nightly emails to the team detailing their progress, alerts, status, impediments, etc.
- I noticed the team’s countless administrative documents were scattered across messy shared folders. So I revitalized a single team homepage (wiki) with clear navigational links pointing to all necessary bits of information and documents.
- Besides being the organizer and facilitator of many team meetings, I’ve facilitated the creation and adoption of many team standards and practices which are both Scrum related and development focused.
- Resourcing — procuring CV’s/resumes, setting up interviews, etc.
A traditional Project Manager may do much of the same, however, the philosophical difference is that the PM often feels it’s their job to come up with the solution and enforce implementation; whereas the ScrumMaster solicits the team for their solutions and facilitates the agreed implementation.

So what are we actually building?
Rumor has it that many of the supermajors (CR, Shell, BP, etc) are in the process of leveraging business intelligence (BI) to better manage their energy assets. Our team is one of many in CR who are developing such applications. The accompanying diagram does a great job of illustrating BI and how it applies to the oil field.
Basically, we are creating fancy web-based dashboards which display aggregated data in real-time (or near real-time) from our assets. Our system translates data from various sources into useful information which is then displayed in aesthetically pleasing charts, graphs, reports, etc. The technical challenge comes in the integration between legacy (old) systems and our cutting edge Microsoft (MOSS 2007) powered interface.
It’s proven to be somewhat challenging, but the potential payoff is quite rewarding when you consider the previous system(s): disparate excel spreadsheets, aging applications and delayed reports which often involve a degree of time-consuming manual labor.
Credit goes to the amazing pool of talent we have on these projects. As intangible as the ScrumMaster’s output may appear, I’d like to think we play an important role in the process! 🙂