A Better Insight Into Agile and Scrum Roles

I’ve been attending a lot of meetups over the last few months and the one for the Pittsburgh chapter of the IIBA (International Institute of Business Analysts) was special because of the terrific speaker. A gentleman named Rick Clare gave a talk entitled “Debunking Agile Myths” that clarified some things I didn’t have an accurate view of. Here’s a pdf of the slide deck.

Scrum is just a subset of the Agile idea and I’ve always worked in an iterative way while gathering and responding to continuous feedback from the customer. The last company I worked for began some light experimentation with Scrum. The details of that situation gave me a potentially skewed idea of the requirements for the ScrumMaster and Scrum Product Owner roles, and those misapprehensions persisted through all of the training and certification classes and subsequent reading.

Ours was a small development shop with no more than two or maybe three development efforts going on at any one time, and with teams of no more than two to five members, many of whom are part time on any give project. The teams rotated across projects, generally not working on any one for more than three months at a time. The individual who took on the ScrumMaster role was also the head programmer, architect, and tool maven and set direction for pretty much everything that was done within the company. I therefore had the impression that this was a required skillset for ScrumMasters rather than simply being a champion for the Scrum process itself.

As a long time software engineer and architect myself, and as a systems analyst, simulationist, discovery and data collection analyst, and customer liaison I was the natural person to take on the Scrum Product Owner role. Most of the rest of the team were developers and analysts with two to fifteen years of experience, and very few of them were allowed to make decisions about architecture or tools.

As Mr. Clare worked through his discussion of ten Agile myths, most having to do with Scrum as he did not address Kanban, Extreme, or other areas, he gave me a new understanding of the requirements for the Scrum roles. Given that this was a meeting of business analysts he described how business analysis was a key component of performing all or part of each of the three roles. Some members of the development team clearly need to be developers, QA/testers, DBAs, and so on but BAs are clearly intended to serve in this role. The team has to have the requisite knowledge of tools, test and deployment methods, and so on, but this knowledge does not have to reside in the ScrumMaster or Scrum Product Owner; they are supposed to be primarily concerned with the Scrum process itself and the business needs of the organization.

I have been of the opinion that I should not serve as a ScrumMaster because I am not currently a guru in any organization’s end-to-end tool chain and methodology, which now seems like less of a problem. I have also felt that I just haven’t seen the Scrum process up close enough to serve in the role, which seems likely to remain an accurate view.

I have been suggesting that I should serve as a Product Owner because of my previous roles as an analyst, liaison, and architect, and also because I had served in the roles during our brief explorations. Of course, I was also a subject matter expert in POE (Port-of-Entry) operations and simulation within our company so that was reasonable for the situation. Mr. Clare explained that the role is best suited to a senior employee or executive that has a strong understanding of the business needs of the organization. This individual has to be able to interact with the development team, but perhaps knowledge of the business needs is more important than the ability to understand the details of what’s going on inside the development team. That said, one of the most important functions of the Product Owner is grooming the backlog, and I have been discovering, defining, negotiating, and managing requirements, change control and design procedures, and punch lists for most of my career.

This view is supported by an experience I had applying to a company I was introduced to through a friend. I applied for the Product Owner position only to learn, after a polite acknowledgment that my application was impressive but not quite what they were looking for, that the company expected the individual would be someone with previous experience developing SAAS (Software-As-A-Service) frameworks. I’ve certainly worked with numerous tools and frameworks, and even designed some light frameworks, and I’ve definitely worked through full-scale BPR (Business Process Reengineering) engagements and transformations, and I’ve even served as a Project and Program Manager in different contexts, but I had never combined all of those experiences in a single role the way that company was looking for.

I didn’t hear anything new about the Scrum process itself, the steps and ceremonies are pretty straightforward and there’s no part of it you can’t just look up in a book, class materials, or online. It’s all about the meta-process, working with customers, and solving problems efficiently and effectively, and I’ve been doing that for a long time.

So, what to do moving forward? Should I simply target BA positions, for which I am exceptionally well-suited, clearly, or continue to look for a break as a PO in the right situation, on that concentrates on simulation, process analysis, operations research, or some other area of concentration for me, or even a ScrumMaster in an even more rare situation? Time will tell, I guess. I’ll keep working, applying, and learning, and I’ll see where it goes.

This entry was posted in Tools and methods and tagged , , , . Bookmark the permalink.

Leave a Reply