Since Ken Schwaber's ground-breaking publication, Agile Software Development (2001), we've all been learning about Agile, Scrum and how it is helping cure many of the known ills of the Waterfall approach to product development in the software world. And product managers the world over have debated how this might affect their profession as a whole, and more specifically their own role. The simple view is that it does have an effect, and in some cases profound. But to make any generalization is dangerous - the actual mimpact on the product Manager hinges on many variables: the role and attitude of the product manager in question, the attitude towards their team within their current organization, the mechanics of the waterfall method hitherto employed, and the specific attributes of the new agile methodology being adopted by the organization.

The keen-eyed among you will notice how many of these variables involve attitudes, impressions and characteristics. So, are we saying the adoption of agile and how this might affect who you are as a product manager is a political, subjective issue? We can be forgiven for fearing the case. In Barbara Nelson's The Politics of Agile, the potential crisis is it seems Marketing and Development are in a race for control of the product, and the only way forward is product managers and developers need to work as a team in order to get anything done. Barbara is absolutely right. If we don't manage the potential political impact of major cultural and operational change (which is what Agile is, however it might be understated), we allow risk to gate-crash the party and possibly ruin it for everyone.

As product managers, we don't like old uncle risk barging in uninvited and upsetting the guests. We are control junkies; we like to manage smooth releases to expectant markets on prearranged dates with demonstrable features and measurable benefits. How do we manage the new array of risks and unknowns? I want to share with you a few lessons learned. Just maybe you recognize some of the situations. I'm talking about Scrum here, but I would wager there are similarities regardless of Agile approach.

Lesson One
Let's start with a scary thought about going Agile: Product managers are the last to know. Agile is not a product management, marketing or go-to-market centric initiative. It is a development one. It is about building better software (and building software better); it is about allowing focused teams to do great things in realistic timescales with limited bureaucracy. The charter is a healthy, sensible and appealing one. And yet the charter is ambivalent regarding who performs the product ownership role at the top level, or how the Agile process is kick-started by the market representative.

In reality, and the way it manifests itself in the organization (rather than the textbook), is Agile is a development initiative, affecting how development, as a function, works. Development is where the big costs are, and Agile aims for a better return on those costs so the focus and the agents-of-change are inevitably development representatives. Product management has to figure out what this means, act accordingly, and ensure business continues to see the results it expects. The concept of the Agile Product Manager is something the product manager must quickly define (Mike Cohn made a start on it as far back as 2005). Whatever your organization's motivation for moving to Agile, and even if you have been overlooked in the process of adoption, here is lesson one... Get in front of the Agile adoption curve and ensure an Agile Product Management definition is high on the agenda.

Lesson Two
And it is a stark warning. Agile doesn't actually solve any of your real problems! Contentious? Maybe. But consider it this way, pick the top 3 problems we face building software and, as a product manager, go-to-market guy, sales leader, you will NOT say: "The overall development process is a little antiquated and we have documentary evidence where we simply cannot change to meet market needs; we need smaller focused teams where we can change direction every month." You just won't. That's not how you see the world.

Now don't get me wrong here, Agile is a great idea. It is unquestionably a very sensible approach to resolving many of the anecdotally agreed difficulties with a heavyweight process. However, consider another view of the key problems facing the development processes.

• Lack of enough resources in Development to build everything we need, when we need it
• Lack of direct market input captured in a controlled and meaningful way
• Lack of particular skills to perform a specific function (either in terms of overall process, or a particular technical skill)

When you consider what Agile does, you realize that none of these will be solved through Agile. Not directly anyway. What Agile does though, is force you to take stock of what you do have. I strongly recommend a full strategic review of business plans and current roadmap, including resources and skills profiling.

Planning to go Agile can act as a catalyst for an appropriate operational review, and it's at this point we can highlight the objectives and success criteria. The business will look for better ROI and this will certainly shape any more development-specific operational changes. But also establish a list of success criteria that work at different operational levels. That way, all levels of stakeholder will buy-in. Without this, you either have the business regarding Agile as a housekeeping project (never a good place to be) or you have Development resenting that their first cultural shake-up in years has been hijacked by those who don't understand what they do! Here, Product Management needs to help steer the course the organization is following, if nothing else it means being able to translate between the technical and the business sides.

