Coping with change on Scrum projects (part I)

Introduction

Most folks don't like change. I know I don't. But one things certain, adopting an Agile approach to software development requires much change in an organization. Whether it's corporate culture, roles or process, as an organization switching to Agile you're going to have to learn cope with change. This series deals with how various functions in the Agile organization are expected to change in order that teams new to Agile can learn what to expect and better adapt to this new and invigorating environment. This week covers the changes one can expect for the Customer and Product Management function in the Agile organization.

Customers/Stakeholders

With traditional waterfall projects customers are typically at arms length and only engaged at the beginning and end of a project. Nine times out of ten, we (development teams) force customers to "spit it all out" up-front, and we make it quite clear to the customer that any change after the start of a project requires change control processes and penalties. Then after we're done coding, which can be many months after the start, we hand the code over only to find out that "we got it wrong". Needless to say this approach is a recipe for disaster and so on Agile projects, customers need to be far more engaged throughout the development process. In fact, on Agile projects we actually expect change and welcome customer feedback. And so customers are expected to participate and provide input at all "inspect and adapt" points. This minimizes risk and give customers and stakeholders options.

Product Management

If you're a Product Manager on a team shifting to Agile, you can expect change too. For starters your title changes from Product Manager to Product owner. But that's not all. Product Managers in traditional environments are mostly front and back-end loaded as well. Besides their specific marketing duties, Product Managers are typically responsible for the Product Requirements document. I have already spoken at length about the new Product Owner role in a previous blog. Suffice to say, in many situations, the Product Owner is in actual fact the proxy for the customer. Either way, the Product Owner is an active participant. The buck stops squarely with the Product Owner as they become ultimately responsible for the product direction and priorities for a project. Contrary to popular belief, the Product Owner also has deliverables and as a result is required to avail him/herself to the team at all times. Whether or not the Product owner is at every single Daily Stand-up is debatable but the more engaged the Product owner is throughout, the more chance there is of success. The Product Owner also becomes partly responsible for defining the acceptance test criteria and in this regard they're somewhat responsible for the quality of the product - especially since these acceptance test criteria allow the development team to build quality in right from the start.

In summary then, as a Customer and/or Product Owner, expect to be more involved day to day. And be prepared to get your hands dirty.

Written by Jack Milunksy - COO at Brightspark, certified ScrumMaster and Co-founder of Agilebuddy (Agile project management software that lets you easily Create, Estimate, Plan and Track your software development projects). For great Agile tips follow Jack at: www.twitter.com/agilebuddy. To get more info on Agilebuddy please visit: www.agilebuddy.com

Comments

[Mohan]

It is a nice article and well written. I am new to agile methodology and currently working on a agile based project. It provides the disciplined approach to develop the software by meeting the business exception and keeping the development team engaged. The agile methodology allows the business to change their requirements during the development life cycle. It may cause the team to miss the project dead line. How does the agile methodology address this issue?

[Robert Lindsey]

Jack gives a good description of the old way of doing things. I became physically exhausted just reading it.

Glad to see he's moving on to the agile way of doing things though.

[~Phoenix~]

I think this article would be best paired with what a Product Manager/Owner is NOT. I still run into issues with the PO heavy handing the team members.