How Product Management's role is shifting with Laureen Knudsen at HP

WEBINAR TRANSCRIPT:

Laureen: Thank you. Good morning, afternoon and good evening, depending on where you are.

I am going to be speaking today on product management's role in Agile.
Once I get started, I'll go through the differences and high level differences between waterfall and Agile; I'll do an Agile overview. I'll speak about product management's role specifically within an Agile environment. I'll talk about Agile collaboration including product planning, design process, stories and acceptance tests, and how you track your ideas into reality, and some metrics you can get along the way.

Then we'll do wrap up and have questions.

What is the difference between Waterfall and Agile. In an Agile environment, people talk about how you can dive straight into code - and you can - once you have your backlog set. Your backlog is any request that has come into the system regarding your software products.

Product management is responsible for that backlog and they provide a hierarchy to all of the requests submitted for enhancements to the code or how a new feature should work.

That's pretty standard to what happens in a lot of companies today with product management. However, instead of just the nice-to-have and the want-to-have and have-to-have, we actually assign a hierarchy so that you have first - something that has to be done first that the market wants.

What also goes with that, is the development team assign a risk for how risky it is for them to do and the priority and risk together, decide what will go first into the code. They only map out the first few features that will be in their first iteration. They don't do the analysis and design and detail design on every feature that's planned for the release.

We do that because we're finding that certain requirements end up dropping out of the release, so you've wasted that time doing that detailed analysis of how those requirements should work, and they may never get implemented.

So instead of using developers' time and product managers' time designing those, we design the things that will go into the first iteration. They can truly dive straight into code, as opposed to the first phases of a standard Waterfall process where they spend weeks on analysis and come up with detailed design specs.

The meetings also differ, in that Agile also provides quick daily standup meetings. You'll hear them called daily scrum, daily stand-ups, depending on the Agile methodology you choose. Waterfall's tends to have longer weekly or bi-weekly status meetings. From my experience, they tend to go weekly during critical times of the release, and they go out bi-weekly at other times.

Team behaviors: Waterfall uses manager directed where work is assigned to people, while Agile encourage what they call self organization; the team is responsible for their own products and they are responsible for making sure it's complete and for signing up for tasks to do, not getting tasks assigned to them. So people take on their own work.

That's a huge change in the environment you work in.

The deliverables also differ, where Agile delivers working code and Waterfall tends to deliver the documentation early - the specs and the PRDs and MRDs - product requirements documents, release charters, market requirements documents - early with working code at the very end, so you don't really know what you're not going to get until the end of the release.

Why Waterfall can have issues: This is a quick slide that's fun to see. Usually from my experience, the MRD was created by the product marketing department, and it was a large, sort of monolith document that got thrown over a wall to product requirements and product management - product management created a large PRD that described what they wanted in the release, and the benefits of each feature.

That got thrown over a wall into a developer zone where no one really talked to the developers about what was exactly needed or wanted. QA often got pushed to the very end, and was behind the 8 ball to get their testing done and never got to have input onto the quality of the requirements. Then they threw the product out to the customer.

What this does, is it really shields the developers from ever having access to the customers on either end. It shields QA from that as well so that the developers never truly understand what the customers are actually looking for. That can create some issues.

What Agile tends to do in an overview, is they focus on what they call the Agile Manifesto. This covers all types of Agile. They focus on individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiations, so no signing off on specs, and responding to changes in both the market and customer requirements, opposed to just following a signed off plan.

They don't say there are no processes - I am a process person by trade, so we definitely have process over things and certain things for how things should work - but it frees up the team to allow them to determine how they want to work.

The teams are also expanded to not just be development, but to include QA, documentation. Product management is a key, key role in an Agile team - and I'll get into why a little bit later. Some people actually think that product managers' role is reduced in an Agile environment when actually the exact opposite is true. It is broadened in scope quite a bit.

While they see there is value in all these things on the right, the things you want to focus on are talking over writing - responding to changes in the market vs sticking to a plan that you may have designed a year ago that the market has left behind.

People are more important than any process. However - good people with good process can out-perform people with no process.

What else does the Agile philosophy provide us. Traditional processes have a lot of risk at the end. I think we've all been involved in software development projects where everybody is living at the company for the last six weeks of the development cycle and QA is there trying to test as best they can. We end up with a quality mess and not enough time to get everything done. People aren't finding out about requirements that got dropped out of a project until the very end - a month before release where then you're trying to re-set customers' expectations of what will be included.

What we try to do instead in an Agile environment, is do a lot more checks along the way within the construction cycle. Every two weeks to a month, depending on how long a spring or iteration is, the product manager is responsible for helping plan what will be in that next iteration as well as setting acceptance criteria, and seeing that their acceptance criteria was met.

