More on this book
Community
Kindle Notes & Highlights
while I mentioned Agile, and while almost everyone today claims to be Agile, what I've just described is very much a waterfall process. In fairness to the engineers, they're typically doing about as much Agile as they can, given the broader waterfall context.
FAST fixes this problem of broader waterfall ways of working
Ahmed Avais liked this
if you're just using your engineers to code, you're only getting about half their value. The little secret in product is that engineers are typically the best single source of innovation; yet, they are not even invited to the party
Teams using Agile in this way are getting maybe 20 percent of the actual value and potential of Agile methods. What you're really seeing is Agile for delivery, but the rest of the organization and context is anything but Agile.
projects are output and product is all about outcome.
I have no doubt that many people and teams are in some measure disappointed with the results from their adoption of both Lean and Agile. And I understand the reasons for this. That said, I am convinced that Lean and Agile values and principles are here to stay. Not so much the particular manifestations of these methods that many teams use today, but the core principles behind them. I would argue that they both represent meaningful progress, and I would never want to go backward on those two fronts.
FAST Agile aims to fix many of the issues that allow agile to become flaccid/fake
Ahmed Avais liked this
the way Agile is practiced in most product companies is hardly Agile in any meaningful sense.
The best product teams I know have already moved past how most teams practice these methods—leveraging the core principles of Lean and Agile, but raising the bar on what they're trying to achieve and how they work.
Products are defined and designed collaboratively, rather than sequentially.
In strong teams, product, design, and engineering work side by side, in a give‐and‐take way, to come up with technology‐powered solutions that our customers love and that work for our business.
Discovery and delivery are our two main activities on a cross‐functional product team, and they are both typically ongoing and in parallel.
“We need teams of missionaries, not teams of mercenaries.” Mercenaries build whatever they're told to build. Missionaries are true believers in the vision and are committed to solving problems for their customers. In a dedicated product team, the team acts and feels a lot like a startup within the larger company, and that's very much the intention.
FAST Agile
All other things being equal, a co‐located team is going to substantially outperform a dispersed team. That's just the way it is.
we greatly prefer members of a product team to be actual employees and not contractors or agencies. It's much easier to be co‐located and to be a stable member of the team if the person is an employee.
there is nothing wrong with a company having multiple locations, so long as we try hard to have co‐located teams in each location.
I've mentioned a few times already that these teams need to be durable, but I haven't said whether this means for a few months or several years.
Flex teams and dynamic reteaming
collaboration is built on relationships, and product teams—especially co‐located teams—are designed to nurture these relationships.
What too often happens is that the company takes people from other organizational roles—often project management or sometimes business analysts—and they say, “We're moving to Agile and we don't need project managers or business analysts anymore, so we need you to be a product manager.”
Or scrum master...
In strong teams today, the design informs the functionality at least as much as the functionality drives the design.
you need to engage directly with your engineers every workday.
Agile Manifesto Principle
the morale of the engineers is very much a function of you as the product manager. It is your job to make sure they feel like missionaries and not mercenaries.
Not every engineer or even senior engineer wants to participate in discovery activities, and this is fine. What's not okay is to have a team of engineers in which none of them wants to engage in discovery activities.
it's very possible that your engineers are responsible both for writing software and for writing these automated tests. If that's the case, then you probably won't have many test automation engineers.
Many of the problematic issues with autonomy arise because of issues of scale.
Even with the best of intentions, product roadmaps typically lead to very poor business results.
prioritizing business results, rather than product ideas. And, yes, it is more than a little ironic that we sometimes need to convince management to focus on business results.
the root cause of all this grief about commitments is when these commitments are made. They are made too early. They are made before we know whether we can deliver on this obligation, and even more important, whether what we deliver will solve the problem for the customer.
Most important, the product vision should be inspiring,
Don't be afraid to disrupt yourselves because, if you don't, someone else will.
The product vision needs to inspire. Remember that we need product teams of missionaries, not mercenaries.
More than anything else, it is the product vision that will inspire missionary‐like passion in the organization. Create something you can get excited about. You can make any product vision meaningful if you focus on how you genuinely help your users and customers.
people with their different skill sets usually come from different functional departments in the company, but they sit and work all day—every day—with their cross‐functional team to solve hard business and technology problems.
Mob Programming!!!
Keeping a small number of teams and their engineers doing useful stuff is not very hard, but getting good results out of a medium—or, especially, large—organization can be truly challenging.
FAST Agile
it turns out that getting the engineer's perspective earlier also tends to improve the solution itself, and it's critical for shared learning.
In general, product discovery is about tackling risks around value, usability, feasibility, and business viability. However, in some cases, there's an additional risk: ethics.
the one I'd recommend is the customer discovery program. Yes, it's a lot of time and effort—especially on the shoulders of the product manager—but it's my favorite leading indicator of future success. I attribute much of the success in my own career to this technique.
Story maps are one of the most generally useful techniques I know. They are essentially a framing and planning technique, but they are just as useful for ideation. They are also used as a design technique when working on prototypes, and they are great for communicating with your team and stakeholders. They also play a very practical role in managing and organizing your work. Further, a story map is helpful throughout product discovery and delivery. I think you'll agree that's a lot of benefits. But the best part is how simple it is.
there are few things as powerful as a marketing person who's also strong at product. The combination is amazing.
what's really going on is that the ideas are already handed to the product teams in the form of prioritized features on product roadmaps, where most of the items on those roadmaps are coming either from requests from big customers (or prospective customers), or from company stakeholders or execs. Unfortunately, these are rarely the quality of ideas we're looking for.
if the product team is given actual business problems to solve rather than solutions, and the product team does their job and interacts directly and frequently with actual users and customers, then getting a sufficient quantity and quality of product ideas is not really a problem.
I consider developers to be one of the consistently best sources of truly innovative product ideas. Developers are in the best position to see what's just now possible, and so many innovations are powered by these insights.
Most of the time, when we do a usability and/or value test, it's with the product manager, the product designer, and one of the engineers from the team (from those that like to attend these). I like to rotate among the engineers. As I mentioned earlier, the magic often happens when an engineer is present, so I try to encourage that whenever possible.
if you show your prototype to two different people and the response you get is substantially different, your job is to try to figure out why.
many problems arise because the vast majority of these Agile coaches don't have experience with tech‐product companies, so their experience is limited to delivery.
product discovery is the most important competency of a new startup,
every time you reference a product roadmap item, or discuss it in a presentation or meeting, be sure to include a reminder of the actual business outcome that feature is intended to help.
It is all too easy to institute processes that govern how you produce products that can bring innovation to a grinding halt.
FAST was designed to solve this
there are several process consultancies that specialize in “Agile at Scale,” which introduce methods and structures intended to scale to large numbers of engineers, yet which absolutely destroy any hope of innovation.
FAST Agile will not kill your innovation - it will enhance it!
that new leader may assume you're hiring them for their knowledge of process and how to define and deliver products. And, so they bring with them their views on how things should work. Even worse, they often then proceed to hire people that want to work in those ways.
emphasize to them that the new company is interested in them because of their mind and their talents, and of course they wouldn't want to bring with them the bad practices of their former company.
the product organization is not there “to serve the business” but, rather, to solve problems for our customers in ways that work for our business.
