Falling into the How Trap
Yesterday I talked a little about how companies focus too much on process… how they are doing their work… rather than the actual business outcomes they are trying to deliver. This is a really big problem that impacts all levels of the organization. I bet if you took a good look at your company you’d find great examples in your corner offices… and in your team rooms.
我’d like to take a moment to go over a simple example that I see over and over in the agile community. I hate to pick on Scrum again (the price of success?)… but Scrum is basically a HOW solution… a process… that solves a particular organizational dysfunction. We need things like business alignment and servant leadership… we need the ability to inspect and adapt and respond to changing business conditions. What Scrum gives us is Product Owners, ScrumMasters, Iterations, and Retrospectives.
我f Scrum works though… why does this matter?
When we start thinking that the goal is to have a Product Owner… even a trained CPO… the focus shifts from WHAT we are trying to accomplish to HOW we are going to accomplish it. I need the business to be able to make prioritization decisions… I need clear direction on what to build next… I need clear requirements definition… I need user acceptance. The Product Owner is merely a HOW that satisfies the WHAT…in some contexts. What if my context changes?
What if I can’t have a dedicated Product Owner for every team? What if in my company… the Product Owner role is too big for one person? What if I need to guide and coordinate multiple teams across multiple timezones? If I focus on implementing a HOW… the Product Owner role… I lose the opportunity to create new strategies that deliver the right business outcomes. If I focus on the WHAT… I am now free to craft a strategy that delivers value… AND operates within the constraints of my business environment.
Re-thinking the Agile Enterprisetakes a systematic look at what we are actually trying to deliver… the core capabilities of our business… and lays out a strategy… a framework… for creating situationally specific strategies to scale agile in the enterprise.
评论s (13)
Roger L. Cauvin
我think you hit the nail on the hit by characterizing "product owner" as a role. As a role, it can be filled in many different ways. Often, I think a combination of people is needed to fulfill all responsibilities of the role.
Mike Cottmeyer
Totally agree. The problem is that folks want to assign it to a person because Scrum prescribes a very specific HOW to address the PO role. When you start thinking about the WHATs behind the PO role… it leads you sometimes to different solutions.
annaforss
我agree on that too many are too focused on the process. It can almost feel like the interpretation of a religious text. I've many times discussed the handling of bugs. Guru X says include on product backlog, so that's the way to go. Oh no, guru Y says the opposite, don't do that. And the bugs are still popping up and are not fixed.
对我来说，产品主是最后一个前哨基地，如果您不知道该去哪里，您会转向那个灯塔。当开发人员搜索答案时，人们可以避免这种情况，将其指向其他地方，并最终猜测开发人员。有时是一个很好的猜测，通常不是最好的选择。
The product owner role means that when a developer don't know where to turn, he goes to the product owner and he's responsible for getting that answer. I cannot as a product owner duck for those questions.
This is why I see this as a single person responsibility. When you are two, you can refer to each other. But this does not mean that you must have a dedicated product owner for a scrum team. What is important is that developers feel that they know who can get those answers and get them in time.
有趣的帖子，一如既往
Daryl Kulak
Distinguishing WHAT from HOW at this level is helpful.
但我have to ask, when does "Why?" come into it. This is a piece of Agile that is often missing, where we are asking why the Product Owner is doing something, understanding it in the current context and making sure it is still something that makes sense.
Too often, we get into a "mechanical mindset" where we're following Agile practices just for the sake of following them, not asking "Why?"
What do you think, Mike?
Mike Cottmeyer
Anna,
如果我正确阅读您的评论……您对Scrum的教条主义感到不舒服……但是仍然觉得团队必须有一个人来回答问题？
对我来说……基本的业务一致性。亚博vip9通道Scrum说，团队需要清楚他们将要建造什么以及在哪里获得其他信息。如果两个人可以扮演这个角色……好吧。如果一群人可以扮演这个角色……那也很酷。
我f two or more people can't do it… then again… we have an alignment problem. Solving alignment by putting in a PO only pushes the alignment problem outside the team and forces the PO to deal with it.
Make sense?
Mike Cottmeyer
Daryl,
我think that the WHY is in between the WHAT and the HOW. Your observation is really the key concern behind all of this. If we put in a PO without understanding WHY we are doing it… without understanding the WHAT behind the HOW… we are following blindly.
我f we understand the WHAT… the HOW and the WHY should support each other. I guess my point is that I think it is all related.
Someone might make the case that Scrum is a beginner level practice… do it the ONE way first… and once you learn it… adapt it. The problem is that many organizations are too complex right out of the gate for entry level Scrum.
Daryl Kulak
Mike,
是的，我主要同意。使用“盲目关注”模型作为开始使用敏捷/Scrum的组织是我看到的一个问题。我觉得有太多的盲目追随者，无论是这样做的组织还是说服他们这样做的顾问（使咨询更容易）。
Since I am an Agile consultant, I try not to fall into that, but it's hard not to.
Mike Cottmeyer
The problem is that everyone says 'scrum scales, scrum scales'. The question you have to ask is… does it scale without radically changing how your organization is structured. Do you have the authority to make the changes necessary to really scale Scrum?
Some clients I talk to like the simplicity of Scrum and want to use that metaphor all the way up. Having a conversation about UP, DSDM, or Lean can be challenging.
Mike
Troy Tuttle
好贴。我已经观察到了几年，这就是为什么我认为精益软件填补了这个空白的原因。精益从“什么”而不是“如何”开始。
annaforss
Yes, the dogma can be annoying, but hey; which community does not debate this type of issues. I don't think the agile community is worse than others. But we could be better.
是的，我认为拥有一个产品所有者不是绝对的规则。今天，我们有两个平行的项目与不同的正式产品所有者，但我们都充当团队的POS。他们可以求助于我们中的一个，我希望他们能确定这个问题是独立于当时的谁被无用的回答。
When I think more about it, it's as always a question of accountability. No one should feel comfortable avoiding a question and leaving someone who needs an answer. And this is the core of the concept of the product owner being a part of the team. As Ken Schwaber puts it; the only title is Doing The Best One Can, and in the case of the product owner people, that is probably getting answers to all those questions.
这应该不是问题，但是是。人们喜欢对软件开发有话要说，但不喜欢做出艰难的决定。负责选择剪切和做什么。这就是为什么我们实际上需要产品所有者的概念，即单一可扭曲的脖子。
我n the best of worlds, we don't need that.
Mike Cottmeyer
Anna… I don't disagree… but in most organizations… especially at scale… the single-wringable-neck doesn't exist.
How are we going to handle it when it doesn't?
Are we going to give up and say agile won't work here? I hope not… I think if we think about the problem properly we can craft a situationally specific strategy to overcome that obstacle.
Paul Boos
Actually, I would say if you are looking for a single wringable neck, then you are looking for accountability because no one is stepping up to take responsibility for getting ti done; either singly or collectively.
无论如何,我们总是推荐给我们的客户to provide a single person with a back-up and then for that single person to bring in others that will provide advice. It's not that it truly is necessary, but as a convenience for scheduling time and such it is easier for our customer organizations to provide that one person as opposed to many people.
So I guess we do it out of convenience.
but then after reading another post today, I think we are doing agile; we aren't yet agile – we're still consciously learning (at least we know we don't know stuff).
Roger L. Cauvin
Anna, let me give you a concrete example of how it makes sense to spread the product owner role across two people. Let's say the team has two questions:
1. How much time should it take for a user with a given profile to use the product to complete a particular user story?
2. Should the user story be implemented in terms of a wizard-based interface or some other interface?
尽管这两个问题都与用户体验有关，但它们却非常不同，需要不同的专业知识。
The first question requires a thorough understanding of users and what level of usability is necessary for the product to be successful in the marketplace. This kind of expertise and responsibility typically lies with a product manager.
The second question requires interaction design expertise. A person can have all of the market and user knowledge in the world and not have the interaction design skills to answer the question competently. Typically, this expertise lies with an interaction design or user experience professional.
如果团队需要单一的问责制（正如迈克所述，可能是一个警察），则您只需向适当的人提供问题。如果这是一个真正的要求问题，则询问产品经理。如果这是一个互动设计问题，则询问交互设计师。如果一个人碰巧扮演着这两个角色，那就这样吧。但it's rare that one person is truly an expert at both product management and interaction design.