Sometimes my clients ask me which are the best organization structures that support a move to agile approaches. There are many ways to characterize their organizational structure and focus, but a common view I like to use is this:

Are they aligned as a Project-based organization or a Product-based one?

You can move to agile methods with either focus, but I think a Product-based focus makes it a much easier and smoother journey. Let’s explore the dynamics of each. Which will help you determine where your organization currently resides AND how you might want to shift your focus if you’re thinking about agility.

What is a Project-Based Organization?

To start the conversation, let’s focus on some of the aspects of a Project-based org: 

  • You view your work as a series of projects to be delivered. They have a finite beginning, middle, and end. They have a budget. Usually, they have fixed scope and dates, with perhaps limited flexibility for spending to add people.

  • Often the teams or people are considered and termed “resources” in this way of thinking, with the team being cobbled together specifically for the project. Even more often, the “resources” are multi-tasking across other projects or heavily interrupted in general. I.e. there is little focus.

  • The organization is simply looking for someone to say, YES, we can name that tune in 5-notes. I often see pressure for internal teams to commit to a project because of a threat to get another team/organization to do it. These are often offshore / nearshore / contract firms who will say anything to win the work.

  • When the project is finished, all of the people are reassigned to the next bit of project work. Typically, teams don’t stay together for very long. Another side effect of this is that ongoing project maintenance, for previously “completed” projects”, isn’t very well understood or managed. That is, it nearly always interrupts the next set of projects.

  • In larger scale environments, there is usually a Project Management Office (PMO) and project managers who are assigned to manage, track, and report on project progress. Once the projects have been “approved”, there is the notion of staying on track or getting back on track, so (estimation vs. actual) variance is seen as negative and controllable.

  • Projects are often considered as independent, with little to no cross team or cross organizational dependencies or impact planning. This is a project-centric and naïve view.

  • From an outward expectations perspective, project dates are often communicated to customers and stakeholders by the PMO. And the PMO is often abstracted from the execution reality of the projects. Or they might be obfuscating the project status in the false hope that things might recover. Either way, expectations are often mismanaged and misinformed until very late in the project lifecycle.

I must say that most of the above is how I’ve worked with projects for much of my career. Terms like waterfall projects, traditional projects, and command & control organizations typify this sort of focus.

From an agile point of view, the most glaring disconnect is with the people. People are not resources.

  • They are not fungible.

  • They are not sensibly splittable (across projects) via multitasking.

  • They are not easily reformed into high-performing teams.

  • Their skills & knowledge are unique and not easily replicated.

  • And they are not easily expanded (added or replaced by other people).

 The latter point was clearly made by Fred Brooks in the 1960’s with Brooks Law that says –

Adding resources to a late project only make it later…

What’s surprising is that I often see this project-based mindset applied in agile contexts. That is, organizations are adopting agile practices at a team level but are still clinging to a project-based mindset across the organization and within the leadership team.

You see it most strikingly within the PMO and within the mindset (and practices) of the middle management team.

So, what is a Product-Based Organization?

Not all of the below characteristics apply to everyone, but they serve to differentiate product thinking from project thinking and how those differences might impact your agile mindset and transformation success: 

  • Products typically don’t have a start and end. At least not for a singular engineering build event. They may be retired, but that is usually after many build investments in their evolution. So, there is a longer-term view to the lifecycle of a product that much more accurately reflects typical customer usage cycles.

  • Products don’t necessarily have to have an external direction. You can have a product focus with internally generated and support IT-based products as well. In fact, the dynamics are quite the same independent of direction.

  • Products usually have an ongoing or continuous investment. The ROI is calculated for multiple instances of the products release AND for maintenance burden from one release to the next.

  • Products support the notion of experimentation, learning, pivots, and MVP’s. That is, early on in the lifecycle, the product often evolves quite quickly based on client and market feedback.

  • Products are often created and maintained by a consistent team or set of teams. Of course, there might be normal expansion/compression of the teams during the life of the product, but a core team is maintained.

  • In the agile community you hear the terms – Component Team or Feature Team. These are indicative of the product area focus for these teams. In this way, teams become adept and skilled within certain product areas. This also includes special experience with the client needs and business domain.

  • Products usually having ongoing specialized engineering focus for enterprise architecture and UX needs. That is, similar to the Spotify model of Chapters & Guilds, cross-cutting concerns are often ongoing as well thru the lifecycle of the product.

  • Products get ongoing care and feeding. You maintain them. You invest in them. You update them. All with an eye towards controlling the viability and reducing their technical debt.

  • In multi-team product development, dependencies are acknowledged and embraced. Planning and cross-team work techniques seek to minimize and accommodate dependencies. This is where techniques like SAFe’s – PI Planning can be advantageous.

Is there a choice?

Meaning, if we’re trying to be agile, can we still have a project-based mindset? How about just a little of one? We’re simply evolving, right? And agile is inherently flexible, right?

I actually don’t think so.

It’s not really about agile or not. It’s more about aligning organizations with a more sustainable and congruent model for product-based (internal or external) delivery.

And it starts with a newfound respect for your people. Realizing that they are not fungible “resources” to be moved about in spreadsheets and Gantt charts at a project manager’s whim. Nor are they “resources” that are solely used at the discretion of a manager on the hot issue of the day. And neither are their estimates and capacity to be ignored in lieu of over commitments that the leadership team has made to customers and stakeholders.

Instead, you build and invest in teams that are skilled and structured so that they grow and learn in their efforts to understand their customers’ needs and can build great products.

Wrapping Up

Another way to articulate the difference is this:

Do you throw people together to deliver projects?

Or

Do you direct product work towards resilient teams who are capable of delivering solving problems for your customers?

My friend and colleague, Cory Bryan, recently recorded a Deliver It podcast focused towards this same topic. I would encourage you to listen to what Cory has to say – http://deliveritcast.com/ep80-products-or-projects-0

Stay agile my friends,

Bob.

Additional Related Resources

And here are some additional references that inspired and/or support my views. I thought I’d share them.

1 Comment