Project Coach

After decades of ongoing agile transformation initiatives in numerous organizations, many fixed-price projects still fail to meet customer expectations, especially in the area of safety-sensitive industries such as automotive or aviation. In the context of “make to order” projects (MtO), a smartly designed role of a Project Coach can increase the success rate, improve expert staff retention, and give your organization a decisive competitive advantage.

Even though every second attempt at an agile transformation fails (see statistical indication here), the advantages of successfully transformed agile organizations have been well documented. Examples like the ING bank, Spotify, Lego, Cisco, and PTC prove this point.

Agility has been adapted as a categorical imperative. The term “agile” has been transformed from an adjective to a new noun, “agile.” It has gone through the long hype curve (see Gartner’s hype curve explained here):

Without a doubt, agile has come a long way since its inception over 20 years ago. However, “agile” is not equal to “agile.” Some project types appear to perform well than others. The success rate for non-MtO projects (e.g., R&D projects, see this article for an explanation of the MtO project types) differ unfavorably from the success rate of comparable agile MtO projects:

As shown in the above chart, MtO projects still struggle with the right approach to agile, while non-MtO projects are already well on their way to further mastering the successful agile transformation. Non-MtO agile projects deliver good results (see the Spotify example). In contrast, MtO projects often end up in a “world of pain,” in which boot camps, task forces, elevated escalation levels, and the often-resulting burnt-out teams are frequently the norm. An attempt to create a unified approach for the entire organization, regardless of the project type (e.g., MtO and R&D), is nearly impossible and explains the challenges facing organizations struggling with agile transformation.

Since its inception, the generic SCRUM has struggled with scalability in specialized work products and team size. The “teams of teams” idea remains a largely abstract concept. Furthermore, in highly regulated, functional safety-relevant projects, unique safety work products can only be successfully handled by a few highly specialized, dedicated developers within a larger team. For instance, not all team members have the training needed to develop a safety concept. Highly specialized artifacts, such as the safety case or the functional safety concept, cannot be designed by random team members without extensive training before joining the project team. While R&D teams can use relaxed project constraints by postponing specific work packages to a later stage of the product development or even remain reserved for the corresponding MtO project (such as the ISO 26262 safety concept), MtO projects need a much faster team building. They cannot afford the luxury of experimentation which is an essential strategy in SCRUM projects.

Furthermore, generic SCRUM projects often suffer from a well-known scalability challenge. The problem of team size is transparently indicated in the SCRUM guide, where the team is defined as follows:

“The fundamental unit of Scrum is a small team of people, a Scrum Team. The Scrum Team consists of one Scrum Master, one Product Owner, and Developers. Within a Scrum Team, there are no sub-teams or hierarchies. It is a cohesive unit of professionals focused on one objective at a time, the Product Goal.”

In the generic SCRUM, only three roles—Scrum Master, Project Owner, and the team—are permitted. When confronted with rigid, complex safety requirements and challenging timelines typical for automotive supplier projects, the teams often struggle with the self-organization of such complicated tasks to the point of borderline dysfunction. Note the emphasis of a small team in the SCRUM guide. Self-organization is next to impossible in teams of 30 or more developers. Therein lies our problem: no complex, safety-relevant MtO projects can be implemented by a “small team.”

The solution to this scalability dilemma lies in a further extension of SCRUM role definitions, as highly specialized responsibilities and roles are needed to ensure better planning capabilities and more effective risk management for MtO projects. In other words, in MtO projects, a higher diversity of project roles is indispensable. In large MtO projects, developers must be organized by subteams, and specific roles must be consistently replicated across all teams to ensure a consistent safety work product quality.

Listen to What Experts Say

A further (somewhat esoteric, but nonetheless critical) challenge is that SCRUM has become a synonym for agile. But agile is a much more comprehensive concept than “just” SCRUM. In other words, the term “agility” must regain its original meaning, and the generic SCRUM should be recognized as just one agile variant among other agile options.

In his book “Balancing Agility and Discipline,” the legendary computer scientist Barry Boehm explains in detail the challenges, fundamental discrepancies, cultural aspects, and misconceptions of both the “planned” and “agile” approaches. His contribution is so insightful that it appears indispensable as a source of organizational systems development strategy. Decades ago, Barry Boehm had already predicted that a “hybrid” process would be the future of software project management (see his paper here). The then future is now, and we should take advantage of his body of knowledge and be genuinely agile while adapting agile and planned project management as a hybrid approach.

