The Agile community long had a tendency to discourage the use of projects, either in terminology or as a governance concept for funding a change initiative. 'Product orientation' has been the magic antidote to everything that has been deemed troublesome with projects. And it makes sense in environments where change initiatives can be small, either in duration or in the impact on the product's users. A product that can receive small updates frequently over its lifetime supports the ability to organize around a product for which we incrementally improve its capabilities. Larger and more complex products are often subject to various parallel adjustments, often requiring a vast amount of talented engineers and external suppliers to design, test, and ship the product. While engineers are busy working on one large change initiative, often there are other large change initiatives awaiting their turn. For the individual engineer it is close to impossible (and unfair) to expect him/her to maintain oversight of the entire large initiative, let alone multiple running in parallel. Hence, the need of a person, a role, a driving force to maintain the long-term overview while working with engineers who can focus on their own engineering work. Hence the plea for the Project Lead.
I am still awaiting an example of a company that provides teams with a blank cheque to fund 'their capacity' with the instruction to 'do whatever brings value'. Large change initiatives are set out to achieve a certain result; e.g. redesign a power train unit to comply with the new EU emission regulation, or redefining a module to solve certain long-pressing customer complaints.
Each of these large change initiatives requires R&D/design/engineering teams to spend significant amounts of time to develop something new, suppliers who require clarity, procurement who requires compliancy to their preferred suppliers and manufacturing partners, and so on and so on. Each of these large (and long-lasting) initiatives needs an entity to understand progress, maintain momentum, and manage the downstream impact of changes.
Introducing....... The Project Lead.
While companies have different names for the role (i.e. Project Manager, Epic Owner, Project Coordinator, Delivery Manager, and so on) their prime objective is the same: ensure the successful execution and delivery of a change initiative (whether it is a project, product, update, change, or service). While each role comes with its own nuances, the prime objective remains the same. Let's dive a bit deeper into this (maybe) controversial stance.
Each change initiative, whether called a Project, Epic, Change, Initiative, or Assignment, has a sequence of roadmap-related activities. Maintaining overview of the roadmap and the various milestones, key decisions, and stage gates is a significant task. Moreover, various forces have impact on this roadmap, requiring continuous adjustments and scope re-alignments.
Moving the responsibility of 'realignment' to engineering teams removes the capacity to perform design work. Less capacity for design work impacts the ability to fulfill the change initiatives objectives. The extra efforts for realignment only compounds when teams are working on multiple change initiatives simultaneously. Hence - the teams need help
While small, stable engineering teams have been both appreciated and proven successful for ages, we will have to ask ourselves the following questions, knowing that stable, Agile teams outlive projects (i.e. are not 're-arranged' whenever the project finishes):
We need to provide clarity, clarity, and more clarity. Lets begin with a Function or Role description. Marina and I will be elaborating more about the examples we have been using in our soon-to-be released book.
Project Leads in hardware engineering environments working with stable Agile teams typically blend technical expertise with Agile methodologies to ensure efficient product development. Below are key responsibilities derived from role descriptions in hardware engineering contexts:
Agile Project Leadership
Facilitate Agile ceremonies (e.g. sprints, system demo's) while adapting methodologies to hardware development cycles.
Align cross-functional teams (mechanical, electrical, sustaining engineering) to project objectives and milestones.
Technical Oversight
Manage hardware development lifecycles, including design, prototyping, testing, and manufacturing.
Validate schematics, PCB layouts, and BOMs (Bill of Materials) to ensure compliance with product specifications.
Oversee design reviews and risk assessments, addressing issues like EMC compliance or supply chain delays.
Cross-Functional Collaboration
Coordinate with software, regulatory, and manufacturing teams to ensure seamless integration of hardware and software components.
Act as a technical liaison for stakeholders (e.g., OEMs, suppliers) to resolve design or compliance issues.
Resource and Risk Management
Track budgets, resource allocation, and timelines using Agile tools (e.g., Jira, Altium 365, Azure DevOps) to ensure maximum connection with the day2day work of Agile teams.
Mitigate risks related to component availability, certification delays, or design flaws.
Quality and Compliance
Ensure adherence to industry standards (e.g., medical device regulations, environmental compliance).
Lead root cause analyses for product failures, inject mitigation activities into backlogs, and prioritize corrective actions.
Iterative Planning: Support the break down of hardware development phases and activities into sprints, balancing long lead times for components with Agile flexibility.
Backlog Management: Provide clarification to support prioritization of tasks like prototyping, testing, and supplier validation in collaboration with product owners.
Stakeholder Transparency: Deliver progress reports to senior management, highlighting adjustments to scope or timelines due to hardware constraints.
Technical Expertise: Proficiency in hardware design tools (e.g., SolidWorks, PCB design software) and manufacturing processes (e.g., system integration, injection molding).
Agile Certification: Familiarity with the vocabulary, Agile mindset, and frameworks that are in use within the company, though adaptations for hardware workflows are common.
Do you find this helpful? Reach out to exchange thoughts!
Ali and Marina
Footnotes: