Ted Bauer and Michael Boykin take on daily, synchronous standups in their article The Daily Standup is Broken, What Should You Do Now?

Asynchronous daily standups or check-ins help to put an end to boundless, traditional standup meetings and get the whole team on the same page with fewer meetings. And corresponding written status updates within a team coordination tool or platform — something that allows every team member to share and review updates from today, yesterday, or even last week — allow everyone to consume updates easily and on their own time.

We landed in a similar (asynchronous) place with our standups, and I wrote about it a while back in Useful daily standup meetings for remote teams:

The issue is always the same: How do we have standups that are useful and that don’t feel like busywork that just takes us away from the jobs we’re supposed to be doing? By using an asynchronous bot and adapting the questions to our needs, we accomplished a few important things:

• Every member on the team takes a few minutes every morning to plan out their day, and troubleshoot anything that might have gone wrong the previous day.
• Instead of weekly meetings of an hour long where we discuss what everyone’s working on, we now have focused 30-minute meetings every Monday where we solve problems and discuss issues that came up during the week.
• I am much more equipped to fulfill my role as Product Manager because our updates are more frequent and the signal to noise ratio is extremely high.

Philipp Krehl has a very thorough, practical article up on Mind the Product called Product Discovery or Product Delivery: How do you Decide? His main thesis is that figuring out when it’s safe to move to the build/delivery phase of a project is all about your level of certainty about the problem you’re solving. He proposes a simple rubric to calculate your comfort level with different product risks:

If you and your team have marked every answer a 3 or below, it confirms that you have a high degree of certainty about your path, and you can start building. You will probably still discover new information but you can just adapt to it — this is why we work with Agile methodologies like scrum or Kanban.

Answers marked with 4 or above indicate areas where you should invest and do product discovery to reduce your uncertainty. At this stage, it’s better to figure out the right thing to do rather than commit to an outcome.

Once you have identified areas which require more understanding you can use an effective technique called Assumption Mapping.

He also provides a good overview of the value and practical aspects of Assumption Mapping, a method I am keen to try out.

Megan Quinn’s post on Development Cadence starts off really strong:

The hallmark of a well-run development engine is a development cadence that is brisk in bringing new products to market without burning out its builders.

And then it only gets better from there. Her point about being “flexible on scope, fixed on time” is spot on:

One way to establish a good development cadence is to commit to a predictable launch schedule and avoid slipping by pushing out features, not time. Some organizations commit to launching every month with the notion of ticks (small feature releases/fixes) and tocks (bigger, marketable moments).

Ulaize Hernandez Troyas makes a good argument for involving full teams in the prioritization of what to work on:

This type of ongoing communication throughout the prioritization process has a definite cost, but the number of benefits from this approach is worth it. We have reduced friction between teammates, which has saved us from long-winded conversations that stemmed from misunderstandings. The sense of ownership and purpose has increased the team’s motivation. On a more personal level, having these open product discussions has challenged my own thinking many times over, which has definitely improved our product direction as a result.

In terms of the specifics of how this works in practice, I tend to prefer a combined approach rather than asking the team to come up with an initial list of priorities themselves. We have a leads team that comes up with a proposal for our priorities for the quarter, based on our business goals and customer insights. We then spend about a week with the entire team discussing our proposal, refining the approach, and making sure everyone is aligned and excited about what we’re working on.

I really like Matthew Ström’s concept of Responsive Roadmaps that “visualize the process of turning uncertainty and complexity into outcomes and output.” He presents this as an antidote to all the things that are wrong with traditional roadmaps:

Traditional project roadmaps are right about our knowledge in a moment of time. They are good records of our beliefs about the correct sequence and magnitude of our work. But these roadmaps are wrong about the reality of work, and almost every roadmap I’ve ever used goes out the window as soon as the work starts. No battle plan ever survives contact with the enemy.

Responsive roadmaps are right about the nature of work: it is full of uncertainty and subject to change. They are wrong about what we’ll be doing in the future; the farther out we look, the less accurate a responsive roadmap is. That tradeoff affords us time to focus in the present on delivering at the highest level of quality.