That also means that SCRUM is not the end of the progress of the art of systems and software project management. There will always be innovative ways to make our projects more effective. The realization that there is no “silver bullet” development process is a liberating insight. Instead, legacy frameworks such as the spiral/iterative approach or SCRUM are a mere input to future project management systems.

The need to further extend agility beyond SCRUM poses an unexpected challenge to organizational policies. The attitude of “all-we-need-is-SCRUM” can create artificial limitations to the advancement of an agile mindset. Especially in MtO projects, “de-programming” of the team is, therefore, necessary to achieve a genuinely lean, agile team mindset. In the spirit of world-class experts like Barry Boehm & co., and combining the lessons learned from real projects and SCRUM as the starting point, we must find the courage to achieve an “adaptive-agile” mindset. A project management system that works for the MtO project class is urgently needed.

As part of this progression, we can—and should—extend or redefine the popular agile project roles, such as SCRUM Master, to accommodate the adaptive-agile thinking to MtO projects.

The Role of a Project Coach

An adaptation beyond SCRUM means that the team often enters uncharted territory. MtO projects start with existing customer requirements. In addition to system and software level specifications, it might also include customer-specific lifecycle elements, such as customer milestones and phases, as part of the MtO contract. In the automotive supplier business, for instance, quality aspects play a critical role, such as a higher Automotive SPICE maturity level, elevated ASIL ratings (according to ISO 26262), and cyber-security goals. Also, manufacturing requirements (e.g., planning for an increasingly demanding “end-of-line” testing, “EOL”) are often part of the development contract. On top of all these expectations, the OEMs increasingly require more meaningful and quick status reports, with sometimes quite strictly stipulated report content, which is often an additional burden.

As already emphasized, self-organization is mission impossible in such MtO Projects. Scaling up MtO projects is the ultimate challenge. But who could take the responsibility of organizing such multi-team projects that goes well beyond the generic SCRUM? Hiring a conventional project manager may sound tempting in such a context. Unfortunately, traditional project management has become next to impossible these days. In the past, project managers had enough time to make all the accommodations and resolve conflicts of all sorts, including customer adaptation to the lifecycle, milestones, and other critical contractually stipulated artifacts. However, in today’s world of fast-paced systems development with substantially increased complexity and ever shorter timelines, the responsible project manager would hardly be able to survive. There simply is not enough time to operate in such a traditional manner. Thus, hiring a conventional project manager often results in frustration. Help beyond a single project role is needed, and therefore, even in relatively small settings, the role of the SCRUM Master was created to cope with the team dynamics and ensure the SCRUM process adherence. In MtO automotive projects, however, a conventionally trained SCRUM Master is frequently overwhelmed by the complexity of the project requirements and team organization in safety-relevant MtO projects.  

Furthermore, the role of a Product Owner in SCRUM only covers a subset of tasks. For example, project risk management, so critical in MtO projects with functional safety settings, is poorly covered. Typically, “the team” is supposed to manage the project risks on its own. That, unfortunately, often means that nobody feels responsible for risk management, which is a frequent reason for MtO project crises.

Thus, dedicated, additional project roles are essential to the resolution of the SCRUM scalability problem, such as:

• Functional Safety Lead
• Requirements Lead
• Change Request Lead
• Test Lead
• Configuration and Tooling Lead
• Traceability and Reporting Lead

Those roles are project-wide (i.e., not meant for only a specific sub-team). The Product Owner leads all teams as part of the overall team structure.

Since neither the traditional SCRUM roles of the Product Owner nor the SCRUM Master will be willing (nor have the time) to take care of defining and establishing new team roles and other non-SCRUM roles, a role of a Project Coach should be enacted to “connect all the dots” and ensure an effective and friction-free project operation.

A Project Coach should be someone with an extensive industry background and solid project management training, as well as a good understanding of relevant process quality standards (e.g., Automotive SPICE), to ensure compliance with industry standards and customer process quality requirements. A Project Coach is not an extra project manager. Instead, a Project Coach should act as a “SCRUM Master on steroids.” A proper Project Coach can fully accommodate the SCRUM Master role. Particularly for MtO projects, the traditional role of a “SCRUM Master” can and should become redundant to the role of a Project Coach. It may sound like a receipt for a palace revolution, but the need for a different, more comprehensive role becomes more evident when looking at the responsibilities of a Project Coach in MtO projects, which include:

