"Agile" Sorta Bores Me Now

So, before I get pounced on by everyone, let me start my saying that I still like agile. Agile as in what some light-weight method folks agreed on at a ski lodge in 2001. The 4 values sure, but more so the opening clause and the 12 principles I still wholeheartedly agree with.

That being said, now that the word agile is mainstream, I don’t find orgs that are sticking truthily to agile’s roots to be the norm.

What I most commonly find is that "agile" means (what I call) “Scrum Masking”. This is where an org “adopts scrum” by means of changing or adding some new roles and ceremonies but mostly doesn’t change how it was working before.

And I don’t only see this with scrum. I’ve seen the same pattern in orgs where “scrum didn’t work” so they decided to use kanban instead. I’ve seen the same results in orgs where “scrum didn’t scale” so they decided to use SAFe instead. I’ve seen it happen in orgs that said they learned from all methodologies and created their own custom processes.

Now, you might be thinking “well sure, but that’s not agile”. And I agree that’s not what the creators of agile had in mind but it’s hard to argue that it’s not what the word agile has come to mean in mainstream application. I’ll let the philosophers debate whether a thing is what is was designed to be or what it has become. The fact remains when a company comes knocking for and “agile coach” or help with their “agile transformation” I usually have some non-positive, pre-formed expectations and I’m not typically wrong.

Some of these pre-formed expectations, the ones that bore me are:

  • There is a hyper focus on doing the process “right”
  • There is a lot of interest in standardization and tooling
  • Agile is almost entirely contained within the IT department
  • Agile is considered a mostly team level concern

However, it’s not all doom and gloom. There are some phrases, that when a company chooses to use them, I tend to see more liklihood for positive change. Some of these include:

  • Help becoming product-led or improve product management
  • Help with portfolio investment thinking and road mapping
  • Help improve organization systems and design
  • And sometimes (maybe 60%), improve business agility

Certainly these aren’t magic phrases that ensure everything will be shiny and perfect. All orgs have issues and improvement areas. But basically, it boils down to asking are we really about sensing and solving more holistic problems that have meaningful impacts on both the customer and the business. Or are we spending too much time working at doing some process “the right way”? While it's certainly possible to get to real improvement through process coaching on scrum, kanban, safe, etc, in my opinion it’s better to just think of those things as tools that may be used to uncover and improve on the real issues.

And again, many people would claim that’s exactly what those tools are meant to do...and again, I agree with that intention, I just don’t see that actually happening when the named tool or methodology is part of the engagement. And unfortunately the term agile just seems to have become the umbrella word for these methodologies.

As always, I’d enjoy hearing stories or experiences that conflict with this or support it. I’d enjoy insights on what others are seeing in terms of interest in real change to solve real problems.

-Matt Barcomb


What Does It Mean To Be Product-Led?

Different orgs have different orientations to how they approach being a business. The orientation of a org governs many aspects of its behaviors and actions. A few examples are: what the strategy is, how decisions get made, how work gets planned and executed, how it interacts with customers, and how it engages with employees.

Having worked with dozens of orgs of all ages and in many industries, I’ve found four main types of orientations: sales-led, finance-led, technology-led, and product-led.

1) Sales-Led

Primarily characterized by a drive for increasing the customer base and revenue. Often develops or promises product features to meet specific customer needs. Will do what it takes to close the sale.

2) Finance-Led

Primarily characterized by a hyper-focus on cost management, risk aversion and increased efficiency. Often requires heavy monetary ROI justification for product and operational initiatives. Org success is often viewed in terms of quarterly Wall Street performance and metrics.

3) Technology-Led

Primarily characterized by adopting new technologies and/or technical excellence. Often major rewrite or re-architecture initiatives are in progress. Frequently large platforms are being built for possible needs in the future. Often, current feature requests are postponed to build out of the new platform or architecture.

4) Product-Led

Primarily characterized by focusing on customer needs and user experience and balancing those against business goals and objectives. Seeks alignment of company strategy with product initiatives. Trades off for product-market fit and value generation.

How to be product-led

Rarely do organizations evaluate their context or goals and choose an orientation intentionally. More commonly, they respond reactively to their environment and those choices push them into an orientation. When an orientation isn’t intentionally selected by a leadership team, it’s possible for an org to experience the tension of multiple orientations as individual leaders push for the orientation that best suits their agenda to do what they think is best.

Intentionally choosing one orientation doesn’t mean the org doesn’t concern itself with aspects from the orientations. It simply means the chosen orientation is its focus. Other business functions are considered through the lens of the orientation that’s in use.

So, being product-led means intentionally choosing or accepting as a whole leadership team to primarily focus on the traits mentioned above.

Because that brief description above can mean a lot of things, a few real-world examples might be useful. It’s important to note that, while these were actual choices of product-led companies, these examples are by no means the only way and may not be right for your context.

Here are a few examples of what being product-led might look like:

Structural choices:

- Teams and departments are organized to optimize for flow of customer value delivery to reduce handoffs and dependencies along these lines.

- A company has a Chief Product Officer (CPO) with years of demonstrated modern Product Management experience and ability to mentor less experienced product leaders.