He goes into much practical detail on how to create, maintain, and use responsive roadmaps.

I really like Jeff Gothelf’s approach to the question “Does every project need to be Agile?” in his newsletter issue Digital transformation is not innovation:

No. Every project does not have to be Agile. However, each project you work on should encourage and support agility. This means that every initiative creates the ability, desire and safety to change course in the face of evidence that contradicts our original plan.

He goes deeper on what it means for teams to have the ability, desire, and safety to change when needed.

Steve Denning’s Forbes essay Understanding Fake Agile is the most useful thing I’ve read about the state of Agile in a long time. It starts off extremely strong, with his “three laws of Agile”:

• The Law of the Customer — an obsession with delivering value to customers as the be-all and end-all of the organization.
• The Law of the Small Team — a presumption that all work be carried out by small self-organizing teams, working in short cycles and focused on delivering value to customers—and
• The Law of the Network — a continuing effort to obliterate bureaucracy and top-down hierarchy so that the firm operates as an interacting network of teams, all focused on working together to deliver increasing value to customers.

Note that there’s no mention of software in those laws. This goes way beyond the original Agile Manifesto, and the idea that Agile is for software only:

But restricting agile to software development becomes a problem. When agile thinking takes over software development in a traditionally managed organization, it inevitably begins to run into conflict with other parts of the organization that are moving less rapidly and less flexibly.

This is how you get organizations that follow an agile process for their development process, while the rest of the organization still operates in silos. Steve discusses many of the other misconceptions and problems with Agile in his post.

There are some decent day-to-day work tips in Sierra Newell’s 7 Project Management Principles Product Managers Can Learn From. There’s one principle I wanted to expand on, and that’s “Define the scope and stick to it”. First, from the post:

Product managers should set the scope of their products’ development as early in the process as possible. Learning how to say no to product requests is a valuable skill. But it is also a reactive method of keeping your product’s development on track. Instead, be proactive. Define your product’s scope from the beginning, and keep development within that scope.

I know that “define the scope and stick to it” is fairly common practice, but I don’t think it’s a good way to build product at all. First, that principle tends only to define one side of the spectrum — how not to add scope. It doesn’t, however, talk about the need to sometimes reduce scope. If you define a “fixed scope” and say you won’t go over it, but then things take longer than anticipated (as they are prone to do in software) and you have no mechanism to deal with it, you’re going to get yourself in trouble. Because at that point, you “committed” to a scope that won’t change, presumably saying “no” to a bunch of things, and still you’re “late” in delivery.

This is why I’m a firm proponent of “fixed time, flexible scope” projects. Under that principle, you don’t lock down the scope for forever and ever. You commit to an initial body of work, and an expected timeframe. Then, if something happens along the way — a developer gets pulled into an emergency, or something takes longer than expected — you have a mechanism to deal with it. Since you didn’t lock down the scope, you don’t have to choose between being “late” or the team working themselves to death. You can reduce the scope of your work to fit into the time you gave yourselves to do it in.

There’s another scenario under which I would go even further and advocate for “flexible time, flexible scope” projects. There are instances where increasing scope (and time) is the Right Thing To Do for a project. For instance, if the choice is between a hacky way of implementing a feature, and extending functionality properly with future-proofing in mind, which would add two weeks to a project, I believe it’s pretty much a no-brainer that you need to add the two weeks.

This is why I think fixing scope is a dangerous practice. There are too many unknowns, too many variables, and too many things can change along the way. We shouldn’t let our process get in the way of good product decisions.

Helen Mou and Kevin Ochal share some good tips for remote teams in Making the Dream Work: Leading Distributed Product Teams. Most importantly, I agree that if you are deliberate about how you design your work process, it’s good for the whole team — whether they’re remote or not:

Instead of approaching distributed teamwork with the mindset of “we’re making it work, in spite of…” staying up late, working more hours, and spending more effort to be on a distributed team; we like to look at it as an investment in strength-building for your organization. Over time, this investment will build up your team’s trust battery, and create new habits, patterns, and behaviours that make any team — distributed or not — successful.

Related reading from me: Remote product management: challenges and opportunities.