Adam Bullied vs. Enthiosys: Don’t Fight!


Adam Bullied has a post last week entitled “Are agile PMs baloney?

First off, great title. No burying the lead here. You can read the post on Adam’s site, here’s the key point he makes:

My belief has always been, product management doesn’t change that much regardless of whether you are in tech (B2B or B2C), consumer products (like soap or fabric softener), cars, electronics, etc… Essentially it all boils down to the exact same things: you have a market, and they have a problem. You are charged with crafting the most ideal way to solve that problem, and then making that vision a reality.

Regardless of HOW those charged with executing that vision (or building the requirements) choose to do that, your paradigm doesn’t change. Developers can be working in waterfall, or they can be working in agile. You, as a product manager, shouldn’t care.

This is really interesting, as I wrote the following in one of my first posts on Agile:

Keep in mind, Agile/Scrum is a DEVELOPMENT methodology. It is a great model for developers and engineers and other R&D team members to work and communicate more efficiently. There are very clear benefits to this model. It provides greater visibility into current work status, work remaining, can identify development hurdles earlier and can communicate them outward more easily.

But, in the end, it is still a development methodology. It should have minimal impact on Product Management’s job as a cross-functional leader marshaling the product from development through marketing, sales etc.

Now the remarkable thing about Adam’s post was the sheer number of comments generated; almost as many as a Failblog post! There was also a lot of passion evident in many of the comments. I even got into the act with a few choice comments myself!  (here and here).

But not everyone agreed.

A shot across the bow?

Shortly thereafter, the folks at Enthiosys posted an article on their blog entitled: How To Sound Smart (But Be Really Naive) About Dramatic Changes in Technology

I know both Adam and the team at Enthiosys personally. I like  and respect them all,  but I’m going to have to take sides here, as this issue of Agile (or agile) and Product Management is something that I’ve blogged on quite extensively.

First off, the title of the Enthiosys post comes across like an ad hominem attack on Adam. Maybe it wasn’t meant that way but it sure sounded like it to me.

The author of the post states:

I’d reframe his question (“Are agile PMs Baloney?”) into something meatier: “Do radically different ways of building software radically change how software product managers do their job, and how does this change our thinking about delivering value to the market?”

So, that’s actually a very different and rather pointed question, not simply reframing the original question.

I also think that the reframed question implicitly pigeonholes the focus of product management into something far less than it actually is.

Let’s start with an analogy

The Enthiosys post continues with the following example:

Suppose I was an industrial designer working in the early 1950’s. My job? Creating new tools for machine shops. My tools? Pencil and paper. Clay and wood prototypes. My development process? Relatively slow. Feedback loops? Long. To compensate, I work as much experimentation into my process as I could, but, let’s face it: there was only so much experimentation that I could try.

Fast forward to today. I’m still an industrial designer making tools for machine shops. Except now I’m not using pencil and paper, I’m using a sophisticated CAD-CAM system. I might be using wood and clay, but chances are good that I’m printing my prototypes. My development process? Fast. Feedback loops? Short. My ability to experiment with alternatives, and to use experiments with customers, is so easy that I find myself naturally collaborating throughout my process.

Now, ask yourself: Has the job of the industrial designer changed?

My response…Darayush’s words

First an answer to the question. I’ll quote from one of the comments on the Enthiosys post left by Darayush Mistry:

The job of an industrial engineer hasn’t changed. The tools have. An industrial engineer with good fundamental skills would be just as effective in the 1950’s as today. A good cook will be just as effective regardless of the tools, cause cooking is all about understand the fundamentals of how ingredients mix/blend/cook at various temperatures rather than the hi-tech gas range and ovens.

I fully agree with Darayush on this point.

My response…my words

Second, the analogy of the industrial designer is not a good one. The difference between Agile development and previous development methods and their relationship to Product Management is not the same as the difference between pen/paper/wood/clay and CAD/CAM systems and the relationship to an industrial engineer.

Why? The industrial engineer is NOT analogous to a product manager. The engineer will build a prototype or tool based on requirements or specifications provided to him/her. Someone had to decide and define what new tools were needed, what purpose they’d serve etc. If it was the industrial engineer, he/she would have done this BEFORE creating anything in pen/paper/wood/clay or using CAD/CAM.

Once the engineer has those requirements or specifications, they can certainly create prototypes and designs faster with CAD/CAM tools, but at that point, they’re functioning in a role more like a product designer or a developer.

