“Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.” — Agile Manifesto Principles #5

If you want to increase agility, you need to empower people to be flexible and responsive. This is true no matter where people sit in your organization. If the plans and processes are too inflexible, if team members have to get multiple layers of approvals to get anything done, then progress will come to a halt if anything changes — and things always change. Rigidity leads to costly rework.

Rigid processes set up development teams to fail.

The authors of the Agile Manifesto had witnessed firsthand the consequences of forcing people to follow processes that set up teams to fail. They saw how demotivating it was to work within an environment where processes and systems didn’t fit the need. They wanted to make software development not just faster, but also better for the people doing the work.

They had the hypothesis that motivated people in a supportive environment did better work, and we’ve seen that hypothesis proven through the superior results produced by Agile software teams. Teams working in the physical space benefit even more when leaders trust their expertise.

Trust is even more important in the physical world.

A physical product requires input from multiple disciplines: Electrical Engineering, Mechanical Engineering, Industrial Design and so on. The experts in these areas have specific domain knowledge that is grounded in specialized training and experiences. An ME can’t do the work of an EE and vice versa — they may not even be able to give useful feedback on technical design details, except in limited areas where the disciplines interface.

Most software team leaders and project managers have a software background, so it’s reasonable for a team leader to provide meaningful feedback on the technical content of a software team’s work. It’s not realistic for a hardware team leader or program manager to have experience with all the disciplines he or she needs to draw upon to bring a physical product to life. Instead, they need to create an environment where these team members can do good work, and then trust their people to do good work.

For products in early development, this means trusting team members to define the major decisions they need to make, and the knowledge they need to build for those decisions: their Key Decisions and Knowledge Gaps. Then trusting the Key Decision and Knowledge Gap owners to design learning activities (analyses, models, experiments) that will help them build that knowledge.

Effective Knowledge Creation Requires Trust

We want our team members to be building knowledge as effectively as possible. We don’t want the need to adhere to a process or get approvals to slow down progress. If a team member comes up with a faster, more efficient way to get the knowledge needed, that’s what the team member should do, whether it’s on the plan or not.

Instead, we manage the flow of work by managing the flow of knowledge: giving team members ownership for Key Decisions, Knowledge Gaps and major deliverables, then getting out of their way. We don’t manage work at the detailed task level — we trust our team of experts to do the right things.

Trust and Verify Early

Trust does not mean relaxing verification standards. It is reasonable to expect a hardware developer to participate in design reviews, as a reviewer and a reviewee, to ensure that nothing obvious gets missed in the final design. But this is a form of late validation, with all the long, slow loopbacks that implies.

Instead, effective product development organizations encourage our specialized team members to engage with experts early and often. Sometimes those experts have reusable knowledge to close Knowledge Gaps directly. They may also review plans for experiments, test methods and design alternatives to point out areas of potential for improvement.

We want to set up an environment where getting this expert engagement is easy, and where people are motivated to both ask for feedback and offer feedback. It should not be seen as extra work — it is part of the process.

In the Rapid Learning Cycles framework, we encourage this engagement at Learning Cycle Events where team members share the knowledge they’ve created. We build expert feedback into the process, and keep the team’s focus on the knowledge, not the tasks.

For Agility, Focus on Knowledge vs Tasks

 In fact, this is actually happening in Agile Software Development, too — it’s just that software developers build knowledge by building, testing and validating code, so it looks like they’re working at a task level. They still encourage teams to manage work at the level of the User Story. Then they encourage teams to break these stories down into smaller pieces, which is easy to do in software, but even those small pieces represent bits of knowledge they create.

I would improve on this principle today in this way: be explicit about the fact that motivated individuals do their work by building knowledge.

“Build projects around motivated individuals. Give them the environment and support they need, and trust them to build the knowledge they need to get the job done.”