Agile/Scrum Software Development and Product Management


I think ours is the only Product Management blog in the entire blogosphere that has not yet had at least one post on Agile/Scrum software development. That is….until now.

I’m not so sure it was a conscious decision on any of our parts. There is so much other good and relevant stuff to write about, like iPhones and iPods for example. 🙂

But seriously, I don’t think we have written about Agile because, and I’ll speak for the 3 of us, it’s not that critical to product management. There I said it!

NOTE: where I use “Agile”, it implies a combination of Agile/Scrum

If you are not familiar with Agile or Scrum software development, you can read more in many locations on the web. A good starting point is, as expected, Wikipedia. Read up on both Agile and Scrum methodologies. While quite distinct in many ways, it’s important to understand both Agile and Scrum and how they are inter-related in practice. In fact, the first line of the Wikipedia entry on Scrum reads:

Scrum is an iterative incremental process of software development commonly used with Agile software development.

While not an absolute definition, and clearly some may argue, I view Agile as more of a culture or approach to software development, whereas Scrum is more truly a methodology, with specific roles, practices etc. that can be implemented. In many cases, when people say Agile, they imply Scrum as well.

As mentioned earlier, Scrum defines a set of roles. One of the key roles in Scrum is the Product Owner. That role is defined as:

The Product Owner represents the voice of the customer. They ensure that the Scrum Team works with the right things from a business perspective. The Product Owner writes User Stories, prioritizes them, then places them in the Product Backlog.

Now, this would most likely map to the Product Manager in most software companies. While true at a high level, another key element of Scrum is the daily scrum meeting where every member of the team, including the Product Owner attends.

Now, imagine if you as a Product Manager had to attend a development meeting every day. When would you get out of the office? When would you meet with customers, partners, prospects etc.?

One big mistake a lot of people make is assuming that the Product Owner has to be the Product Manager. While conceptually that may be true, the Product Manager cannot, and in my opinion, should not attend these daily scrum meetings. I’ve worked in PM role in two previous companies that used Agile/Scrum development methodologies, and I think I attended one Scrum meeting. We still had regular communication with the development teams and regular product reviews etc. but we weren’t embedded into the development process the way some people might think we should be.

Other roles such as Product Designer need to be defined to take that day to day decision making role and act as the Product Owner, or at minimum, be the proxy for the Product Owner (if that is the PM) so that the PM doesn’t get bogged down by daily scrum meetings.

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 marshalling the product from development through marketing, sales etc.

Here’s an analogy. Sales teams invariably follow some kind of sales methodology. It could be strategic selling, solution selling, or conceptual selling. It could be some other model, or even none at all. If the sales team decides to adopt or change their sales methodology, do other related teams like Marketing or Product Management have to change how they work?

The answer is NO. So, then why should those changes happen to Product Management if the development team adopts Agile/Scrum? Our job remains the same. Understand the market, customers, competitors, merge that in with business objectives etc. define what needs to be built and move that through all the stages of development/launch/post launch to enable product success.

If in a few years, some better development methodology comes along, and is adopted by the engineering teams, will that change what Product Management does?

NO.

Development methodologies should be a grey box for Product Management. We should have an understanding of them, but we don’t need to become an “embedded” part of their implementation. It’s all about loose coupling and clear lines of communication. We have our objectives, and Development has theirs, and when we need to interface, we do so in an efficient and mutually convenient manner.

Let me put it this way, and pardon the analogy if it is a bit inappropriate. Product Management and Development don’t need to be married to each other to be efficient. The relationship needs to be more like a “friends with benefits” arrangement. i.e. the two hook up on a regular or as needed basis. 🙂

Saeed

Agile/Scrum Software Development and Product Management (part 2)

Agile/Scrum and Product Management (part 3)

Agile/Scrum and Product Management (part 3a)

Advertisements

