How to Define Roles for a Product-Based SDLC
Published:Contents
- 1. Overview
- 2. What are the goals for defining roles in the softare development lifecycle?
- 3. Which SDLC roles should we define?
- 4. What does a product-based SDLC implementation look like?
- 5. Conclusion
1. Overview
Defining roles to promote an effective software development lifecycle (SDLC) can be an arduous task. Organizations often make the mistake of attempting to force thier existing structure into a pre-defined pattern. This can lead to unclear ownership over parts of the process and inefficiences due to increased communication overhead or unclear communication pathways. Often times, these deficiencies may not be realized until the organization attempts to scale their product delivery.
When tackling the prospect of rebuilding your SDLC pipelines, your organization should consider first the model they wish to implement. Ensure the model allows for scalability without increasing the overhead for everyone involved. Afterward, it should assign existing organizational resources, as applicable, to build a product team which follows the model, while hiring to fill gaps.
One such model is presented here, following a flavor of Agile development, dividing work between multiple business-supporting products.
2. What are the goals for defining roles in the softare development lifecycle?
Our goals with this model are:
- To clearly define ownership over various aspects of product delivery
- To clearly define responsibilities within the software development lifecycle
- To maximize scalability of a product organization
- To reduce inefficiency in resource utilization across the organization
3. Which SDLC roles should we define?
Ideally, each role should be filled by a different person, to maximize separation of concerns and to reduce competing responsibilities and interests within an individual.
Business Owner
The role of the Business Owner is to identify business problems and corresponding business metrics which should be optimized by the solving of business problems. A Business Owner often operates outside the day to day activities of the delivery team. However, it is is the Business Owner's responsibility to set goals for the overall business and to ensure funding is allocated to maximize the efficient delivery of those goals. Meeting these goals is the ultimate responsibility of the Business Owner.
Product Owner
In our SDLC model, the Product Owner owns the implementation of a specific product. It is their responsibility to ensure the product meets the goals of the business and to identify requirements for product modifications in order to satisfy business goals. This role works with Business Owners, analytics teams, user experience and design teams, and engineering teams to establish product requirements. They may also meet directly with or solicit feedback from users in order to find ways to improve the product. They are responsible for building and maintaining the product roadmap -- or the future vision of the project which will be accomplished over time. When work is identified for the product, the Product Owner helps to ensure that the proposed work is prioritized both internal to the product team and externally across other product teams. Ensuring the best customer experience for the product in order to meet business objectives is the ultimate responsibility of the Product Owner.
Engineering Manager
The Engineering Manager has responsibility to ensure maximally efficient resource allocation across one or more delivery teams. To do this, the engineering manager oversees the day to day operations of a delivery team, providing feedback to members on a consistent basis and helping to unblock issues that may arise during the course of implementation. The engineering manager helps to ensure that the technical solution to business problems satisfies product requirements and is built scalably and maintainably. They also provide a buffer between the delivery team and the product owner and program manager in order to reduce interruptions and churn for the members of the delivery team.
The Engineering Manager works with the Product Owner and Program Manager to prioritize work against realistic delivery timelines for the Delivery Team. When required, they work to fill vacancies within their team or identify resource gaps and the impacts of those gaps when generating delivery estimates. Prior to agreeing to work, the Engineering Manager will fully vet the product requirements, often working with a designated Technical Lead from the delivery team, in order to ensure the delivarables can be met.
Ensuring the most efficient and maintainable technical implementation of a product is the ultimate responsibility of the Engineering Manager.
Program Manager
The Program Manager has responsibility to ensure that business goals or projects spanning multiple products are delivered predictably and efficiently. All proposed projects must generally be presented with a proposed timeline and budget, spanning all of the products required to achieve satisfactory implementation. The Program Manager works with various Product Owners and Engineering Managers to ensure transparency in delivery, appropriate resource allocation across teams, and that work remains on track to hit agreed upon targets. If deviations to the project plan arise (such as changes in project requirements, business goals, or technological implementation details), the Program Manager ensures these details are communicated to stakeholders. The program manager often works as part of a Program Management Organization (PMO), which seeks to ensure consistent, repeatable process across program teams.
In SCRUM, program managers will often fill the role of SCRUM Master. This is not a requirement.
Delivery Team
The delivery team is composed of the individuals who will build, quality assurance, and maintain the product. They may be specialized within roles across the technology stack -- such as service and front-end engineers or quality assurance automation engineers.
Caveats
This is only one model of many that may work. Organizations can be different in their needs and in their available resources - from people and skills to budgets. However, we should caution against being dismissive of establishing SDLC roles.
Our goal is to develop an efficient process that minimizes overhead and promotes the most efficient use of our organization's resources. As such, when defining the roles of an SDLC model -- even this one -- is important to accept the realities and to provide adequate planning and reasoning. This way, you can be assured you are using your people and their time to maximum effect.
4. What does a product-based SDLC implementation look like?
For each of the following roles, we will consider a team which is seeking to improve the conversion rate of a Product Display Page (PDP) on an e-commerce site - LovelySofaCushions.com.
Identifying the problem or opportunity
Working with internal analytics teams, external vendors, or through market intelligence, the business owner determines the business problem: the conversion rate (or the total number of customers completing a purchase divided by the number of people who visit the website) across LovelySofaCushions.com is low compared to close competitors. Based on this analysis, the business owner sets a goal of increasing conversion by 5% to fill the gap (Figure 4.1).
Figure 4.1
This will be one of many goals set by business owners representing the business. These goals will be weighted against one another to determine which will return the most value for investment.
In order to determine the investment, the business owner needs to determine the approximate cost of projects which will support this goal. To do so, they will work with the project managers.
Identifying Solutions to the Business Problem
One or more business owners will communicate the goals they have generated to the product owners. The product owners, bearing the ultimate responsibility for individual products, will gather details from customer feedback, engineering partners, product analytics, or personal insight to generate potential solutions to the problem (Figure 4.2). These solutions might be enhancements to the customer experience, new features for a product, or identifying and fixing existing production issues impeding customers.
Figure 4.2
For our purposes, let's say that our product owner -- who owns the Product Page for LovelySofaCushions.com, has identified three potential changes to be implemented.
- Customer feedback suggests customers would like to see the product displayed in the selected color.
- The engineering team has discovered an error occurring on 1% of "Add to Bag" events.
- A product recommendations component is rendering at the top of the product page and pushing the product hero and selections below the fold on some devices.
Scoping, Identifying Requirements, and Estimating Delivery
With these three changes identified, the product owner now works with the engineering manager to determine scope, requirements, and estimates.
- scope is the sum total of the systems, processes, and experiences which will be impacted.
- requirements are the specific changes which will be implemented.
- delivery estimates are the time and effort expected to be needed in order to deliver on the requirements.
The first pass at scope and implementation details comes from the engineering manager based on the product owner's initial requirments. They identify the broad technical details required for implementation. They relay these loose estimates to the product manager, who refines the requirements. This process continues until the product owner and engineering manager both have a good understanding of the work to be done. (Figure 4.3)
At this point, the manager will bring in members of the delivery team to provide high-level estimates, often directional rather than guaranteed. Depending on the structure of the delivery team, this might be the entire team or one or more tech leads. Tech Leads are generally highly-experienced individuals who help lead the day-to-day software development within a team or part of a team. Regardless of which members are working on the estimates, the delivery team provides their own estimates of effort and risk and ask questions they may need answered in order to implement the requirements.
Figure 4.3
After discussions have reached a consensus, the product owner will determine the priority of each.
For the three areas identified in the previous section we will keep high-level scope, estimates, and requirements to the following:
- In order to implement color selection, the business will need to purchase a broader license with our image server vendor, the process for the merchandising team will need to update the process when taking photographs, and develop the front-end logic to change the color of the item shown in the image hero to match the selected swatch. This is a large effort across multiple teams and there is a moderate risk that unexpected issues will arise.
- The engineering team believes they know the root cause of the 1% Add To Bag failure issue. They believe there is a race condition in establishing a commerce-platform session when clickig the Add to Bag button. The fix appears easy, but there is a moderate risk that there is a deeper issue at play.
- Lastly, moving the recommendations section to appear after the product hero and selection is a small, low-risk change.
Prioritization
Unfortunately for any business, the number of resources available to complete projects is not infinite. We are limited by both time and skilled team members. And so, prioritization must take place.
The first round of prioritization happens at the product owner level. The product owner has received requests from multiple business owners, product leadership, and engineering. These must all be balanced by which can be achieved with the least amount of dedicated support (the least cost) and which will have the largest benefit (the highest return).
Our product-page product owner has initiatives competing with the conversion rate enhancements. There are also requests to change the color scheme of the product pages, a low-effort initiative, and to add product videos to the page, a medium-effort initiative. Our product owner, prioritizes them like so:
- Color Scheme: The color scheme change will take one resource about one sprint. It is an easy win and will help the company stay on brand.
- Add to Bag Errors: The engineering team is already working to fix the Add to Bag issue. They expect it should take two engineers no more than three sprints. This should increase the conversion on the product-page by 1%, and the product-page accounts for roughly 95% of conversions on LovelySofaCushions.com. This will increase total site conversion by 0.95%.
- Product Recommendations Change: Moving the product recommendations will take one engineer no more than two sprints. However, this will need to be A/B tested for up to 60 days to achieve significance and prove that it has increased conversion as opposed to reducing it. The hypothesis seems very strong though and the expectation is that it will increase conversion by 2%, or total site conversion by 1.9%.
- Product Videos: This change will take two engineers two sprints, but has no hypothesized impact on conversion. However, it should drive better Search Engine Optimization (SEO) and thus, top-level traffic. Increasing the total number of sales, even if conversion is flat.
- Product Hero Matches Swatches: Updating images to match color swatches is a multi-team effort. It will take the entire team four sprints to complete, in addition to work from other teams. No other work will get done durig that time. It is expected to increase conversion by 4%, or 3.8% across the site.
The product owner tells the various business owners the priorities, the costs, and expected outcomes. The business owners then determine the priority for the business, and as such, how the business will allocate funds. This negotiation between business owners and product owners will change the priority of the features until we get a prioritized set of features to be delivered.
Those negotations have left us with the following prioritized list:
- Add to Bag Errors
- Product Recommendations Change
- Color Scheme
- Product Hero Matches Swatches
- Product Videos
Delivery
Now that work has been prioritized, the engineering manager, program manager, and delivery team work to break the product requirements into digestible tickets for implementation (Figure 4.4). These tickets are groomed to provide clarity, prioritized for work, and then worked by the delivery team.
Figure 4.4
In this stage, the role of the engineering manager is to provide support and limit disruptions for the delivery team. The role of the program manager is to coordinate work in order to ensure it is delivered in a timely fashion across teams and to provide updates to business and product stakeholders about the work being done and risks that have emerged. The role of the delivery team is to deliver on the requirements. The product owner should regularly review the work of the delivery team and provide final approval as features are completed ([Figure 4.5]).
Figure 4.5
Measurement
The final, and very important step, in our software-development lifecycle is to measure the impact of our feature. Software development for enterprise is about making hypotheses about how visitors will react to the features we implement and then testing that those hypotheses are true. This helps to inform us about whether our investment in those features has paid off and helps direct us towards those items which require further refinement.
Most importantly, it helps us to determine whether our changes have done harm to the user experience. This way, we can ensure that we are not degrading the customer experience over time. Each of our work items had expectations about how well they would impact customer conversion. If all worked as planned, then we will hit the 5% business goal. If they did not work as planned, then we might need to find more ways to improve customer conversion in order to reach that business goal.
5. Conclusion
This is just one model of many for implementing product-based SDLC within a technical organization. When taking this, or similar approach, it is important to remember your goals. You want to clearly define ownership, to segment responsibilty, and to maximize the efficiency of resources.
Maximizing resource efficiency can best be done by: 1) Avoiding too much communication overhead by minimizing the number of people any individual needs to communicate with in order to complete their work, and 2) Minimizing the number of distractions for any individual. By clearly defining the flow of information, decision-making, and responsibility of roles within your organization, you can be sure to achieve these goals.
Categories: organization software development lifecycle