• Tailoring the project according to the project and customer needs, including milestones, timelines, reporting structure, and specific project roles
• Defining the project-specific sprint cadence, e.g., bi-weekly or weekly, and synchronizing sprints and releases with the project customer contract stipulations
• Establishing roles and role-specific interfaces to other stakeholders and the customer, as well the suppliers
• Defining the reporting structure to support the Product Owner
• Coaching the Product Owner to ensure that the team understands and supports the roles and the additional work products
• Ensuring identification and mitigation/resolution of project risks
• Facilitating workshops and big room sessions online/offline
• Acting as a “confidence person” to support individual team members in case of open or hidden conflicts and concerns. That is a mentoring aspect of the Project Coach role.
• Preparing and supporting formal process assessments (e.g., Automotive SPICE assessments) as defined in the contract agreed with the customer.
• Acting as a “side-kick” to the Product Owner, filling in whenever the Product Owner is temporarily unavailable
• Ensuring inclusion of disciplines other than software, such as system-level engineers, as well as hardware and mechanical engineering experts
• Actively supporting the project-specific hiring process to assure that the new team members fit the team structure and mindset.

The Project Coach should understand how to resolve the team’s critical obstacles and show stoppers, thus support the Product Owner as an additional escalation instance with a direct interface to the project sponsor and—if required—to the project customer.

What skills should a Project Coach possess? In the article “The TCC , a TCC’s skills are well described. It is the same skill set required for a good Project Coach. However, unlike the TCC role, the Project Coach is not a QA manager role and does not have to be independent. In fact, the Project Coach should not be independent since the Project Coach typically reports to the project sponsor. At the same time, a Project Coach must have the integrity and ability to not only uphold the team’s morale but also talk to the power it must be. The project’s success is of utmost importance to an effective Project Coach.

Why a New Role?

As previously mentioned, the Project Coach is a “SCRUM Master on steroids.” Why not title it as such? I suggest not calling this role “SCRUM Master” for the following reasons:

1. The SCRUM Master is a generally acknowledged, well-established role in generic SCRUM. As a side effect, SCRUM Masters are typically trained to reject additional responsibilities beyond the generic SCRUM Master role.
2. SCRUM Masters are often hired specifically for the generic SCRUM Master role. The “job description” makes it difficult for SCRUM Masters to take action beyond generic SCRUM responsibilities, such as initializing or driving further process improvement and organizational change.
3. Often, SCRUM Master simply lacks the relevant training and experience in other areas than SCRUM, such as Automotive SPICE or functional safety.
4. A Project Coach typically reports to the senior line management (e.g., the project sponsor) instead of third parties or even the scrum.org consulting group. That, by the way,  resolves the sometimes occurring problem of lack of trust within organizations in MtO projects.
5. Generic SCRUM focuses specifically on software development. A Project Coach, by definition, on the other hand,  supports software teams as well as other engineering teams, such as systems and hardware teams, as well as customer and project suppliers.

SCRUM has been tremendously successful in promoting the agile mindset. It can work very well in non-MtO settings but has often failed to impress in MtO projects. For MtO projects, as peculiar as it may sound, a more agile mindset is needed than the traditional, generic SCRUM approach. It also makes sense to differentiate between SCRUM and the adaptive-agile approach to avoid misunderstanding when setting up MtO projects. Thus, it is opportune to refer to “adaptive-agile” instead of SCRUM in the context of MtO projects. 

The adaptive-agile mindset in MtO projects can resolve the contradicting expectations of critical stakeholders. For example, the customer often expects that a generic SCRUM project team presents and consistent, long-term project planning, especially in functional-safety-relevant settings. Long-time planning, unfortunately, is explicitly undesirable in generic SCRUM. In effect, customers may demand that “you can have your cake and eat it,” while the project scope is open to continuous changes and project requirements without the appropriate compensation. It is a traditional problem in fixed-priced projects. If your team is not trained in ongoing scope negotiations and applies effective project rhetorics, the project will often get in serious trouble, resulting in escalations and missed delivery deadlines. As opposed to such an approach, the adaptive-agile for MtO projects allows for fairer conditions in better-motivated project teams and more effective scope management. It provides long-term adaptive planning, transparent project scope management, and better long-term risk management for the customer.

