Scrum: It’s a full-time job.

“An adequate ScrumMaster can handle two or three teams at a time...A great ScrumMaster can handle one team at a time.”

-Michael James

One of the lessons we learned early in our Scrum roll-out was that the Product Owner and Scrum Master roles required much more involvement than originally thought.  Coming from a Waterfall development environment, where releases were long in duration and milestones spread out, people in the organization were used to having key roles on multiple projects, context switching as needed.   Juggling responsibilities in a Waterfall environment seemed to work well, or at least acceptable.  Our Product Managers, for example, could own several product lines, including associated customer meetings and field interactions, and easily satisfy occasional project touch-points such as requirements definition (at the beginning of the release) and Beta and FCS duties (at the end of the release).  These project touch-points required their full-time involvement periodically, a few times a year, making it relatively easy to context-switch periodically and satisfy the needs of each effort.



With Scrum, however, things turned out a bit different.  Though we “took the training” and “read the literature” which repeatedly said the roles of Scrum Master and Product Owner were full time jobs, we weren’t true believers.  Our “muscle memory” way of working had everyone juggling multiple roles and responsibilities, it was the way we were used to working. During the course of our Agile Pilot projects, however, we got convinced pretty quickly that Scrum roles could not be part-time.

Scrum is more intensive than waterfall development.   

With frequent “potentially shippable product increments” created every 2-4 weeks,  there’s essentially a full product release at least once a month if not twice.   During our Agile pilots, our Product Managers, filling the role of Product Owners, soon realized that creating and maintaining a Product Backlog required a significant amount of time.  Every few weeks a new set of fully-defined “product requirements” need to be ready for the team for the next Sprint. Product Owners found it challenging to satisfying their Scrum PO role and concurrently complete other project work.  Our Scrum Masters, too, found themselves booked full-time, facilitating team interactions, producing Sprint Burn Down charts, working impediments, and delivering frequent product releases at regular Sprint Review.  Team members, often with other-project responsibilities, found themselves spending more time delivering on Sprint Goals, often at the expense of their other responsibilities.  

As we scale Scrum within the organization, we’ve (obviously!) needed to identify new Scrum Masters and Product Owners.  We’ve held fast to the one project per Scrum Master recommendation. Identifying new dedicated Scrum Masters has been fairly easy - our Pilot teams was that the efforts produced several Scrum Master candidates, a nice side-benefit!   Finding full-time Product Owners for each team was more challenging.  Because we’re applying Scrum to large multi-team projects, our mapping of Product Manager positions to Product Owners simply didn’t scale.    Our solution was to look to our lead engineers. Most of our new teams have technical Product Owners, usually Software Architects, and they are dedicated full-time to the team.  Product Managers are involved at either a co-Product Owner (in an outward facing role) or at a higher level in the project effort, via a Product Council-type role that involves them as stakeholders.  

I expect our organization to fine tune (via inspect and adapt) these non-Scrum roles as we mature in our Agility.  But regardless of the organizational “noise” around the Scrum Teams, I believe that participation at the Scrum Team-level will continue to require full-time effort from all members in order to be successful.

Scrum @ Progress

Earlier in 2010, my company began the process of defining a Unified Development Process for the 500+ engineers in the Product Group.  We formed a committee containing key representatives from across the product group. After extensive investigation and deliberation, the committee chose to focus on an Agile process, and in particular, Scrum.

What is Scrum and how does it fit within our Company?   

Scrum is a software development framework, and not a prescribed process. It’s a framework that focuses on cross-functional, self-organizing teams producing potentially shippable business value in increments called Sprints.   A quick Google search will uncover reams of literature on what Scrum is, with the Scrum Alliance has a nice short overview here: http://www.scrumalliance.org/learn_about_scrum.  

What’s important about this process effort is how such an Agile framework fits within our existing 25+ year old corporate environment.  On the surface it sounds simple:  educate the engineering teams, flip a switch or shout”on your mark, get set, go!” and voila!, we’re now Agile!  In reality, evolving from a Waterfall software development lifecycle to Agile is a monumental undertaking, but one that is, in my opinion and experience, worth taking.  

As part of the our effort, we’ve began running a number of Scrum Pilot Projects, projects in each division who have “volunteered” to build software using the Scrum framework.  I’ve had the good fortune to “own” one of the pilots and to also observe others.  Most of the benefits and challenges that I have observed during this process matched my own experience as well as those I have heard about from friends or read about from others in the software industry.  And some of what I observed surprised me.  I hope to capture these observations as the subject this blog, aptly titled “Agile making Progress”.

