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.
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.
No comments:
Post a Comment