So people tend to work that overtime and do that push for that month-long period to meet that monthly date, vs having a 9 month construction cycle with no real insight.

I'll get into a little more detail on those pieces coming up.

What should be goals of adopting Agile. These were the goals that we thought. The primary goals are to increase consistency and relevancy of the requirements by using a customer advocate.

Customer advocate is by definition the product manager. If you have a small set of customers, you may be able to have a true customer as part of the team but I have found that is really difficult to do.

What we do at a company like HP - I worked before at Peregrine - we relied on our product managers to understand our customer base and all of the industries we were in - our product managers were those customer advocates and worked on the design of the product with the developers.

Adopting Agile allowed us to verify our process plans and allow for requirements changes along our plan because you only plan an iteration at a time. Requirements can change every iteration. We have long development cycles of like 18 months. During that 18 months a new requirement comes up in the market which always happens. You can plan for that within the release and immediately bump other things out that aren't important anymore in the market, and have new requirements pulled in so that by the time you release your product, you truly are market driven and market ready.

We measure our ability to deliver market value - and I'll talk about that a little later - and we have more insight into projects because we are doing these monthly checks and inviting people to come see the code that's done so far - we have deliverable code or working code that's been integrated every month so we have more insight into the projects and where they truly are.

If things are getting behind, you can tell that about one to two months into the construction cycle. If you can't get a contingency in place to get that project back on track, you can already start setting expectations in the market that your project is not going to have all the features you had initially planned.

Other goals; we improved communication across teams. Agile just requires that and I'll go through that in a collaboration slide. We distributed risk, like I had spoken about before, across the entire release cycle. We have quality early in the cycle. With each iteration you also test the software that's done, so your feedback loop is shortened quite a bit and you make sure that the testing is done along with the coding.

We captured all the knowledge of the developers. Believe it or not, at the end of an Agile project, we had more correct documentation on what was actually coded through our stories than we'd had through our specs.

So what is the role of product managers in Agile. Really, they must be a part of that team; of the development team, and be available throughout the construction cycle of the project. They are the customer advocate and customer voice. Because of that, you need to really be available to the team, be there to answer the questions when they have design questions. You provide prioritization of all requirements. Iteration to iteration, you can change that requirement list and the prioritization.

The developers still do the risk and the estimation portion of the prioritization, and that information together comes up with your final list. PM is vital in coming up with the requirements for the release, and making sure that they are always the top requirements being worked on.

PM provides acceptance criteria. Acceptance criteria is how a developer knows they are done with that story.

We had issues with done; what does done mean with different development teams. This really provides PM with a way from the customer's perspective, so that the story is written to say 'an administrator would want to log in and do - be able to control, say, security in the user role within a feature'. That is your user story along with your acceptance criteria, for how would you know that was done; that you could log in as an administrator, that it wouldn't work for other types of roles, that the administrator could set the role for each user - you have specific acceptance criteria that you set for each story.

Before each iteration, you are responsible for updating the priority list in the backlog which is the requirements backlog. All tasks are flushed out - as the tasks are flushed out, you're available for questions and provide answers from a customer perspective for how something should be done.

It also provides a culture change so we no longer focus on business roles of managers and titles. We really focus on a team and the responsibilities to and of the team. The mindset is that the team commits to the work and they complete it - so they take ownership of what they say they can get done as well as getting that done in the time they said.

Estimations are a tricky thing. If people haven't estimated and truly tracked their estimates to actuals before, they might not be very good at this, so at first you understand there will be a velocity addition to the - I don't want to get heavily into velocity - but an addition to the work so you know if somebody's already saying it takes 5 hours and it takes 7, you can apply a multiplier to their time to know that you always need to add a little more.

The leaders, the executives, as well as the product managers and people running those projects in the company, must allow the teams to progress without interruption so they can honor their estimates and the work they said they will complete.

What this does, is it allows the development teams to totally focus on what they have said they will work on within an iteration, and that shoulder tapping of either executives or sales - or even some PMs - to say oh no, can you add this in too - we need this to make a sale this month - that stops.

If we need to do something like that, you break into the iteration, start re-planning the iteration from scratch and re-prioritize the whole backlog based on the new requirements that are input.

How does the collaboration really work. This is in a best scenario where the customers will talk to analysts as well as product marketing and PM.

Product marketing takes the market drivers and starts the pipelines for the projects. Product management also hears this information, talks to all of our customers, and they create storyboards within the pipeline based on both the market drivers and the customer input.