Scrum Roles

There are three roles that the Scrum framework identifies:  ScrumMaster, Product Owner, Team Member.  How the roles do or could fit into my company's Product Group is discussed below, ihowever it should be noted that every group, every product, has potentially different needs.

The ScrumMaster.  The ScrumMaster is the person who ensures that the team is functional and productive.  The ScrumMaster role can be viewed as the facilitator or ringmaster.  At my company the role of a GEM (General Engineering Manager, a project coordinator) may align well with ScrumMaster.  For the Pilot Tooling team, the pilot project that I own, we’ve got a great ScrumMaster who is in fact a GEM.  However, this shouldn’t be a hard and fast role mapping.  Other teams have ScrumMasters who are engineers, or even engineering managers (just not the manager of anyone on the team).  The ScrumMaster cannot hold a position of reporting authority over any of the team members.  On any team, it is very likely that the “right” person for the role will rise to the occasion - someone who is a facilitator or coordinator of the group.  With the pilots, sometimes the choice was obvious, as it was with the Tooling team, sometimes after a sprint or two, the team realizes that someone else on the team might be better suited as the ScrumMaster and the team adjusts, as happened with another Pilot team.

The Product Owner.  The Product Owner is responsible for the business value of the project, and represents the “voice of the customer.”  The PO is also identified as the “single wring-able neck”, having ultimate responsibility for the project.  On of the most important tasks for the Product Owner is for identifying and prioritizing the “stories” (release requirements) that the team will be working on. Here in in my company, one initial thought expressed was that a Product Manager should be a part of every team in the role of Product Owner.  In theory this makes a lot of sense.  In practice, however, it quickly becomes problematic.  We’ve seen in the Pilots that the user stories and product backlog require near-constant refinement (also known as “grooming”).  Additionally, some user stories are very technical in nature, due to the type of software we are building.  A high degree of low-level technical understanding has often pulled in a Software Architect to help with backlog grooming and prioritization.   The Tooling team found that the backlog grooming and story refinement regularly required deeper technical expertise. Scrum favors empowered and self-organizing teams, and a this team quickly readjusted to solve this need by making the Product Owner a joint role, shared between a Product Manager (outward view) and a Software Architect (inward, technical view).  To date that partnership has worked well over 4 sprints.  It will be interesting to see how the Product Owner role will scale within the larger organization where there could be a dozen or so Scrum teams working on the same product line.  Perhaps we’ll see some form of Product Council or co-Product Owner or a hybrid approach.  I look forward to seeing how each team self-organizes!

The Team.  The team consists of the people doing the work. As a general rule, the team should be cross-functional, because at the end of each Sprint a potentially shippable piece of software is produced.  For software to be shippable it must be written, tested, documented, packaged, and have training materials created.  As you can imagine, this generally means that you need Developers, QA, Doc and Readiness on the team.  The Scrum team is given the authority and empowerment to self-organize and do what they need to do to get the job done.  In return for this self-governing power, the business owner asks for a team commitment to deliver some level of potentially shippable software in a predetermined amount of time.  In other words, the team commits to implementing a some number of stories (requirements prioritized by the Product Owner) within some predetermined amount of time (generally 2-4 weeks - for the pilots it was 2 weeks).  Because I had a high level of confidence in Scrum to begin with, I wasn’t personally surprised by the (tremendous) output of the pilot teams.  I was surprised, however, by a higher than expected commitment by each Team to make this effort work.  This was Scrum magic, in my eyes.

Organizational Transformation

Due to corporate evolution, the environment I work in makes it hard for many us to focus on one project.   Because we’ve all got a number (often different) “top priority” work items, we must often time slice our attention across these efforts to achieve some level of success.  This strategy is at odds with Scrum, as Scrum requires a Team to commit to deliver an unchanging list of functionality, over a fixed period of time.  In other words, Scrum teams need unwavering focus on commitments they have made.  For a Scrum team to succeed, Business Owners (management) need to leave the team alone during that time-boxed sprint so that the team can succeed. Here, to me, lies the biggest organizational challenge.

The pilot teams demonstrated to me that even in the face of major impediments and overriding “external” priorities that they were able to “figure it out” on their own and make it work.  This is a good thing and gives me hope for the success of our ongoing organizational transformation.