Third, and I think this is really important, the product management relationship with product development is only one aspect of the role. Product Managers must be focused on the business success of their product, not simply the “manufacturing” of it.

Finally, I think it’s very important that Product Managers in the high-tech community understand that they have a critical business role to play in the success of their companies. There are a lot of obstacles in the paths of these Product Managers.  The profession is still young and not well understood. There are few if any good preparatory programs to equip Product Managers with the tools and skill sets they need to be successful. Power politics in companies weigh heavily on the success of Product Managers. With these and other obstacles in the way, the last thing Product Managers should be doing is attaching potentially confusing or misleading terms such as “agile” or “Agile” to themselves.

What happens a few years from now when the focus on “Agile/agile” diminishes in the Development community? What happens when the next new and innovative and hyper-efficient software development model comes out? Will a new adjective need to be attached to the title “Product Manager”?

And finally…really!

Product Management needs to be defined on it’s own terms. We as a community need to take that responsibility on ourselves. Tying our profession to what is fundamentally a software development methodology, no matter how potentially applicable it’s core principles may be to other domains, is not the right thing to do. It will not bring clarity of the purpose and full value of Product Management to others.

I argue (quite successfully I must say :-)) in this post, that Product Management has always been agile and that it is Development that is finally understanding the value of being nimble, adaptable to change, not tied into rigid methodologies etc. The Agile Manifesto was a call for change in the Software Development community, not the Product Management community.  Let’s keep that clearly in mind.

Saeed

Advertisements