These storyboards get laid out and broken down into stories that can fit within an iteration. They work heavily with development to come up with what those stories are and what the acceptance criteria is. How does the developer know they are done.

Quality is involved with this as well, and QA tasks can come up in how they test so at the same time the testers understand what's going into the release, have heard how the customer wants something to work, and they can verify that not only is it bug free but it actually works as the customer would want it to.

If you have a small product or a product that's easily releasable and your market wants released quickly, you can do a final release to the customers or you can repeat this iteration process in-house, combine those all into an integrated release and send that to the customers.

That's the method we used at HP; we combine a bunch of iterations together. Ours can go up to 18 months - 12 to 18 months, usually, for just our construction cycles - we combine that together but we do integrate about 6 weeks to 2 months to make sure the product is working, that all the new features are working together with the existing features; our CM builds it. It's not allowed to be on a developer's box. We have customers that can start looking at things from an alpha perspective at that point.

What happens during product planning. The customer commitment - we know new customer commitments come in and that's just a constant. You are constantly having people ask for things; you're constantly having sales come to you and say, oh, to make this sale we have to do this and this - what Agile does, is it just plans for those new requirements to be coming in on a consistent basis.

The release roadmaps need to align to your market drivers so you can ensure you are planning for your industry and your market. And they also need to align to the product features that actually show up in the product.

Agile helps you align those together really well with having the PM be the customer advocate.

We manage tradeoffs and negotiations through what we use as a balance release model, where it has high level release features, rough budget estimates of time and money, so we can tell if you want to put - you have a 10 million dollar budget for this release and you want to put two million to a certain feature, you can track your time and budget estimates to that.

We do resource balancing and allocation to ensure that we're not over allocating one certain resource or a team of resources too much within a release at a certain time, and we classify our investments by business goals within this negotiation process, to create our initial product planning and our project planning.

All of this together provides our business framework for a release.

In our design process, our product management acts as our customer advocate. We're in so many industries and areas, that we really require and we rely on our product managers to heavily understand our customers, and to be able to advocate for them how a new feature functionality should work.

They are also called our product owner and they are ultimately responsible for the overall product and release.

Acquiring the customer advocate type of knowledge we realize needs to be incorporated into the process. For the initial features that are the highest priority and highest risk, we get that information prior to any construction starting. With the features that are happening in future iterations, we can have this ongoing along with construction.

So in that way, we've sort of shortened our release cycles where the all of the information that's being required to design the product doesn't have to be done up front for every feature prior to any coding starting.

But we do make sure that each feature is designed in advance of the construction for that individual feature starting, and we have the ability to break down high-level goals into something that can be worked on.

I know a lot of companies do things like, say we have an initiative we need to improve quality across our portfolio - so quality has to be a focus of every release. How do you know you're really focusing on quality. You can assign goals or initiatives into your features which can then be broken down into tasks and I'll show you how that works.

What are stories and acceptance tests. Story based development - a story is really a promise for a conversation. It's not meant to be the full detailed design; it's meant to give from a customer perspective, how something should work.

It doesn't include all the techy information and how a developer will work on it; it is how does the customer expect this to look, and how does the customer expect this to act.

There is an analogy for this that goes along with -they say they cut through a whole piece of cake - w here you cut through all the layers - so you can have a story written from a customer perspective at the top and through that, the development team, while sitting in a design meeting, can say oh, but on the server I need to do this, and that's going to change how in interact with the application server and with the client and all that information can get built into tasks underneath the story but the story is always from what the customer wants to have happen.

Story should be small enough to be implemented within one iteration. If you find out they're not, you break them down into two stories. Effort and risk is always provided by the developer and not by product manager. They are the ones that have to do the work.

The risk in this risk - it's not a corporate risk - it's the risk from the development team of how risky is this to integrate with what the existing code - how risky is this from a new technology standpoint - all of that type of information.

Acceptance tests are critical to every story. We encourage test driven development. Test driven development means that when you write an acceptance test, it should be in the form that a tester, a QA person can immediately go start writing their test plans off of that.

By the time the code is complete, the test plan at a minimum is done. If you are using automation testing, the developer and the QA person together can write the automated test prior to the coding being complete so that by the time the code is complete, the developer can run it through the automation to prove that the acceptance criteria is met.

Then the QA can run it again after it's been integrated through everything, to make sure acceptance criteria is still met.

Then at the end of that, you can pull those automated tests into a test harness and that can continually be run after each future iteration so you can make sure nothing gets broken in the future integration.

