Agile

I started this series discussing the issue of the various product-based roles in an agile organization. I suggested a product value team because one person becomes a bottleneck. One person is unlikely to shepherd the strategy and the tactics for a product. And, batching the product planning in one-quarter chunks doesn’t encourage us to reduce the feedback loop duration. When ...

Many of today’s enterprises are hardly fit to play a leading role in today’s world. They are designed on the past-world premises of stability and high predictability, of repetitive work with easily scalable results. They experience profound difficulties having to navigate the predominantly uncertain and unpredictable seas of today’s world. An increase in agility is needed. They adopt Scrum. Rather ...

As I’ve written these product role posts, a number of you have asked about how to use component teams. You might have a security team. Maybe a performance team. Regardless of my desire, you have component teams. You want a more agile approach to manage the interdependencies among the teams. You want to be able to deliver small features more ...

Many people in the agile community promote a product orientation over a project orientation. That’s possible because an organization has product or feature teams. That works until you have more products than teams. That’s when you might still need projects to accomplish everything. If you keep teams together, you can still use projects in a product-oriented organization. More Work Than ...

The stronger the team, the stronger the business, and it all starts with effective management. Programmers are notoriously difficult to find, screen, and onboard. They are artists. They are ambitious. Whether you have a small or rapidly-expanding team of programmers, chances are you’re going to come across situations that wreak havoc on employee happiness and morale. The popular saying “Employees ...

An agile approach requires a cross-functional team. That means that everyone on the team focuses on the same intent. That intent might be an entire product. It might be a feature set as part of a larger program. But, the team focuses as a team. That cross-functional team is a product team or a feature team. I tend to call ...

Managing a growing product can be as rewarding as challenging: Involving more people and teams and scaling up is hardly ever easy. This article shares 10 practical tips to help you effectively scale as the person in charge of a product. 1 Involve the Right People A small group of qualified individuals who have the right skills and motivation can ...

In an ideal agile world, the team would work directly with a customer. When you have a small product that serves maybe three types of customer (new, expert, admin for example), and that customer is down the figurative hall, you might not need any product people. You can create short feedback loops with your customer. (See Part 1 for more ...

We have many words for people who shepherd the business value of a product. The many words aren’t a problem, as long as we can all agree on what these various people are and they take responsibility for. When we don’t agree, we run the risk of not managing our strategy, not thinking in terms of problems, and not managing ...