The Limitations of the Role of the Project Coach

As already mentioned, a Project Coach is not a team’s process quality assurance role. In the Automotive SPICE (or CMMI) reference model, the QA responsible (often carrying the title of a Quality Assurance Manager or QA Manager) must be an independent instance. Therefore, the Project Coach must not be identical to the QA Manager. Similarly, a Safety Manager is an autonomous role that cannot be the same person as the Project Coach.

Furthermore, establishing a Project Coach is not always the best way to go for non-MtO projects. In R&D projects, a well-trained SCRUM Master will typically handle the team successfully using the generic SCRUM, even in larger projects. No specific “tailoring” is needed in such cases.

Also, in small settings, a dedicated Project Coach might be overkill. Small, highly skilled expert teams can self-organize even in challenging safety MtO projects, just as postulated in the generic SCRUM model. No dedicated Project Coach is necessary; A standard SCRUM Master suffices.

The Project Coach Mindset

The “agile mindset” is a fundamental concept indispensable for any organization that is “going agile.” The “organized agility”—or adaptive-agile—mindset is a natural advancement of the agile principle in MtO projects. Like the general agile, the “agile mindset” is not a traditional “process.” Instead, it is a set of principles and mental shortcuts to achieve better project results in MtO projects. Based on the experience gathered in such projects, here is a loose list of thoughts that offers inspiration on the way to achieving an adaptive-agile mindset in MtO projects, as well as a blueprint of the more detailed responsibilities of a Project Coach:

