Introduction: The agile community is all about moving from projects to products, where an organization sees all the work done as the creation or modification of its products. The organization funds the products for the long term and allows the team members and the product owners to decide how to spend that money.
A guide on how to get started moving from a project to a product:
Identifying the product: Identifying the product may sound easy, but actually, it is not. The major challenge here is deciding if "product" means an external product for the customer or an internal product for another team. To achieve all the biggest gains, one should master an understanding of the flow of products to the outside customer. However, many clients have thought that focusing on the external product may not be fruitful as the Agile journey that is required to create the product does not influence the larger organization and does not contribute any value to the organization at the local level.
How to identify the products? Keeping an updated Excel spreadsheet with all the product details is one of the very effective ways to manage the product. But if there are a lot of products of one client then maintaining a lot of these sheets with different suggestions and scopes can be a very scattered and difficult practice. Different team members may give different ideas and keeping a note of all the ideas, implementations, operations can be hectic to track to. Since all of the information are about the same product but of different value, a detailed updated idea about all of the information at any particular time is very important for the client.
However, It is very critical to get a list of products that all of the groups involved in the development of the product agree to. When all the team members see different answers, improving the product flow becomes difficult. Below mentioned are two strategies that effectively help when product development is in progress: Focusing only on the subset of the product, the organization is actively working and will be working in the next quarter. The client may have thousands of products, but not all of them are in working condition unless the client have thousands of teams. Keeping the focus only on the next quarter limits the scope and the productivity will be increased. More ideas or products can be added in the subsequent quarters when one learns how to cope with an advanced pressurized work culture that will eventually be more diverse. In order to create a product model, instead of focusing on thousands of individual products all the products can be abstracted into product lines and can be looked at once to minimize the burden and follow a standard approach. Identify the products for your sub-organization. Identifying the products that the real users like to view and the product creation should be started with minimal value. This can be adjusted later.
If a customer owns too many products, then the customer should limit the work and should focus on the next quarter. Or abstract upwards into product lines, and focus on a string instead of products to manage the complexity. To ensure all the audiences about the role of development, operations, management, portfolio, and finance of the defined product. Create persistent agile teams The companies are required to move away from transient or temporary agile teams to persistent agile teams, which will help with the growth of the current work. Many organizations have agile teams, but they are project-specific and are dissolved when the project ends. Every time a team modification occurs, it incurs a "J curve". Productivity dips before rising again. If the company wants to stand and maximize the product flow, the customer should retain the team and the team should remain stable for longer periods of time. Then DevOps transformation process starts. If the team owns the products until their end of life, that is a part of a DevOps mindset. Still the project can hire call centers to handle issues in the project, but if the team that has created the project still exists, then they can work on the various improvements.
Microsoft Azure setup is elegant yet simple, and it is the only tool that is built on this product mindset. Jira, VersionOne, Rational Team Concert, and Microsoft Teams are the tools where setting up a product hierarchy in a day without any need for tool experts is possible. Some customers who were using Excel spreadsheets for their products were now inclined towards Microsoft ADO to manage their work. The working of Microsoft ADO is more comfortable instead of Excel. The customers then understood that with this strategy of working, the proper reports were lost, and a lot of small teams who actually started on agile were lost. The customers needed to understand the importance of PATs so that they can refactor the organization. Moving away from TATs and towards PATs, as more identification of products, their longstanding agile teams to own them.
The team members should be stable in a project, any alteration in the team many times can set off a J curve. The team creating a product should be longstanding, i.e. should not leave the team in between for better product life. When the customer starts to identify the product and the PATs, the finance department team member should make sure that the finance team have should be aligned with all these PATs and agile systems. The finance team needs to figure out how people spend money and how much value they get from whatever they spend. On the other side, the portfolio team struggles to understand the epics, features, and the stories' costs. The portfolio team is the one that decides on which feature or epic to work, on and the priority of the work. The basic skill that the portfolio team should possess is understanding the delivery value.