Archives for February 2016

This is the third in a series of posts discussing the various reasons why Agile transitions tend to run into roadblocks or fail completely. In the first post, we looked at some fundamental considerations that often wind up causing problems for teams wanting to make the change to Agile practices. In the second, we discussed the importance of retrospectives and evangelism in the success of such transitions. Here, in this third post, we’re going to examine some things that many teams lack which may significantly affect their ability to implement, embrace, and succeed with Agile processes: Knowledge, Commitment, and Progress.

When we say that Product Managers “lead through influence,” most people think of building rapport with the execution teams to ensure that you have the personal and professional leverage required to get them to do something without challenging things for their own reasons. But that’s really only a small piece of the overall leadership puzzle, and in many ways it’s also the easiest part — assuming that you know something about the market, that you know something about the users, and that you know something about the problems they’re facing, most of the “management” of delivery teams will come rather easily over time.

Where things get trickier, and where many of the career land mines lay for the unwary Product Manager, are those who sit above you — those in leadership positions within the organization. They often have (or claim to have) more product knowledge than you, more market knowledge than you, more customer knowledge than you, and more direct authoritative power than you. Knowing and understanding how to build your own relationships with your leadership team is an essential skill for the successful Product Manager, and here are a few tips that you can use to ensure that you’re growing your influence among the leadership team and not ceding your limited authority to that team.

Awhile back, I got into a rather heated discussion with someone who was a firm believer in “textbook Scrum” and insisted that because the Product Owner is part of the Scrum Team (according to the biblical Scrum Guide) that they simply must be involved in every retrospective with the team, no matter what. This discussion reminded me of the trap that many people fall into when they shift from traditional, structured, waterfall or stage/gate approaches into Agile development practices — they assume that there’s one process to rule them all, one way to do things, and anyone who does anything different is a heretic and deserves to be burned at the stake for even suggesting that sometimes it might be better for the team as a whole if the Product Owner isn’t invited to a particular retrospective.

Now, don’t get me wrong — I think that Product Owners, in general, should be very involved with every aspect of their teams’ work — from stand-ups to demos to retros, and everything else in between. I think that the standard practice should be that the Product Owner is invited to the retrospective as an observer and occasional active participant. But I do not believe that anything in the Scrum Guide or any other alleged “definition” of the right way to do things should be followed to the detriment of the teams’ success and improvement.

Dogmatic application of any standard process is inherently anti-Agile, for the following reasons…

There comes a time in every Product Manager’s life when they face adversity and challenges above and beyond the day-to-day administrivia that we struggle with every day. And it’s in these moments, at these times, that we find out what we really believe in, and what we’re really willing to do to stand our ground and push through the barriers before us. This is especially true in organizations going through a transition period — whether it’s growth, changes in ownership or management, or even shifting patterns from front-loaded development practices toward more agile approaches to product development. And it’s not only our values that come to the front when these things happen — it’s the organization’s values that stand out — often in stark contrast to the espoused positions that sound good when things are going smoothly.

What is it that drives these vast differences in behavior, and what can we do to bring the two closer together, especially in times of struggle?