• Task responsibilities: No task should be owner-less. That prevents the “it-is-not-my-job-syndrome.” Use your task management (like JIRA) to enforce that all tasks have an explicitly assigned assignee.
• Avoid conflicting roles: The job description of “agile project manager” could indicate that the organization is not consistently clear about project goals. A project manager is generally a no-no in generic SCRUM organizations and poses a conflict potential. Clarify the conflicting role descriptions asap.
• PMO: If there is a PMO team to help your projects, make sure it is an “agile PMO.” A PMO can (and must) exercise a consistent, adaptive–agile mindset. Also, such PMOs could be growth stem cells for Project Coaches.
• Groupthink: Avoiding “groupthink” always means actively looking for improvements, regardless of roles and individuals in the projects. The ability to exercise critical thinking is paramount to the success of MtO projects, and the Project Coach is responsible for ensuring and encouraging it.
• Balanced power: The Project Coach can and should play a decisive role in MtO projects, directly aligned with the project sponsor. If the project sponsor is unhappy with the project results, the Project Coach should be just as disappointed and do everything in the Project Coach’s power to improve the situation.
• Long-term planning: There is no successful MtO project without long-term planning. It is one of the most important differences between a generic SCRUM and an adaptive-agile mindset MtO project. The key stakeholders, primarily the customer, will not accept some vague planning. The experience from the customer’s painful past projects has taught the customers that a lack of long-term planning is a red-alert risk. Remember, the plan is nothing—the planning is everything in MtO projects. It is not just a waste to keep the custie happy; instead, it is a great way to manage project risks long before they materialize as project issues and critical blockers.
• Beware of complacency: If a Project Coach states that “SCRUM says…” then you might be just as doomed as if you were a mindless zealot for CMMI or Automotive SPICE in the past. If you don’t believe it, try to “talk to SCRUM” and learn what it says about your mindset. In other words, SCRUM is not some kind of a divine entity. Instead, it is just a project management concept. Keep in mind that you are never “done” with project improvement in an adaptive-agile project.
• Be actively involved in the hiring process for your projects. Not everyone can withstand the pressure of an MtO project. An effective Project Coach continuously assesses the ability of the team to “stand the heat” and immediately holds out a helping hand to the team member at any time. However, if (new) hires don’t share the adaptive-agile mindset, the Project Coach should be able to raise the issue to the project sponsor (or a similar role in your line organization).
• Reporting: Traditionally, delivering project reports is deemed as not agile. Project reports may be redundant in non-MtO projects, but in MtO projects, project reports are indispensable to avoid wasteful meetings resulting from customers’ uncertainty and badly aligned risk mitigation. In complex projects, the customer won’t run a daily build and verify the results to see what is happening in the project. It is not to say that a daily build is not urgently necessary; it’s just that it is simply not feasible for the high-level customer to go through the code to see if the proper functionality is correctly coded. The customer wants to have a quick, up-to-day overview of project progress and project risks without a lengthy discussion of all modified and new features.  Instead, use tools like JIRA/Confluence that can automatically create the right “live” report without extra effort from your team.
• Automate everything: Not only the reports; all repetitive tasks should be automated whenever possible. Find and assign a Project Engineer to develop, set up, and maintain an effective project environment to eliminate waste and relieve the team. Plan resources to do that (talk to your sponsor!)
• Maintain absolute fairness and trust: The entire team must be a trusted team. Latent conflicts must be immediately resolved, and you are responsible for achieving this status quo as a Project Coach in concert with the Product Owner. Note that there are limits to “unconditional openness” regarding the project sponsor and the customer. If you disclose all concerns unfiltered, escalations and task force mode are guaranteed. To prevent that from happening, consistent planning and frequent reporting to key holders is paramount, and a clear team-internal agenda must be established, clarifying what, when, and how to share project progress details with the customer.
• Maintain your integrity: As a Project Coach, you must maintain absolute integrity. There is no trust without integrity. Train and coach the entire team to have the same attitude.
• High-pressure environment and anxiousness: MtO projects are typically a high-pressure work environment. An adaptive-agile mindset thrives in it. Like the Marines, trained to fearlessly run towards the battle instead of running away from it, the team must have the courage to meet the project challenges head-on. Naturally, the team suffers periods of excessive stress and anxiety throughout the project lifecycle. A good Project Coach will know it and work on easing the fears and lowering the frustration level for all team members.
• Avoid antagonizing ideologies: “Predictability” and “agile” are NOT a contradiction in MtO projects. Clarify this with your team asap. Adopt, don’t fight.
• De-program the team: Especially in new projects and freshly hired teams/team members, you must immediately define and communicate the project strategy. Align with the customer, project sponsor, and Product Owner on the fundamentals. That includes clarifying some essential concepts, such as:
  • An agile mindset is not identical to SCRUM. Not only other agile schemes and processes exist, such as Kanban, Lean Startup, etc. Also, in MtO automotive projects, Automotive SPICE compliance is routinely required. A fully-fledged V-model must be in place, no questions asked. Also, the functional standard ISO 26262 explicitly demands comprehensive V-model compliance with all waterfall-like aspects of it. Your team must “make peace” with such rigid project constraints and become adaptive-agile instead.
  • “Stakeholder Value”: The term “value” is often used instinctively in generic SCRUM. In non-MtO projects, that value often changes according to the current project status and project phase. In MtO projects, on the other hand, the value is easy to pinpoint: it is the requirements implemented and delivered according to short- and long-term planning concerning the product quality criteria as stipulated in the project contract. 
  • Satisfying the management? Occasionally, some agile trainers state, “Satisfying SCRUM should be the goal instead of making the management happy.” That is a confusing, unnecessarily antagonizing statement in MtO projects. Such a claim is not valid in any (surviving) MtO project. It is about satisfying the customer’s demands and is well-defined mainly in the customer specification in typical automotive OEM projects. No manager wouldn’t be happy with a well-run MtO project.
  • “Agile transformation” as an ultimate goal. Agile trainers sometimes “sell agile” as an ultimate, self-contained goal, some kind of a “greater good,” but it is not the whole truth. An agile mindset is an important aspect, but “agility” and “delivery” of product results are just not a contradiction in terms of any means. In the case of MtO projects, successful project delivery to the satisfaction of the project stakeholders, mainly the team and the customer, is the ultimate goal.
  • End-to-End: This is another popular, mystifying statement that is not clearly defined but sounds “important.” Translated in English, that statement should mean that no tasks defined in the project scope are negligently ignored, and clearly defined responsibilities are the norm in your project. “No tasks left behind,” if you will.
• Fully aligned with the Product Owner. Your job is to support the Product Owner in all regards, including filling in if the PO is not available because of sick leave.

Project Initiation Phase