Lesson Three
Let's consider the word change. Change is a big word in the Agile manifesto.

Change is a good thing and something that organizations do based on market need and whenever necessary, to steal a march on their rivals. With Agile, change needs to take place in a meaningful way as part of the development process, and not (as Waterfall largely prescribes) as a bad thing to be avoided wherever possible. Simple so far? Good. Now, you, the Product Owner, go tell the developer who's new to Agile, "Actually no I don't want this, do this" every couple of weeks. See what he does. Or tell an entire development team that while they had been working on a cool Java user interface, you now need them to work on some maintenance project, in C++, on another platform. Don't expect a cheer! Better yet, assign yourself to that dead-end, backwater product you prayed the other product manager would do because you can't stand it, but now you're the only guy available.

Agile implementation requires a culture where change is acceptable, expected, and encouraged on a very personal level. Supporting this, we require a strong skills and personal development engine humming away in the background. And if there isn't, Agile is going to fall at the first hurdle, because as soon as you do the numbers and try to move people around, you will meet stern resistance, and there will be nothing to facilitate and promote resource mobility.

A skills profile portfolio is a vitally important piece of planning collateral. I suggest to anyone implementing Agile who doesn't have an enlightened training and skills policy and an accurate company skills profile (including non-technical roles), they are merely aspiring towards Agile, not seriously planning for it. Product management has to be involved, but so does HR. And, they have to step up to ensure things are in place, not least with the training budget. So, our third lesson is Agile requires training; let's get that very clear.

Lesson Four
Implementing Agile is, by definition, an Agile process. One of the best things I ever saw to aid Agile implementation was the establishment of a company-wide Adoption Team, which ran according to Agile process. It lived the dream from the start, acted as the font of wisdom, built organic operational skills, credibility and confidence, and helped resolve significant impediments raised by any of the early-adopter scrum teams. Lesson four: using Agile to implement Agile is a tremendous advantage.

Lesson Five
Define all new roles and live them! No marks are awarded for having some of your roles sorted out, or even some of your scrums up and running. As soon as there is any kind of scrum interdependency (usually very quickly), you need everyone working the same way. Particularly vital roles in the implementation are those of Product Owner and Scrum Master, and I'm tempted to devote an entire article to this subject alone. Suffice to say these roles need to have the hierarchy of product ownership fully nailed down, right up to and including the Business Owner (which is where Product Management assumes the responsibility). Get this wrong and you will have all kinds of fun getting anything started from then on. Scrum Master is simple. However many good scrum masters you think you have today, you don't have enough. A senior technical guy or a loud one doesn't make a good Scrum Master. A good organizer, facilitator, lateral thinker, communicator, does. These are attributes not traditionally associated with rank-and-file development staff. Add this to the skills profiling effort to make yourself a skills gap from day 1.

Lesson Six
Agree what it isn't. What is expected of people needs to be agreed, as above. And things then change. I've seen entire shelves of preparatory material rendered moribund through Agile implementation, saving a few poor souls countless hours. Much of this might focus on the requirements-gathering process, which could be due for an overhaul to allow the greater dynamism that Agile would promote. Certainly Agile backlog management systems exist, and it would make logical organizational sense to have the front-end requirements element locked in to the same system. Consider, however, the product itself might well receive some suggested change because of the Agile ethos of building just-in-time documentation and limiting bureaucracy. Other functions to keep in step then at the early planning stage are those responsible for documentation, for customer care and for after sales service, because they need to buy-in to any changes in how your products will be documented. So lesson six is to get buy-in on any changes (especially reduction) in any of the outputs  of the development process. It could be vital.

Summary
A lot of what I've said here is derived from a common-sense view of embarking on any significant process and cultural change. If you are ready to change, and you communicate and plan effectively, there's every chance the change will be for the better. If any of these suggestions resonated or made you think "we haven't considered that yet", it might help you fine tune your Agile implementation. Don't expect results immediately. Do expect to have to refine even your best first plan and do expect you will need to refine your cultural values to support what can have profoundly positive benefits.

Derek Britton has worked in a variety of Development, Project and Product Management positions in the IT industry over the last two decades. Currently, he is a Senior Director, Product Management at Micro Focus, responsible for the portfolio management product lines.