This also gives you rapid feedback so you know immediately if something isn't hitting your acceptance criteria and as a PM, if you're in all the acceptance meetings as well at the end of each iteration -- you have an acceptance meeting - the PM is in that to make sure what is happening is truly what they said needed to be done so you provide the acceptance.

Because of that, you get the feedback to say no, that really wasn't what I was talking about; I really needed it to do this or the customers are really going to want it to work this way; you have the data flow going a little odd ... that type of feedback can be done within a couple of weeks to a month period when you have your acceptance meeting, instead of waiting til the end of the construction cycle, and then you're trying to get something totally re-worked.

Really, Agile talks a lot about co-location where the entire team needs to be in one place. That's a really great thing if you can make it happen. We found - in a company even the size that Peregrine was - and now with HP - this just isn't feasible.

The 3x5 cards that all the Agile groups talk about just don't cut it. We use a tool to track our progress, to enter our backlog and track our information, break down our features into stories - there are some great tools out there now that help you do that.

Ideas to reality. When you have your market drivers, that should roll into your release features. You design your release features from a PM perspective based on what the marketers gave you. Through that, we usually create a roadmap or your initial release plan.

Those get broken down into storyboards for how does the data flow through the system and how does a user want to use the system.

The storyboards are broken down into individual stories for how much work can get done in an iteration. Then those get broken down into daily tasks that can get done, and to the acceptance tests.

If you flow something like this through, and you can create a hierarchy, you can also roll that information back. In your tasks, if you have estimated and actually information in your task for timing, you can track how much time you're spending on each story, on each storyboard, on each feature, and on each market driver.

The initiatives and goals I talked about earlier, like a quality initiative - if you have features that are mapped out to your quality initiative, you can roll those into storyboard stories and tasks and then track back to how much - you know, are you actually spending 15% of your time on quality initiatives or are you doing more than that or less than that.

You can use this to track your metrics back to your initiatives, your goals, your market drivers.

It allows you to see how you are doing on your investment budgeting, where if you invested for certain market drivers or are trying to hit a new market - it allows you to track your task completion for how far along are you truly against a certain feature, against a certain storyboard - and it allows you to do your accountability back up to your market drivers.

Again, if you are using the tools to track all of this, it's a lot easier to get these types of metrics rather than the 3x5 cards.

I'm going to start wrapping up.

There are real business drivers behind why you would want to adopt Agile. It helps companies increase their relevancy to the market because you are tracking your market requirements continuously through your construction cycle.

It enables company-wide product goals across your entire portfolio. like I talked about the quality goals. It allows you to track those relatively easily if you are tracking all of your levels and linking your task back to your features; you can make that happen quite easily.

It provides a framework for tracking your investment and risks as well. One thing I hear about Agile, is that it doesn't give the executives the information they need to really run the business - but if you do things like this, where you are actually tracking and linking things together - you can give them a lot more information than you can give on most Waterfall projects.

You need to consider your entire product life cycle when you are working in Agile. If you decide to do Agile and you want to distribute your product quite quickly, you can distribute monthly or every six weeks, once you wrap it up.

A lot of people that design websites and have web systems release new software monthly or bi-monthly. A lot of people that host products for their customers will release every two months or so. You need to balance how fast you release with what your customers want.

Our customers that we've had in the IT industry on their big enterprise projects, their big enterprise software projects, don't want us to release more than every year to two years. So we release internally and integrate internally and then release to the market.

You consider your market drivers, your product design and your design changes completely if you go to an Agile environment. Your quality requirements - you can do quality requirements against your customer requirements, and track those through.

Your quality is done up front. The testing is done a lot earlier in the construction cycle. Your team dynamics change a lot in an Agile environment, and you have to get people who want to take responsibility for their own work and not get assigned tasks - but actually want to help define those tasks - and then sign themselves up for them.

The launch and release can be different based on how much your customers want, and your post release market impact can get tracked, because you can see that you spent a certain amount of time - what was your customer impact - what requests do they have on that new release - how fast do those come in - did you miss your mark in your design as you went through - and track the new requirements coming through for your future releases.

Adopting Agile is really a continuing learning process. I've seen some teams try to go from a Waterfall environment to a full Agile environment over night and it really doesn't work quite well.

My recommendation is that you read through Agile, attend some Agile classes, and then pick the things - the portions of the Agile method you choose - that will best align with your teams today.

A lot of people start with daily stand-ups. That gives everybody on the team, from PM and user experience and quality, documentation and developers - a 15 minute time period to quickly state what they've done in the past day and what they are going to do in the next 24 hours.

So everybody on the team continuously knows what's going on with the project. You can start designing things a little differently, but don't try and go from Waterfall to Agile in one quick step.