I’m Predictable in an Agile Environment
LIKE.TG 成立于2020年，总部位于马来西亚，是首家汇集全球互联网产品，提供一站式软件产品解决方案的综合性品牌。唯一官方网站：www.like.tg
“Being Agile” and “being predictable” may seem mutually exclusive, at least when it comes to product management. A good sprint cadence creates a predictable frequency of software releases but divining what’s actually in them feels harder. Isn’t the whole point of Agile that we can continuously adjust, making on-the-fly tweaks to seize opportunities? Contrary to some prevailing opinions, managing products in an Agile environment doesn’t mean surrendering planning to the whims of the development team. In fact, Agile can help you be more predictable in some ways. I say this speaking from personal experience. I’m predictable in an agile product environment.
Agile ≠ Chaos
Those unfamiliar with Agile often have some misconceptions about how it really works. Let’s start by dispelling a few Agile myths:
Agile is a free-for-all.
Developers don’t code what they feel like, and the software doesn’t just ship at random points of time. Agile is merely empowering the product development team to make iterative progress while adjusting to incoming data.
Product managers don’t have a role in an Agile environment.
Product managers are still prioritizing features, gathering and synthesizing customer feedback, defining a strategy and product vision, and offering input to the implementation process. None of these tasks go away. You’re no longer writing lengthy product requirements documents with the same exacting detail as before. But developers still both need and value your input.
Dates don’t matter.
Agile certainly embraces a more fluid approach to project management. But if something needs to ship by a specific date, there’s nothing in the Agile Framework preventing it. In fact, by iteratively developing the software over multiple sprints, chances are the desired functionality will ship with fewer defects. Unlike in the waterfall model, it’s reviewed numerous times during the process.
There’s no visibility into what’s happening.
With waterfall, there are often project plans detailing what every resource is doing all the time. Anyone can take a peek and know precisely what folks are up to and how things are progressing. This type of visibility may be murkier during the actual sprint, but that’s not the case before and after. Setting sprint goals before a single line of code is written, and retrospectives (or micro-retrospectives) provides an opportunity to dig into what transpired and improve things going forward.
Plans are useless as everyone chases the latest shiny object.
First of all, once a sprint begins, what the team is working on for those two or three weeks shouldn’t change. The sprint goals remain locked. However, if something new does come up, the sprint planning team (including the product manager) can decide whether it’s worth altering the course for future sprints.
Applying Agile Values to Product Management
The Agile Manifesto has four core values. These Agile Values are the central tenets that drive everything else. Looking at each one, we can see their potential to make product management (and product managers) more predictable in agile environment.
Individuals and interactions over processes and tools
At first glance, you may already be scratching your head. How does this make a product manager more predictable? But note that this value uses the word “over” and NOT “instead of.”
There is still plenty of room for tools and processes. Agile needs those to be in place to avoid developers idling and things from getting out of hand. But it also elevates the importance of communication and addressing stakeholder concerns.
By creating more frequent dialogue, there is an increased level of transparency; when people know what’s happening and why they can better predict what’s to come. There’s no black box, no guessing about when things might ship.
In an Agile world, things may change a little more often. But everyone will also know about changes much faster and understand any potential ramifications.
Working software over comprehensive documentation
By removing the requirement for, well, detailed specifications, teams can deliver updates and new functionality faster. This process shortens the distance from prioritization to ship date.
When there are fewer hoops to jump through and hurdles to clear, it’s easier to predict availability. After deciding to build, product managers should have a solid sense of when things will debut. They can then provide clear communication to coworkers and stakeholders.
Customer collaboration over contract negotiation
Customer-centric companies are committed to doing everything with the best interest of customers in mind. They’re continually processing user feedback and turning those requests and complaints into a better product.
Guess what gets in the way of that kind of responsive, ongoing progress? Having to renegotiate a contract every time something changes. When the lawyers get involved, there’s no telling how long things can get held up.
Removing those entanglements lets teams focus on building a great product. It removes this common source of uncertainty from the equation.
Customers need to pay for things, and a contract might be required. But Agile-friendly companies structure those agreements, so they don’t hinder innovation and iteration.
Responding to change over following a plan
Of the four values, this one seems the most contentious with our thesis. Plans make things predictable, don’t they?
Well, executing a plan properly is predictable. But while the plan’s elements are predictable, you can’t always predict what transpires after a product ships.
Adoption, usage, churn, reviews, net promoter scores… there’s no way to know what’s going to happen until it happens. If you’re operating with an inflexible long-term plan, it’s hard to adjust based on the product’s reception. When the cruise ship is chugging along, it’s tough to change course.
The best part of Agile is being able to measure, learn, and adjust. That means plans must be a little more dynamic instead of plotting out every single move for the next 18 months. That’s why roadmapping is a predictable product manager’s best tool for managing expectations and hitting target goals while still utilizing the benefits Agile has to offer.
Download Strategic Project Alignment in an Agile World ➜
The Art of the Agile-Friendly Roadmap
One reason some product managers can turn negative toward Agile is that their “capstone” project (the product roadmap) might seem at odds with the framework’s fluidity. Well, if your product roadmap is chock full of particular features and exact dates, then you’d be well within your rights to be frustrated.
However, including that level of detail and specificity isn’t the only way to build a roadmap. We’d argue that approach isn’t doing anyone any favors, including product managers.
Feature-Less Roadmap
Instead, product roadmaps featuring goals and themes are usually a much better way to go. Themes illustrate what parts of the product will be worked on at different times, along with the desired outcomes of those efforts. You can escape the trap of promising features and dates—which are inevitably destined to change in an Agile environment—while still communicating the direction and priorities for the product.
If there’s concern that a feature-less roadmap is too vague and open to interpretation, add milestones as specific scheduling targets. This change doesn’t guarantee a particular feature will be available by a specific date, but it conveys that you’ll reach a goal by that time.
Remember, a roadmap’s primary purpose is communicating a vision for how the product strategy will become a reality. Implementation details and schedules aren’t required to build stakeholder alignment.
Getting on Board with Agile
We get that Agile can sometimes feel like it’s taking control away from product managers and handing over more power and decision-making to the implementation side of the house. But wary PMs should take comfort in a few Agile principles that simplify their ultimate goal of delighting customers.
#1) Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Customer satisfaction is the first principle of Agile. Not “building cool stuff” or “unshackling the creativity of our development team.”
#2) Business people and developers must work together daily throughout the project. We used to throw requirements “over the wall” and see how things shook out. But the ongoing dialogue between product and development should result in products meeting expectations and delivering customer value. Moreover, you get the chance to stick your nose into things every day!
#3) The most efficient and effective method of conveying information to and within a development team is face-to-face communication. We mean, you might need to attend daily standups. But it also means you’re not spending as much time writing lengthy documents no one ever reads. You can continually assert yourself as the business owner and voice of the customer.
You can be Predictable in Agile
Ready to learn even more about how Agile and product management can not only coexist but simultaneously thrive? Read the Agile Product Manager's Guide to Building Better Roadmaps
LIKE.TG 专注全球社交流量推广，致力于为全球出海企业提供有关的私域营销获客、国际电商、全球客服、金融支持等最新资讯和实用工具。免费领取【WhatsApp、LINE、Telegram、Twitter、ZALO】等云控系统试用；点击【联系客服】 ，或关注【LIKE.TG出海指南频道】、【LIKE.TG生态链-全球资源互联社区】了解更多最新资讯
本文由LIKE.TG编辑部转载自互联网并编辑，如有侵权影响，请联系官方客服，将为您妥善处理。
This article is republished from public internet and edited by the LIKE.TG editorial department. If there is any infringement, please contact our official customer service for proper handling.