• Initial risks analysis: Collect project risks starting from day one. Put them in a well-managed overview. Either the Product Owner or you as Project Coach (or both) should facilitate the risk register.
• Define all roles: Define all required project roles in a written form. For instance, one of the most important—albeit often forgotten—project roles is to take care of the requirements and identify potential change requests. Well-managed requirements and change requests in MtO projects are as good as gold.
• Change request management: Help the Product Owner systematically manage change requests. Customers typically don’t like it, but you must maintain the project scope, and any divergence from the project scope, as defined in the MtO contract/SOW (statement of work), should be accounted for. Coach the Product Owner to maintain it as a “bargaining chip.” It doesn’t mean that each change request will be added to the bill. Instead, use the well-managed list of approved change requests as a bargaining chip when project risks unexpectedly arise.
• Team chart: Define responsibilities and their direct interfaces in a written form and agree with the Product Owner and other team members on the project team structure. Keep it constantly updated.
• Ensure tools availability in the workflow setup: The task workflow (e.g., using JIRA or a similar too) must be correctly set up from day one and updated/modified as needed.
• Train and constantly coach the team: An effective Project Coach ensures everyone knows all roles and responsibilities. New team members need a well-organized introduction so that each new team member must hit the ground running.
• Establish a project-specific “Definition of Done” (DoD): In MtO projects, the DoD includes agreeing on requirements, verification criteria, testing, and applying a review strategy on all levels. As a Project coach, actively support the Product Owner with this task.
• Permanent alertness mode: Start every MtO project as if a “task force” were about to begin tomorrow. Think about it that way: “You are already in a customer escalation—you just don’t know it yet.” It is a fundamental mindset that is important for the success of MtO projects.
• Work from home: In the generic SCRUM, face-time in an on-premise office is expected. An adaptive-agile mindset, on the other hand,  makes it work by using the right tools and policies specific to work-from-home and geographically distributed teams. Working from home can pose a unique challenge, but it can work just fine, see the article series Alone together: on productive working from home for more details.
• Set up an effective e-mail policy: Generally, avoid e-mail if there are more appropriate tools, such as team instant messenger and direct phone calls (voice calls or per video). Make sure that a single source of information is established. Use easy-to-use reporting tools like Confluence or similar instead. No e-mail distribution is needed in such cases. Redundant information is a hot-red project risk that must be eliminated asap.

Further Remarks During the Project Execution

• Pro-active risk handling: Seek out project risks every day and immediately mitigate them with your teams. Start on day one and continue throughout the entire project duration. Work closely with the Product Owner on this.
• Continuous planning: Based on the customer requirements, work with the Product Owner and the team to ensure that both short- and long-term planning is frequently validated and continuously updated.
• Estimate the effort: The concept of “story points” in SCRUM does not include real effort estimation. That is usually unacceptable for any Automotive SPICE assessor. Estimating the number of team resources is required to ensure that additional resources can be requested from the project sponsor in a qualified way. Just saying, “we need additional people” is a frequent request that results in unnecessary discussions with the project sponsor. The “mythical” person-day may appear outdated. Still, as long as we don’t get paid with story points instead of real money, there must be a well-defined relationship between story points and the time effort, ultimately aligned with the project budget. In other words, as a Project Coach, it is OK if the team uses story points and a variable velocity calculation. However, you still need an easy conversion of story points to hard currency to calculate the reminding project budget.
• Document the effort: After every sprint and each release, record the resulting effort. You may do it during a regular retrospective or simply collect the results in your task management system (e.g., JIRA). Use it to make sure that the team is not systematically overbooked and overworked. If the team gets forced to do frequent overtime work, you know that you have failed to manage the resource availability risk in your project. Ask the designated Project Engineer to automate this task entirely so that you don’t have to sit over endless, error-prone spreadsheets to collect the data.
• Maintain a structured backlog: In generic SCRUM, the backlog tends to be a linear list. In complex safety projects, especially MtO projects, a structured backlog based on the architectural design is more valuable and should be part of the backlog refining used for sprint and long-term planning.
• Continuous reporting: Make sure that either the Product Owner or you as Project Coach delivers project status reports to critical stakeholders on time.
• Involve the key stakeholders: The customer should be continuously “in the loop” of the daily development. Ensure that the customer appoints someone on the customer’s team with detailed technical and business knowledge so that the customer expert can immediately clarify them with your team.
• Daily integration: If possible, the team should deliver a fully working product for the customer team to “play” with.

