Engineering Agility Newsletter #6: Project Managers and Agile Teams

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. 

A plea for Project Managers, Project Leaders, Epic Owners, and similar roles

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.

High cognitive load when teams are working on more than 1 project / change initiative

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

Then, what does a Project Lead do with Agile teams?

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): 

1. 1. How can a Project Lead do its work when the capacity of the the stable Agile teams are shared amongst multiple Project Leads?
   2. How can the Project Lead know that the capacity funded by his/her project is used on his/her project?
   3. How can we structure 're-alignment' to happen cadence based, rather than ad-hoc? And how do we manage ad-hoc changes without immediately impact the flow of the teams? 
   4. What are other (cultural, procedural, and technical) adjustments that are required in processes to protect the stability of Agile teams from rearrangement?

Sooo... now what?

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. 

A function and/or role description of a Project Lead working with Agile Teams

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:

Core Responsibilities

1. 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.

   • Perform work reprioritization efforts required to achieve project milestones. 

2. 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.

3. 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.

4. 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.

   • Collaborate with other Project Leads to prioritize work most valuable for the business, effectively utulizing the same stable team capacity, rather than solely focussing on own project completion.

5. 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.

Agile-Specific Duties in Hardware Contexts

• 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.

Required Skills and Background

• 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.

• Leadership: Ability to mentor engineers, resolve conflicts, and maintain team morale in high-pressure environments.

Do you find this helpful? Reach out to exchange thoughts!

Ali and Marina

Further reads and sources

• A podcast with Weronika Michaluk, practice lead at HTD Health, on the development of Medical Devices with Agile team. Hosted by the Agile Embedded Podcast
• Using Agile Manufacturing at a Luxury jeweler to improve productivity, a case study from Tulip.co

Footnotes: 

• Header image generated by ChatGPT. The text is old-fashionedly self-written.
• The mentioned companies have not paid for the promotion.