21 responses to “Agile/Scrum Software Development and Product Management

  1. Hi,

    Nice post and I agree to most of what you said here. Agile/Scrum is more a development process aimed at optimizing “how” a product is made. On the other hand, product managers have a bigger and more crucial question to constantly answer – “What” is the right product to make.

    ~bhuwan

  2. Thanks for an excellent post!

  3. Well said, Saeed! Many companies have assumed that Product Owner is equal to Product Manager. That’s a recipe for disaster — Product Managers can’t be in the daily stand-up, or the team will reach a point where they don’t know what to do next. Product Managers need to be in the market, because ultimately the market knows its problems, and Development does not. On the flip side, Development understands how to create and build great solutions, and the market does not. Product Management has to be that bridge between the market and development, by studying the market and defining the most important market segments, personas, and problems — and we can’t do that if we’re in the building, involved in the daily workings of Development.

    Thanks for writing.
    Stacey

  4. I have to admit upfront that I am not now, nor have I ever been, involved in any way with Agile or Scrum as a development method. I am intrigued by the iterative nature of those methods, but as Saeed said, I don’t see how the development methodology affects what I need to do as a Product Manager.

    I already attend multiple meetings with Development team members, not including the ad hoc ones that occur in the hallway or in a cube. How does a stand-up meeting with all of Development and the PM reduce this? I don’t think it will.

  5. I don’t agree with you. Unless you understand how something work how can you expect to manage it well? If you don’t want to know how your product is being built and you don’t want to get involved then results must be mediocre at best.

  6. Hello N

    What part don’t you agree with? That product management shouldn’t attend daily scrum meetings, or something else?

    If it’s about the scrum meetings, does that mean that before Agile/Scrum, product managers could only deliver mediocre results? I’d like to understand your position better.

    Saeed

  7. How many teams are you involved with? If more than one, then attending the scrum of scrums might be the way to go. The value of the daily scrum is that it’ll keep you up to speed on where the team is. It’ll also highlight areas that they need your help (i.e., your lack of response on a question could be blocking them). It is important that this meeting is kept short (10-15 minutes or less).

    Particularly for the scrum of scrums, it might be valuable for someone to capture its results and send them out to the team as a brief email. Since not everyone attends (usually just one or two from each team), this is a good way of keeping the larger team up to date (including you when you’re traveling).

    If you’re stretched too thin, you could use someone playing a role that we labeled as a requirements architect. In our case, this was our development architects who helped to map from the what to the how (bridging the gap with the teams on a daily basis).

    Probably more important (and more time consuming) than the daily scrum is your participation in iteration planning, demos and retrospectives.

    There will be other affects on the product manager when switching from waterfall to agile. You’ll want to approach your requirements differently. Instead of a list of things the software should / shouldn’t do, you should break it down into stories where each can be implemented independently, will add customer value and the team will be able to accomplish within an iteration.

    Instead of saying “must”, “should”, or “frill”, you should rank them and update that ranking every iteration based on what was learned. Agile is all about attacking the most important things and changing based on what you’ve learned.

    You’ll also want to rethink how you present road maps to customers. See http://www.walterbodwell.com/node/5 for some ideas on this.

  8. So, where does it say that if you move to an Agile/Scrum methodology that Development can make decisions on functionality without first consulting with the Product Manager/Product Owner?

    Our development team has recently moved to Agile/Scrum and they are using some of the Agile principles such as “Evolutionary Requirements” and “Self Organized Teams” / “Empowered and Motivated Teams” (i.e. the ability to make decisions without management approval) as justification for changing existing functionality and usability decisions for new functionality without first discussing them with anyone.

  9. Pingback: Agile/Scrum Software Development and Product Management part 2 « On Product Management

  10. Steve,

    See my response in part 2 of this series.

    Saeed

  11. Pingback: Speaker City » links for 2008-07-28

  12. Pingback: Agile/Scrum and Product Management (part 3) « On Product Management

  13. Pingback: Agile/Scrum - Reality Check « On Product Management

  14. Pingback: The Cranky Product Manager never fails to disappoint, plus a blog you should read | The Cranky Product Manager

  15. Pingback: MatHamlin.com » Blog Archive » links for 2008-12-07

  16. Pingback: Agile/Scrum and Product Management (part 3a) « On Product Management

  17. We’re using Scrum here for several projects. I am called (in Oracle-ese) an “outbound” PM, which basically means that my interest is customers, channels and the market. In our implementation of Scrum, I am not a “Product Owner” in Scrum terms. The “inbound’ PM and the engineering manager are considered the Product Owners, and I am fortunatel that I rarely have the need to participate in anything directly related to Scrum. My interface with the engineering project is primarily via our requirements management system, where the business requirements for the release are captured and discussed. Those business requirements are used to feed the Scrum backlog and drive sprint planning. It appears to work quite well this way, and we are managing to carry out development sub-projects in the release with close cooperation between three sites and four different Scrum teams.

  18. Michael,

    Thanks for the comment. The outbound/inbound PM is one accommodation that works with Scrum. A few of questions for you if I may.

    1. How closely do you work with Inbound PM?
    2. Are you colocated with them?
    3. Do you report up into the same Directors/VPs?
    4. What is your relationship with Product Marketing?
    5. Where does your responsibility end and their’s begin?

    Thanks

    Saeed

  19. Pingback: Adam Bullied vs. Enthiosys: Don’t Fight! « On Product Management

  20. Pingback: Agile and Product Management