13 responses to “Adam Bullied vs. Enthiosys: Don’t Fight!

  1. I don’t want to take a position on whether Adam’s original blog entry was “naive”.

    However, Saeed, I do want to comment on the Enthiosys analogy of an industrial engineer’s job having changed over the years. Darayush Mistry’s reaction was:

    “The job of an industrial engineer hasn’t changed. The tools have. An industrial engineer with good fundamental skills would be just as effective in the 1950’s as today. A good cook will be just as effective regardless of the tools, cause cooking is all about understand the fundamentals of how ingredients mix/blend/cook at various temperatures rather than the hi-tech gas range and ovens.”

    And you stated:

    “I fully agree with Darayush on this point.”

    By Darayush’s reasoning, agile hasn’t changed the job of software engineers who practice it, either. I.e., the job of software engineers who practice agile “hasn’t changed, but the tools have.” After all, the job of software engineers remains

    Do you agree? Do you accept the conclusion that the job of software engineers who practice agile is no different from those who practice waterfall?

  2. The last sentence of the second-to-last paragraph in my last comment should read, “After all, the job of software engineers remains: to implement software.”

  3. Roger,

    Thanks for the comment. I agree the job of individual engineers has not changed, but how they manage their daily work has.

    I have the feeling you’re going to lead me down a path of logical reasoning towards a particular conclusion. 🙂

    The issue here though is not engineers, but Product Management and Product Managers, and how they can most effectively do what they need to do.

    Product Management is a multi-faceted function and it should primarily be a business function — optimizing the business of the product, product lifecycle management etc.

    The interface with Engineering is only one aspect of that role. Thus if Engineering changes how they want to work, then how Product Management interfaces with Engineering may change, but it may not. It depends on a number of factors including maturity and size of the organization, the type of product etc.

    My main point is that description of “agile” or “Agile” Product Management is unnecessary if it is simply a reaction to Agile development adoption.

    Saeed

  4. Saeed, the immediate direction I’m going is to show that part of Darayush’s point is either irrelevant or false.

    If we treat “the job of the industrial engineer” as synonymous with “the goal of the industrial engineer”, then, sure, the industrial engineer job hasn’t changed in the scenario described in the Enthiosys blog entry.

    Similarly, if we treat “the job of the software engineer” as synonymous with “the goals of the software engineer”, then the software engineer job hasn’t changed in an organization that’s adopted agile.

    Finally, if we treat “the job of the product manager” as synonymous with the “goals of the product manager”, then the product management job hasn’t changed in an organization that’s adopted agile.

    But the argument becomes irrelevant, because it fails to distinguish the affect of agile on the software engineer job from the affect on the product management job. Remember, the claim has been that agile is a development methodology, and thus fundamentally changes the development organization (software engineers) but only incidentally touches product management.

    Alternatively, if we treat “the job of the industrial engineer” as synonymous with “the way an industrial engineer manages his daily work”, then the job has changed quite a bit in the Enthiosys analogy, and Darayush’s assertion is false.

    At the end of his comment on the Enthiosys blog entry, Darayush wrote:

    “I think there are fundamental skills that a Product Manager should understand and possess and tools/frameworks like Agile/Scrum just augment them. Don’t get me wrong I’m not saying you don’t have to acquire additional newer skills to learn these new tools/frameworks to make your self more efficient/effective in what you do. However to me it’s a layer that you put on top of the core skill set.”

    I agree completely. However, the same exact statement applies to software engineers and their skills.

    Spread out in comments in several blogs, there have been many specious arguments claiming that agile changes development but denying that agile changes product management. In each of these cases, the arguments have failed, because the reasoning applied to development also has applied to product management. Darayush’s argument is a case in point.

    You have made several separate points that deserve to be addressed. I plan to address them in a blog entry of my own.

  5. I have written a blog entry on the issue of whether product management is primarily a development methodology. I believe it addresses the core of yours and others’ arguments.

  6. I wonder whether this discussion would benefit from bringing some non-PMs into the loop, specifically some development managers and/or technical VPs and/or CIOs. Then let’s go to the other end of the spectrum and ask some sales/marketing types, and end up our “alternative perspectives” worldview tour with a LOB exec.

  7. Hmm, you sure hit a hot button. My personal opinion is that this question can be quickly and easily answered simply by taking a look at where a Product Manger spends his / her time. The actual amount of time spent on worrying about product / feature creation is generally somewhere about 20% of a product manger’s time (from my experience). The rest of the time is spent on sales, pricing, support, competition, business plans, forecasting, focus groups, etc.

    That means that roughly 80% of a PMs time is spent on non-product related tasks. Agile or not, the development of the product has relatively little impact on a Product Manger – as long as it gets done on time!

    – Dr. Jim Anderson
    The Accidental PM Blog
    “Home Of The Billion Dollar Product Manager”

  8. Jim, agile methods affect (and enhance) many of the alleged non-product related tasks you mentioned. For example, pricing often requires an iterative approach. You never know how much customers are willing to pay until you “test” the market with working product.

  9. Bob, a director of engineering weighed in with a comment on my blog.

  10. I think Saeed pinpointed the bigger issue here, and I think that that point is getting buried under the details and propaganda of both camps. Agile was proposed first and foremost as a software methodology. No issue there. It works, there have been fantastic results (and I mean that sincerely), and everybody is generally happy. It’s once the methodology is imposed on other facets of a product or project that issues start to arise.

    A publishing company can use agile in its development groups, and as long as it’s a purely Dev implementation, things are fine. However, if the product in question is contingent on new content or leveraging licensed content, it can and will bring everything to a screeching halt. Bringing a third party into the equation, especially one that is quite accustomed to dictating its own schedule and terms, can effectively put any product on hold. Agile might help in reallocating resources for issues like this, but I can’t help but feel that a traditional PM may be better able to account and mitigate situations like this than the agile counterpart, simply because there is a greater focus on the long-term schedule and risk assessment.

  11. Thanks for the comment Russ.

    I’ve said this in other blog posts, and Russ says it as well, though a bit differently than I have.

    For tightly-coupled tasks — e.g. where everyone works very closely together in a dependent manner — Agile methods are very good.

    But as Russ’s example points out, bringing outside parties into the mix can break the efficiency cycle.

    Agile (with capital A) and Scrum in particular is about moving forward efficiently towards a set goal. The daily standup meetings and burndown charts are about visibility and ensuring barriers to progress are cleared away as quickly as possible.

    There is a certain binary religiosity of Agile vs. Waterfall that tends to cloud more nuanced discussions of the benefits AND detriments of Agile. No system is perfect, let’s admit that, agree on the benefits (if possible) and move forward without getting entangled in philosophical debates. 🙂

  12. Saeed’s points are some of the most reasoned that I have seen on this subject. Remembering that not all product management equals software product management clarifies that there are a lot of other tasks that a product manager has to accomplish for any kind of product. On the other hand, there are many uses for Agile-like techniques in any kind of product management — common sense should prevail.

    Also, in some organizations, product development is only a minor part/ minor cost of the “whole product” development which may include distribution plans, partner coordination, sales launch activities, PR, inventory rebalancing, etc. Agile must fit gracefully not only into the product development process but into this “whole product” process and must be evaluated by this yardstick.

  13. Pingback: Happy (belated) birthday to us (again)! « On Product Management