Since the Clever PM is recovering from a nasty bug, he’s going to rely on Quora for a little Clever content again, this time focusing on the question “How do you get developers to commit to finishing a sprint on time?” I chose this one because it plays into one of the common misconceptions about Scrum and Agile approaches — that it’s the responsibility of the Product Manager to ensure commitment from the Development teams; this is certainly how it works in the Waterfall world — the Product Manager negotiates a “contract” with the Development team for what they’ll do, how it will be done, and how long it can take. But in the Agile world, particularly in Scrum, it’s the team that makes the commitment to deliver, based on what they believe they can achieve in their next iteration. It’s the Product Owner/Manager’s job to ensure that the team has a well-groomed, prioritized backlog to choose that work from. [Read more…]
One of the biggest challenges facing nearly every Product Manager is the lack of a clearly-defined role in the organization. Even in companies that have “rigorous” organizational structures, the Product Manager often becomes everything to everyone – the hub around which all the other business processes operate. And for the most part, this isn’t necessarily a bad thing. Unfortunately for all of us, the simple fact is that not every person has talent for every single piece of the puzzle. The “marketing genius” might not know the difference between XML, HTML, PERL, and PHP; the person with the best relationship with the Support organization might feel challenged when asked to present to the Sales organization or sit on a panel at an industry conference.
It is for this reason that many companies differentiate between “Product” Management and “Program” (or “Project”) Management. And, for the most part, this makes sense – the Product Manager becomes the voice of the customer, and of the market, while the Program Manager becomes the liaison between the Product Manager and the Development organization, sometimes even taking up a role within the Support or Training organizations as well. For smaller organizations, or very niche markets, this works quite well, particularly if the Product Manager originates from the market that the product is serving. Their experience and prestige in the community provide key insights and instincts that can guide the product in its development, and ensure that customer requirements are met.
However, a challenge presents itself when this type of Product Manager needs to confirm their instincts and insights with the market as a whole, particularly in situations where the organization has decided to implement an Agile or Agile-like product development process. One of the core tenets of Agile and similar methodologies is regular review by the stakeholder, here most likely the Product Manager. But, if that Product Manager is out in the market several times a month, coordinating these reviews can become very difficult. And the product, as a whole, suffers.
Enter the concept of a Market Planner. I first encountered this concept when I was assigned to design a brand new product, from the ground up, for a niche market that sat on the periphery of my prior industry experience — it was, in fact, at the intersection of two very different markets. The Market Planner on this product came from the other side of this niche – from the other industry in this intersection. As we talked about the concept, it became increasingly clear that she was in a great position to be the voice of the market to the product, and of the product to the market, while I was the obvious choice to work on the ground, collating requirements and combining them into a narrative that we could sell to the business as well as the Development teams.
For the next year or more, we worked side-by-side — she attended conferences and engaged in panel discussions with industry leaders, feeding me detailed reports about what was working for them, what wasn’t, what their workflows looked like, and whatever wild concepts they would come up with over dinner and drinks. I would take these tidbits of information, collect them, and put them into documents that were used to explain the product to our internal stakeholders. Often, I had to tell her “no”, or put some of her requests on the backburner, for version 2.0 of the product. And she often asked for my own input on ideas, concepts, and workflows. It was a match made in heaven, and we launched a very successful product, the first of its kind in the market space.
This was a very different experience than any other I had with that particular company – the active participation of a Market Planner made a world of difference in the product. She knew where the product should go, what the specific needs of the target customers were, and most importantly provided both a vision and a plan that I could execute against. The separation of the long-term from the short-term from the execution truly made all of the difference.
What I learned from this is that every person in the broad Product Management world has their own specific skills, talents, and interests. And the most effective structure for a larger business, particularly if they’re attempting to expand into new and uncharted areas, is to engage the market in a structured, coordinated approach – have a Market Planner to be the overall voice of the market and of the product, let them set and communicate the vision; have a Product Manager who can coordinate and collate all the work and insight uncovered by the Market Planner, and let them turn the vision and plan into actionable requirements and documentation that can be absorbed by the rest of the business; and last but not least, have a Program Manager who can wrangle the exact deliverables, the schedule, the nitty-gritty resource allocation problems that plague even the best-staffed of organizations.
With a strong “Power Trio” of these three roles, there’s almost nothing an organization cannot accomplish.
I started this out as a single post, but it’s become far too unwieldy for a single day. Thus, I’m breaking this up into two segments — one focusing on missing the point, the other on finer mistakes that sink potentially “good” teams moving into Agile processes. It’s still one of my longest posts here, but I hope you find it worth the read.
“Agile” and “Scrum” have seemed to take a beating over the past few months, with a lot of criticisms and complaints online and off with regard to how it’s not the “silver bullet” everyone expects it to be and how it actually fosters a lot of dysfunction and bad behaviors in developers, Product Managers, and management. The problem with a lot of these criticisms, at least the ones that I’ve read, is that they take one or two bad experiences with agile methodologies and apply them as a blanket criticism of all agile methodologies — and almost universally one can look to the details of these complaints and see that it’s far more likely that the bad experiences are caused not by a bad philosophy or a bad methodology, but by bad implementation of those principles and processes.
I’ve worked with several companies to effective transform from backwater processes to effective, efficient, and successful product delivery teams through the use of agile philosophies and a variety of agile methodologies. The problem is, nearly every team has some level of dysfunction already (and likely always will), and if you go in blind to those dysfunctions, or with a belief that all you need to do is “be Agile”, then you’re destined to fail — but I would posit that it doesn’t matter what process you choose, if you ignore your dysfunctions they will always come back an bite you in the end.
To that end, I wanted to take some time today to discuss some dysfunctions that I’ve seen in teams claiming to transform into Agile/Scrum teams, all of which are not only contrary to the principles on which the methodology is founded, but each of which can sink any attempt to be more agile into an unending quagmire of crap.
Almost by definition, leadership involves influencing people — whether that is through direct action and orders, or through indirect influence, the end result is that a leader convinces people to take action toward a particular goal or through particular means.
Generally speaking, this is a good thing — a good, strong leader can create a vision of the potential future that others want to work toward bringing about. However, there is also a hidden side of leadership that’s often overlooked, the “dark side” of leadership that can actually cause more randomization and chaos than it can structure and vision.
Throughout my career as a product manager, I’ve encountered leaders who didn’t realize the actual impacts of their actions on the teams that they were leading. These folks didn’t intend to cause chaos and randomization, but they were not cognizant of the subtle effects that their roles had on what otherwise would have been innocuous suggestions or comments.
Let’s look at how some common leadership situations can result in unintended chaos…
One of the sometimes-confusing aspects of the Scrum approach to Agile development is how a Product Manager fits into the system. It’s important to understand that Scrum was designed originally as set of development practices, and as such from the textbook perspective views everything through that lens. The crux of the confusion comes primarily because Scrum has a role called a “Product Owner” which is intended to be the teams “contact point” with the outside world. All too often it is just assumed that this is a role that melds entirely with that of a Product Manager, without critically assessing what that role really is, how it needs to be managed, and what other duties a Product Manager needs to engage in that aren’t comprehended by Scrum as a development practice.