Companies are like machines. Each department plays their part, and together the thing somehow works. People within one department don’t always have to understand the entire operation – Sales people, for instance, are not required to understand how coding actually happens.
Certain organizational changes happen, and force the departments to understand a bit more about the machine. For instance – if Sales people are asked to begin selling a product that is delivered as an API, they’re probably going to have to learn something about coding (even if it’s just enough to explain the benefits of their solution).
Usually, Development can make adjustments to their process without needing the support or understanding of other departments. They change the process for controlling source code – but no one else has to deal with that, so it’s an isolated change within their department. Or, they go from manual testing to automation. Again, no one else needs to understand that change (as long as quality is positively impacted).
In most companies, changing to agile is not isolated. When the process for receiving requirements and estimating work changes, lots of areas in the company are impacted and must be brought on board. Basically, this change can cause stress in other parts of the company. If Product Management was having a hard time keeping up before, the change to agile will highlight that weakness, and sometimes stretch our process so far that it actually breaks.
If your development team is thinking of going agile, you have to stop and examine your requirements process. Are you ready to live in an agile world?
How are you preparing requirements? Do you constantly update the prioritized list of market requirements? Or, do you get to a point where you realize you have to deliver requirements, and quickly scramble your schedule so you have time to write stuff down before the team wants to review?
If I asked you to give me your top two requirements tomorrow morning, could you do it?
This is what Product Managers have to be prepared for! When your team goes agile, you have to constantly maintain the prioritized requirements, so you can give development more work at any time.
An agile team is going to ask for requirements more frequently, since they’re organizing their work into short sprints rather than a long waterfall release cycle. If you are constantly seeking market input, and organizing that input into a prioritized list of market requirements, you should be able to handle the transition fairly easily.
If your developers are transitioning to agile, take a look at your machine. Oil as needed, so that your team is enabled to succeed in an agile world.
7 comments:
I was talking to a fellow product manager earlier this week who's in a bit of a predicament. The development team is going agile but her management team is still pressing for a complete set of detailed requirements all up front, a la the traditional waterfall approach.
Your advice is good: "An agile team is going to ask for requirements more frequently, since they’re organizing their work into short sprints rather than a long waterfall release cycle. If you are constantly seeking market input, and organizing that input into a prioritized list of market requirements, you should be able to handle the transition fairly easily."
The change to agile impacts almost all organizations, so while I agree the product manager needs to adapt...they also need to help the management and executive management teams adapt (i.e. manage the people issues that can crater success if left unmanaged). To steal your analogy, they need to help oil the larger machine, so to speak.
Maybe you should post a followup targeted at helping product managers manage the rest of the organization through the change to agile.
Nice Post.
While changing to agile, the process for receiving requirements doesn't change much. It's just that customers get tied in more and more frequently into the day to day activities of product management. Agile PM must strive for small steps but in the right direction.
Here is my take after some research on this subject. I think that vision and roadmap are critical and necessary for any company product strategy, agile or not agile.
I see this not only possible with agile, but even easier. Basically,
we can do fine adjustments during each iteration to keep the course (e.g. something that does not make it for S1 will be for S2). In other words, you as a PM look at the horizon and proceed by small steers. In the waterfall you may realize too late that you need to abruptly steer and may not make it to get back to the right direction in time as per the release schedule
We can constantly add strategic steers at each iteration, keeping the course as per our strategic vision. And, if a change in direction is needed, so be it (but this has nothing to do with agile)
Hello Stacey,
I have a question. You say that
"If I asked you to give me your top two requirements tomorrow morning, could you do it?...[] so you can give development more work at any time."
Which I absolutely understand. However, I am missing a piece. How do you go from a market requirement to a set of actionable tasks for engineers? Is the backlog list one that is made of small enough requirements (that may lack a context)? Still, it is a market requirement, not a specification. It needs to be processed by design or development anyway to be actionable by the various dev team members
Thanks
-Donato
Hello, Donato, and thanks for your comments.
I completely agree that strategy is important. When I talk about roadmap or strategy, I include everything beyond the current project -- whatever we're working on right now has to be treated differently, since we're executing the development, marketing, and organizational preparation for it. My philosophy is that when Product Managers do their job, of finding, quantifying, and articulating market problems, we can set a course that doesn't change much for the current release. If we're consistently and thoroughly studying the market, we should be able to accurately predict our course for the short-term (current project). As we learn more about the market, our future roadmap map change -- but if we're changing requirements for what we're currently working on, it probably means we didn't do enough research before the project began. We can't know everything up front -- but we can achieve clarity on the top priority problems, through diligent research of our target market segment.
Your second comment focuses on the process needed to change market requirements into design, backlog, and sprints. In an earlier post, I noted:
"The designer should be in charge of the translation of market requirements into features. In an agile environment, that means that the designer must work with the Product Manager to understand the market requirements and their priority –and then lead the team to turning the problems into features and sprints that make sense. This must be done in close conjunction with the project manager, to ensure that the product that comes out the backend makes sense, and provides maximum impact in the target market segment."
Product Managers study the market. Designers receive market requirements, and work with target users and development to transform those requirements into a design that can be executed by engineering and tested by quality assurance.
Peace.
Stacey
Hello, I am currently a trainer in the IT department for a mental health agency. My background is in social services. I have a B.A. in psychology. I recently got the opportunity to move into a training position for my agency. I have been looking into certifications that will allow me to move up in the IT department or HR department within the agency. Could you possibly tell me the difference between an Agile Product Management certification vs a Product Management certification. The two appear to be the same.
Hello, I am currently a trainer in the IT department for a mental health agency. My background is in social services. I have a B.A. in psychology. I recently got the opportunity to move into a training position for my agency. I have been looking into certifications that will allow me to move up in the IT department or HR department within the agency. Could you possibly tell me the difference between an Agile Product Management certification vs a Product Management certification. The two appear to be the same.
Post a Comment