Thoughts on the Product Owner Role

The Product Owner is the other complementary key role in generic SCRUM that needs an update in an adaptive-agile MtO project. In the Scrum Guide, the Product Owner (PO)…

“… is accountable for maximizing the value of the product resulting from the work of the Scrum Team.”

“The Product Owner is also accountable for effective Product Backlog management, which includes:

• Developing and explicitly communicating the Product Goal
• Creating and clearly communicating Product Backlog items
• Ordering Product Backlog items
• Ensuring that the Product Backlog is transparent, visible, and understood. “

Further responsibilities and tasks of a Product Owner are, thankfully, not further defined in the SCRUM guide, thus enabling a straightforward extension of the Product Owner role.

In the case of MtO projects, extended responsibilities may include:

• Maintaining the project scope regarding requirements and required resources and managing project change requests.
• Managing key stakeholders, including the project sponsor, the customer, and the project’s suppliers
• Establishing an effective stakeholder communication approach across all levels, including the team suppliers
• Actively managing the project’s risks
• Reporting the project status to the key stakeholders
• Ensuring a middle and long-term planning consistency
• Have a decisive say on the (new) project hires

In the past, the traditional project manager would take care of such responsibilities. If so, why not simply replace the name of “project manager” in “Product Owner” and expect the same range of responsibilities? The problem is that, in modern, fast-paced MtO projects, the generic SCRUM Product Owner would quickly get overwhelmed with such additional tasks. The project timelines have been continuously compressed, and such an “agile project manager” with further extended responsibilities would burn out quickly. Thus, parts of the original project manager’s responsibilities must be delegated within the project team. Naturally, the Project Coach, as the Product Owner’s “side-kick,” could, and should, take over many of those responsibilities. In addition, the Project Coach should help the Product Owner with allocating the specific roles as needed in an MtO adaptive-agile team.

The adaptive-agile Product Owner should take more responsibilities than are defined in the generic SCRUM. Scope management, risk management, and reporting would be typically included in the extended Product Owner role. I would, however, recommend not stipulating all of those responsibilities in great detail as part of the organizational process definition. Instead, the Project Coach must assess the experience, training, and corporate culture aspects and tailor the roles, including the Product Owner role, to the project needs.

Remarks on Roles Naming

Be mindful when establishing new role names. The term “master” (e.g., “SCRUM Master”) has become politically problematic. That is also an argument to use the role name “Project Coach” instead, even for non-MtO projects. Also, the generic SCRUM name of a “Product Owner” in adaptive-agile projects could become confusing. The generic SCRUM role is narrowly defined. Maybe an “Adaptive Product Owner” could be a better alternative. I would also generally tend to avoid the term “Project Manager” in adaptive-agile to avoid unnecessary confusion with the classic project management definition, such as described in the PMBoK Guide. Remember: words do matter, and the agile world has become an ideological minefield that a Project Coach must know how to navigate.

Conclusion

There is a healing to the self-inflicted injury of the disturbingly high number of distressed MtO projects. Even though there is no “one-size-fits-all” trick to fix it, resolving the project policy confusion is the first step towards an effective, adaptive-agile mindset that shows the way to the eventual solution. “De-programing” of the MtO team is critical to the project’s success. The Project Coach should lead this team discussion to resolve all fundamental, dogmatic, and wasteful arguments and make sure that the team feels respected, is passionate about the project delivery, and remains motivated at all times.

As an essential contribution to the project’s success, the Project Coach supports the individual developer’s career goals, thus supporting the developer’s career advancement in alignment with the organizational goals. Working with the line management and the HR teams, the Project Coach can be instrumental in retaining the key experts, despite the often challenging environment in MtO projects.

The adaptive-agile approach is an essential step to resolving the still high number of distressed MtO projects in complect safety-sensitive industries such as automotive suppliers. A clear, driven by official organization policy, distinction between R&D and MtO projects, supported by the right set of team roles and responsibilities, is a recipe for increasing the overall project success rate.

In that manner, a well-established role of a Project Coach in adaptive-agile MtO projects is guaranteed to accelerate organizational and individual career advancement and significantly reduce the percentage of distressed MtO projects in systems development organizations.