Agile strategy: How to go from projects to products in 3 steps
Get up to speed fast on the techniques behind successful enterprise application development, QA testing and software delivery from leading practitioners.
App modernization 101: Understand your options—and how to get started
6 rules for high-quality page object patterns
Why you should build accessibility in from the start
9 open-source service meshes compared
15 great resources for modernizing your applications
Software development and IT operations teams are coming together for faster business results. Learn from enterprise dev and ops teams at the forefront of DevOps.
Shift your DevOps into high gear: Key models to consider
10 companies killing it at DevOps in 2020
Continuous delivery: What it is, and why it matters
Are poor team interactions killing your DevOps transformation?
SAP S/4HANA app migration: Lessons from the trenches
Trends and best practices for provisioning, deploying, monitoring and managing enterprise IT systems. Understand challenges and best practices for ITOM, hybrid IT, ITSM and more.
15 AIOps resources for IT pros
Machine learning and data warehousing: What it is, why it matters
Get started with ESM: 5 breakout projects to consider
AIOps essentials: What it is, why it matters
16 great digital transformation resources for IT pros
All things security for software engineering, DevOps, and IT Ops teams. Stay out front on application security, information security and data security.
Zero-trust security: How to get started
How to build in app sec with strategic automation
Secret Service dodges location-data warrants … there’s an app for that
The state of cloud security and privacy: 5 key trends to watch
Zero trust security: What it is, why it matters
Technical conference highlights, analyst reports, ebooks, guides, white papers, and case studies with in-depth and compelling content.
Chaos Conf 2020
TechBeacon Guide: Transform Your IT with AIOps
INSPIRE 20 Podcast Series: 20 Leaders Driving Diversity in Tech
TechBeacon Buyer’s Guide to ESM Products
TechBeacon Guide: Cloud Security & Data Privacy
A big trend in the agile community is to move from projects to products, where an organization sees all work as the creation or modification of its products. The organization funds products for the long term and allows persistent teams and their product owners to determine how to spend that money.
Here’s a three-step guide to get started.
Identifying your products sounds easy, but it is not. All my clients have struggled with this. One challenge is deciding if “products” means external products for the customer, or internal products for another team.
To achieve the biggest gains, you should master understanding of the flow of products to the outside customer. However, many clients are so removed from the externally facing product that focusing on this seems unhelpful. Some groups on their own agile journeys do not influence the larger organization and may wonder if the move from projects to products has any value at the local level.
Imagine that the scope of transformation is only Step 3 of this value stream. Any optimizations you make will improve only Step 3. But if Step 3 is not the bottleneck in the flow of value, you are unlikely to make a significant difference overall.
If the bottleneck is in a previous step, Step 3 may already be starving for work. If the bottleneck is after Step 3, optimizing Step 3 will only further overwhelm those steps. Improving Step 3 would make both worse!
This can be confusing to the organization funding the agile transformation of Step 3: Will the investment yield tangible results? Is it worth optimizing only Step 3? Here are a few thoughts:
It’s best to address all the steps. But if your scope is to improve only one step in the value chain, you must improve that step and also take a systems view. Only then can you expand the transformation to the other steps that might need the help more.
You need both types of products: those for the actual users, and the products of Step 3 and how those products support the true products.
Imagine you are improving the HR department of an organization. One internal product of HR might be talent acquisition. Is talent acquisition the biggest bottleneck to overall product flow? Maybe not. But if the users of HR feel it is one bottleneck, it is still worth improving.
One client already had an Excel spreadsheet with their products. This was a wonderful head start, until they tried to use the list. The products were inconsistent. Development used one set of ideas for products. The managers had put together a different list. Operations had a third list of products. And finance had a fourth answer. All were different yet represented the same products.
It is critical to get a list of products that all of these groups agree to. When everyone sees a different answer, improving product flow becomes difficult.
Some may feel they have only one product—oil, for instance. This rarely holds true, but it is a self-correcting problem. If there is more than one product, this will emerge as you move forward. So don’t fight it; improve when you learn more.
At the other extreme, some clients have thousands of products and struggle with how to model them. Here are two strategies:
Companies need to move away from transient or temporary agile teams (TATs) to persistent agile teams (PATs) that will outlive their current work. Many organizations have agile teams, but they are project-specific and are dissolved when the project ends.
Every time you modify or form a team, it incurs a “J curve”: Productivity dips before eventually rising again. So it stands to reason that if a company wants to maximize product flow, it should work hard to ensure that teams remain stable for long periods of time.
This also starts to address DevOps transformation. If teams own the products until their end of life, that’s part of a DevOps mindset. You can still have a call center that handles issues, but the teams that created the product still exist and still own improvements to them.
I am a fan of Microsoft Azure DevOps (ADO) for agile work management. The setup is elegant yet simple, and it is the only tool I’ve seen built on this product mindset. I’ve used Jira, VersionOne, and Rational Team Concert—and Microsoft Teams was the only one where I could set up a product hierarchy in a day without the need for tool experts.
One of my clients—the one that had an Excel spreadsheet of their products—decided to use Microsoft ADO to manage its work. When they learned how to enter their products into ADO instead of Excel, they were delighted. But then when it came time to enter their PATs, they had no idea what that meant.
It turned out that they didn’t have teams at all. They had five department managers, each of whom had lots of reports, but everyone was working on pretty much everything. The entire idea of small agile teams was lost on them.
Once the client understood the value of PATs, they began to refactor the organization to maximize PATs.
As one client identified the products and PATs, a finance team member asked if there was a way to somehow align what they had in finance with all of this and whether it was worth the time and effort. He said, “We know people are spending money, but it is really tough to understand what value we are getting from that spend.”
On the flip side, the portfolio team was struggling with knowing how much the epics, features, and stories were really costing. (Some definitions: Portfolio is the group that decides what to work on and the priority of when to work on it. Their skill is in understanding value delivery. Finance is the group that watches how money is managed. Their skill is in accounting, and they understand auditing, financial statements, and the like.)
There were a few issues at play here.
The client solved these problems by working with finance to understand how the products they had identified aligned with their financial categories. They then incorporated those categories into ADO, Microsoft’s agile work management tool. They had previously added all the products to ADO, so now they added the financial buckets at a higher level and nested the products within those buckets.
Further, this financial team had already committed to moving toward funding value streams, product lines, and/or products. That’s something that SAFe advocates for, so you can decentralize portfolio decisions and thus get to true lean portfolio management.
Once this task was finished, suddenly it was clear what people were spending money on and the value they got. They could just look at the epics or features recently closed, the features in flight, and so on. And they did all of it by way of the big visible information radiators (BVIRs) in the ADO tool.
Stories were too granular for top-level reporting. Epics were too slow-moving to be the only report. SAFe asks for large teams to be feature production machines, churning features into production like bonbons in a factory. So reporting on value at the feature level was the true currency for this type of reporting.
However, epic movement was still reported on, since it was always critically important to understand risk when an epic rumbled along. Teams continued to measure themselves on story production, as did their product owners and product managers.
At this point there was only one issue left to resolve: The quality of the epics, features, and stories was not good enough for the reports to be meaningful. That was a big problem, but there was more motivation to fix it than ever.
How they fixed that will be the subject of a separate article. (Teaser: In essence, the company realized that teams were using the epic/feature/story hierarchy, instead of a value hierarchy, as a substitute for the classic waterfall work breakdown structure. By using the value-stream vocabulary, they were able to significantly improve visibility into value delivery.)
The patterns described here will help you on your journey from projects to products. The journey is worth it, since it can increase the flow of value into the hands of your users. But remember that, while the steps sound straightforward, in practice they can be trickier than you think.
If a company started from scratch but had members from finance, portfolio, development, and operations, as well as an agile specialist and permission to make changes, it could do this in months, not years. But if the team were missing members, it would take much longer, take more wrong turns, backtrack more often, and might never be done—or it would take years.
[ Read also: Anthony Crain’s Projects to products: What it means, why it matters ]
Get up to speed on using AI with test automation in TechBeacon’s Guide.
Find out the top four benefits of AI-powered testing in this Webinar.
Learn best practices for reducing software defects with TechBeacon’s Guide.
Download the free report “Agile and DevOps Reduces Volume, Cost, and Impact of Production Defects”.
Practice quality-driven development with best practices from QA practitioners in TechBeacon’s Guide.
Download the free World Quality Report 2019-20.
Get the best of TechBeacon, from App Dev & Testing to Security, delivered weekly.
I’d like to receive emails from TechBeacon and Micro Focus to stay up-to-date on products, services, education, research, news, events, and promotions.
Check your email for the latest from TechBeacon.
Agile strategy: How to go from projects to products in 3 steps
Research & References of Agile strategy: How to go from projects to products in 3 steps|A&C Accounting And Tax Services
Source
0 Comments