Month: October 2008
Richard from AgileCommons.org left an interesting comment to one of my Agile/Scrum/PM posts that I think is worth discussing. I agree with some of what he said, but of course, the interesting parts (IMHO) are where we don’t agree!
You can see the whole comment in the link above, but I’ll pick out the salient parts here. Richard starts:
Scrum’s key value is most definitely NOT in its definition of roles to support a development methodology.
Agreed on this point, the value is not specifically the roles, but for software companies trying to implement Scrum, implementing the roles, such as Scrum Master, Product Owner etc. and processes that make up Scrum are key.
And what I’ve focused on is the Scrum team’s interface role — Product Owner — and it’s relationship to Product Management. There is a lot of confusion in both the Development and Product Management communities about how best to enact this role.
Its genius is giving all of us business veterans a lighter, more realistic project management framework that recognizes results improve when you break large, long projects into short iterations that inspect and adapt along the way.
While I agree with this, the notion of breaking larger projects into smaller tasks is hardly new, nor unique to Scrum. I think my grade 3 teacher taught us this principle, but it is enforced much more strongly in Scrum through the concepts of stories and iterations. The other, and in my opinion, more important differentiators from other methodologies are:
- the daily tracking of both group and individual progress, issues and interactions so as to minimize lag time between when a problem is identified and when addressing it begins
- the tight-coupling of teams such as development and testing during iterations to keep the process moving forward
In fact, given the code and functional interdependencies that are a natural consequence of any software development project, for tightly-coupled teams to work hyper-efficiently, they MUST resort to daily tracking and conflict resolution.
This adaptive approach works equally well for planning a trade show, writing a whitepaper or burning down your backlog of sales tools.
Well, yes and no. Virtually all projects are broken down into smaller more manageable and measurable tasks. When writing a whitepaper, one might break it down into smaller steps such as initial research, initial draft, first edit review, updates, second edit review etc. But in this case, unless there are several people writing and editing the whitepaper simultaneously, there is no “scrum” to speak of and the benefits of Scrum don’t come into play.
I would argue that trade show planning would be similar. While again there is benefit to identifying smaller, more measurable tasks, a lot of the tasks are completely independent from one another — e.g. booth design, giveaways, demo and script preparation etc. — and all have to be done by certain dates but are not directly interdependent. i.e. these are loosely-coupled tasks. If there is no tight-coupling of teams, the value of Scrum is diminished though not eliminated.
Dean Leffingwell says it best in his “CIO Playbook:”
Know where you are every day with Scrum
– or –
Think you know where you are on your well-formed plan
and discover that you are very wrong, very much later
There is a bit of religiosity entering the discussion here. No project tracking mechanism is entirely accurate. And any process can be executed on well or poorly. I’ve seen many projects executed and tracked well via non-Agile/Scrum methods.
Scrum does — as I said in the first post on this topic — “provide potential for greater visibility into current work status, work remaining, can identify development hurdles earlier and can communicate them outward more easily.” But there are no absolutes here.
Scrum is not a panacea. And while it can likely be applied to other domains than software development, the current focus of the Agile Alliance and certainly that of the Agile Manifesto is on Software Development. And for good reason.
Software projects are very complex. The final result — “the software” — must be flexible, scalable, secure, robust etc. It must work. There are a lot of dependencies and unknowns that must be resolved as part of the software development process. Those dependencies can be in the software code itself, interaction with 3rd party software or hardware, and under conditions that may be difficult to plan for and test. These dependencies and complexity can only be minimized with constant vigilance and communication. This is why Scrum is suited for software development.
Other tasks that don’t have the complexity, level of dependency, or unknowns that software development has, will not benefit as much, and sometimes not at all, from Scrum-like methodologies. Ask yourself, could HR go Agile?
Given adaptive management approaches are better than predictive methods whenever you have unknowns, the rest of the business absolutely needs to “bend and accommodate.” If development is finally able to deliver customer value faster, what is preventing your company from experiencing the revenue gains? Is it because Marketing can’t adapt to the new pace? Support? Sales? A lame install & update process?
Put it another way, if your #1 competitor is consistently delivering new features in half the time you are, how long do you think that is tenable?
So here’s where the crux of the problem lies. It’s an engineering centric view of the business. As I read the paragraph above, I can’t help but think a few things:
- Richard is an engineer given the snarky comment about Marketing and the comment about “lame install process” (no offense intended Richard if you are not an Engineer)
- The air of superiority I hear from many Agile advocates over other project tracking methods reminds me of certain political or religious campaigns. Lower the intensity level folks!
- Customer value is about more than just software features sooner. If Development can work faster than before, that doesn’t mean the market or customers are ready to accept product every 4 months vs. every 6 months. Engineers seem to often forget this unfortunately.
- As for competitors building software faster…that has little to do with methodology. My #1 competitor may be twice as big as me (or twice as small!), or their quality may be half of mine, or their feature set is built on a house of cards, while mine is built on a solid architecture. Velocity, to use a Scrum term, is important, but it is only one aspect of what the business needs from the development organization.
- I’ve never seen a Development team that can deliver product faster than a Marketing team can put together and execute a launch plan. Seriously, is this a problem that Scrum needs to address?
Agile may have started out as being about development, but it’s quickly becoming about the whole enterprise.
As I read this last line, I’d like to agree, but the following line comes to mind:
To a hammer, everything looks like a nail.
There are aspects of Agile that can be used or adapted to areas other than software development. And if other teams benefit, then more power to them. But there is little evidence that the “Agile Enterprise” will emerge in the coming decade any more than the “Real-time Enterprise” emerged in the previous one. I may be wrong, but those kinds of changes, if they happen, take a long time and a lot of effort to enact. To paraphrase myself:
Change is a process, not an iteration.
In this post, I’ll discuss where I think the Product Owner should reside in the organization, and some of the issues to consider when making that decision.
As discussed in part 3, and so well illustrated by Dean Leffingwell, the table below lays out the differences between a Product Manager and a Product Owner.
So where does the Product Owner role belong. Well, the answer is…. “it depends”.
The Product Owner is part of the Scrum team, and as I’ve said many times, Scrum is a DEVELOPMENT methodology, and thus, in general, the role should be part of the Development organization.
This does NOT mean that Product Management does not communicate with the Scrum team at all. What it does mean is that the Product Owner must be customer-centric enough and have enough understanding of the requirements to help the development team efficiently work through day to day issues when implementing well defined stories.
The Product Owner lives with the Development team. The Product Manager works with the Development team, but also with other teams such as sales, marketing, support, finance etc. Thus it is really not practical to make the PM also the PO, given the nature of the role.
Earlier I said, “in general” the role should be part of the Development organization. In a healthy and mature development culture, it should reside there. But as we know , many development organizations are neither healthy nor mature. If that is the case, you or the management team in your company need to decide how best to accomodate that role. Perhaps Product Management needs to take charge of the Product Owner role. Maybe some Development teams need someone from outside the org and others don’t. Does Product Management have the bandwidth or the skillset to take on that role?
There are a number of questions that need to be thought through. The end goal needs to be how best to keep the development teams effectively aligned with requirements and customer/market needs. Find the right people for the role(s) of Product Owner and ensure they clearly understand the objectives, and put them in the right place in the organization to maximize their potential for success.
Rich Mirinov stated in a comment on a previous post:
The crunch is when there’s not enough money (or staff or attention) to have both a Product Manager and a Product Owner.
If the company decides to adopt Scrum, then the company must acknowledge the requirements it puts on the development team and staff accordingly. If the company is not willing to do that, then they should wait until they can staff it properly, or understand the trade-off that they will need to make.
If the PM takes on the role of PO as well, the company MUST acknowledge the dual role, and not be surprised when the next set of product requirements doesn’t come out in time, or is deficient.
My concern with the Product Owner being part of the Development group is that there may be too much pressure on them to make decisions that are best for the schedule/easier for the developer or more fun for the developer – and not what is best for the customer or the market. Their allegiances could lie more towards Development and the person that manages them – not necessarily the product.
The ROLE of the Product Owner in Scrum, is to be the “voice of the customer”. That is fundamental to the methodology. If the PO does what is in the developers’ best interests and NOT the customers’ interests, then the PO is not doing their job, plain and simple. It then becomes a management issue to resolve. The VP of Engineering or whomever is in charge, needs to be mature enough to ensure that people in the Engineering org do their job. If that’s not the case, the problems have nothing to do with Scrum or the Product Owner. As mentioned in a previous post:
Scrum is not a panacea for organizational issues
Finally, here’s what I find strange. Before Scrum, Development Managers, UI and Interaction Designers, Developers, Architects etc. were empowered to make tactical implementation decisions. They were also tasked with the responsibility to escalate issues that could result in not meeting requirements. There was regular dialogue (at least in the companies I worked in) between Development and Product Management via status meetings, functional and design spec reviews, UI reviews, feature complete reviews etc.
Now with Scrum, people seem to have suddenly forgotten all that, and feel that the Product Manager needs to be involved in all decisions and that the various touch points that existed previously are no longer needed.
Spec review? Who writes specs in Agile? Remember that line from the manifesto? Working software over comprehensive documentation.
Reality check folks. Hate to tell you this, but Engineering is NOT the center of the universe, and just because they’ve adopted Agile/Scrum, it doesn’t mean the rest of the company should suddenly bend itself to accommodate. Engineering needs to work within the context of the business, and not the other way around.
And Product Management needs to have a backbone and stand up for what is right and best for the products and the business. Wanna really be the CEO of the product? Then ask yourself, what CEO would define his or her business based on the current methodology used by any functional team?
I would expect that most of the Product managers that read this blog don’t put their products on sale very often, if ever (what sales people do is another issue). But today Amazon cut the price of their S3 storage service. I’ve reviewed a few price lists in my time and I can’t think of a single time I cut prices. So is the S3 Product Manager a genius or a fool?
Like many of you I watched the US Presidential Debate on Tuesday night. The night before that I watched a re-run on YouTube of the first debate last month. What struck me more than anything was that neither candidate seemed to take the lead. It reminded me in many ways of salesmen arguing about product features rather than telling a compelling story.
What was missing was the underlying narrative about what’s going on in the US and around the world. With all the money that the candidates spend on polling, research, and spin, I wish they could get their positioning right.
Here’s the outline of what I’d like to hear from both sides. I’m not trying to be comprehensive, mostly just to sketch the format of the argument with a few examples.
America is at a cross-road, and the outlook right now appears dark. If I told you that things just needed tweaking, that would be misleading and dishonest, because what we need is an overhaul of the systems that govern this country. At its core, capitalism and democracy are sound, but we have some problems to fix:
- The capital and financial markets need to be restored to health. Like it or not, the financial system in this country – and around the world – is like the circulatory system of the body; no one notices when the blood is flowing, but when it stops flowing, the body shuts down. In the past two weeks we came terribly close to a collapse of those systems, and getting out will not be easy, but it has to be JOB 1 of the next president.
- The war in Iraq has taken a toll on this country that goes beyond money and into our national psyche. Regardless of what you think about how the war was started, we’ve now inherited a situation that needs to be solved.
- We need to restore the innovative, aggressive, competitive nature of our nation’s industry, across the board. This will not be easy. Some kinds of jobs will never come back to our shores, but we can restore the competitiveness of American manufacturing and we can create jobs that can never be off-shored.
- The social infrastructure that we rely on is breaking our backs. The costs of health care and education are sucking the life out of individual families, and in aggregate, the economy.
Those are the problems, my friends, and we have not faced a situation like this in our lifetimes. We are at a cross roads. BUT!
- We can do it because we’ve done it before! Talk about the nation’s forebearers, the founding fathers, JFK, Abe Lincoln, and current leaders in all areas of society, economic and social. We can climb this hill.
- I believe in us. I believe in you. The America I believe in can tackle these problems. We have the technological infrastructure. We still have the strongest economic engine in the world.
- What we need is leadership that knows the problems, and can pull the nation together to work on them. We DON’T need a leader who will control everything, but one who can see a bright future and bring Americans together to re-tool this country to be the leader of this next century.
The trouble is:
- these problems are not simple, and thus the answers are not simple. Fixing them will require sacrifices. It’s not popular for me to talk about sacrifices; my pollsters tell me that you want bonuses, not sacrifices.
- The reason the financial system is broken: <explain … show you’ve diagnosed and understand the problem, help people understand what’s really going on. If you do this well, you can later explain how you’ll fix it with their help.>
- The reason the healthcare system is broken: <diagnose, explain>
- Diagnose, explain each core problem.
- For Obama:
- Before we can fix a problem, we need to admit it, admit the depth of the problem, and recognize our own parts – as a country, and as members of government – in creating the problem.
- The current administration is defending its record.
- While Senator McCain calls himself a renegade, he is part of the republican system, and his team would be more of the same.
- My opponent really will not admit the problem exists; he’ll talk about the problems in vague ways, but he’s stuck defending his own voting record and his long-standing alliance with President Bush.
- For McCain:
- Talking about hope is different than creating hope; Senator Obama has a lot of spark and some good ideas, but this situation requires more.
- A complex situation like this requires a steady hand and experience.
- Senator Obama has almost no international experiences, and whether you like it or not, we are in a globally connected world. The success of the next 50 years will depend on the ability of your next president to understand world issues and work with world leaders. One or two trips to Europe is not enough preparation for the job, sir.
And I am asking for you to elect me to be your president:
- We will start on day one with initiatives to restore confidence in the financial markets in American and around the world:
- Surely the candidates have ideas here?
- With those initiatives under way, my next priority would be to stimulate the economy: <plan>
- Include a LOT about how average citezens can help. This isn’t about government welfare; it’s about a country getting back in shape, and that requires all of us.
- I believe in XYZ for healthcare, and I would do ABC…
… continue to lay out the platform.
Do you you get the picture?
What I present above puts the argument into a framework that explains:
- The problem(s) we face, and the magnitude of the problem…
… candidates talked about individuals with problems (which is ok), but not as much about the deep structural problems with the country itself and its place in the world.
- But we can do it… show belief; talk about the kind of country this is.
… John McCain did some of this, but not nearly enough… and without an overall strategy to help Americans understand how they can help.
- The trouble with the existing situation (Diagnose the problem), and why my opponent can’t solve it.
… diagnosis was sadly lacking in this debate.
- Why my plan addresses the problem and avoids pitfalls
… again, this depends on a clear articulation of the problems and the reasons the problems exist. At this point, lay out the policies!
I think both candidates missed the boat. Their problems all come back to positioning:
- They didn’t admit the problem, or the scale of the problems. There was not a full reckoning of the magnitude of the problem in the capital markets, but perhaps they don’t want to spook the public? I’m not sure how many Americans have internalized the impact of the collapse of the Wall Street giants over the past several weeks, and the tumbling stock market, but it seems to me that the nation must be stunned. What happened? What next? Americans know the problems are big, but if a leader doesn’t talk about it, he doesn’t connect with us.
- I didn’t hear a lot of confidence. People are scared, and they need to believe. Show belief in the country to overcome this challenge.
This isn’t just about government doing more. It’s about giving citezens their own marching orders; what can they do for the economy? Empower the nation, and you’ll reduce the reliance on government by definition.
- Diagnosis: I didn’t get the sense that either leader really understands why we have the problems we do! If he doesn’t undersand the problems folks, I guarantee he can’t solve them. And if he doesn’t share his diagnosis with Americans, Americans can’t get on board!
- Lay out the plan. In the product world, these are the features. In this debate, they talked about the features without describing the problems. We were left with a debate about features with no way to evaluate them.
Maybe what these guys really need is a product manager.