- Development is primarily considered through the lens of business and customer value. Architectural roadmap initiatives are opportunistically pulled through based on current feature development. There is a VP of Product Development that reports to the CPO.

- Sales is considered an operational function of the product strategy. There is a VP of Sales that reports to the CPO.

Strategic choices:

- A company separates its strategic goals from its financial and operating (FinOps) targets. Both may be of equal importance, but FinOps targets are not thought of as a strategic outcomes.

- The company vision statement is written in terms of new customer capabilities or experiences.

- Strategic goals and initiatives are considered in service of achieving the company vision and are framed as problem or solution hypotheses.

Sales choices:

- Sales only sells the features available in the current product. If a potential customer desires a new feature it is discussed with multiple strategic team members to evaluate the request against product-market fit, business opportunity, and risk.

- Sales is trained to message the org’s  ability to be in touch with customers and market needs.

- Sales can provide examples of the org’s ability to lead or quickly adapt to industry needs and a history of delivering usable, quality features quickly.

Technology choices:

- Architecture roadmaps are product-driven. Product and tech leaders understand the architectural direction and risks and then use current feature development to pull architectural work into play.

- Product leadership is trained to understand the business value of a well-factored codebase, a maintainable test harness, and continuous integration, deployment, and delivery.

- Technical debt is prioritized by business value. Typically this is improving the changeability of a codebase that is about to receive heavy feature development work, or getting rid of a major “bug factories” that reduce delivery capacity.

These are just a handful of examples. There are certainly more. What have you seen or experienced that you feel help an organization become more product-led?

-Matt Barcomb


3 Fundamental Org Design Issues

Sometimes when you try to change something in an org it feels harder than it should be. Almost like there's some invisible force working against you. This is often perceived as resistance to change. Sometimes folks continue to try and find other methods that would be easier for the org to assimilate, but often with similar results.

What if the challenges with change aren't directly with the change but more fundamental issues? Sometimes we might talk about the org not having the right mindset or culture. But culture is an outcome. What parts of the system strongly influence culture? Maybe we could change those.

Over the years I’ve observed three broad buckets for these invisible forces. They’ve become what I think of as Fundamental Org Design issues.

1) Organization Structure, Roles & Policies

These are often the most visible or tangible issues. Who reports to whom, where people are located, whose responsible for what, and what rules are in place for what reasons.

2) The Incentive System

This can be a little harder to detect. Some things are easy and those things tend to be explicit rewards. Things like salary, bonus, promotions, awards, etc… However there are things that are harder to notice but are just as much (maybe more so) a part of the incentive system. Things like status, reputation, responsibilities, autonomy, etc…

If you’re interested in understanding more about your incentive system, check out the Incentives Analysis Canvas.

3) Acceptable Impactful Behavior

Some of this may fall under what Google or Modern Agile call psychological safety. But to me this refers specifically to any routine behaviors that are tolerated or considered generally acceptable that impede information flow, reduce people’s creative engagement or, limit the amount of inclusiveness within the org.

While these buckets are obviously broad strokes there are few things I’ve experienced as resistance to change that cannot be traced back to one of these issues.

So my current big question is, if this is true, why do we ever undertake any kind of change without first understanding the fundamental issues that effect it? Maybe we should consider starting our change with these lower order, fundamental changes first. Maybe that would be too much, or too political, or too hard...but those seem to be the same reasons given for why changes fail.

I’m curious, does any of this ring true with you? Have you ever tried changing things at the fundamental level first? Did it make a difference?

-Matt Barcomb


Being "Intentionally Adaptive"

One of the major things I see limiting many companies is their ability to act intentionally as an organization. By acting intentionally I simply mean doing things on purpose with evidence.

This starts with being thoughtful and reasonable about what goals you’d like to achieve as a company as well as what kind of company you’d like to be overall. It means admitting where you’re at and acknowledging the work needed to improve, using equal parts passion and skepticism.

I think a major part of being intentional is also thinking systemically. While perfect knowledge is not possible in complex systems this doesn’t mean that intentionality should not consider the various parts and connections of these systems.

Acting economically is another key aspect to being intentional. Understanding your options, values, costs, and trade-offs for all the various decisions and actions that could be made is the epitome of intentionality.

It’s important to temper intentionality, a stabilizing, conservative force, with adaptability. The ability to remain flexible and be resilient over long periods of time.

In order to be adaptable, and organization must first be resilient. Able to withstand current or imminent threats and risks. Resiliency poorly implemented can tend to be inefficient but this does not have to be the case. Resiliency is also key to fluidity and responsiveness which are important traits for being able to seize unplanned opportunities, not just persevere through threats.

Over the long term, a resilient organization will be able to adapt. Leveraging the intentionality mentioned above will allow organizations to sense and respond to shifts in its surrounding ecosystem while still maintaining directional viability and sticking to core principles.

Of course there are other principles that most organizations would find useful. Empathy and humanism are towards the top of my list. Generative and sustainable also make my top ten. But for most places, while there will always be room to improve, I think "Intentionally Adaptive" is a great place to start. It builds good foundational skills and often leads to other principles in the long run.

What are ways your organization is being Intentionally Adaptive? What opportunities do you see for being more Intentionally Adaptive?

-Matt Barcomb