In my past two posts in the Scaling Agile series, I’ve written about the triangle of traps and the challenges of developing complex systems when scaling Agile development. Today I would like to focus on the impact and challenges at the team level when developers and product owners are forced to operate in dispersed and distributed environments – a situation that could impose serious dependencies and may have an impact on other teams.

Three points of impact

The working context of large projects directly impacts team members in three big ways:

• They are dealing with a huge backlog and multiple teams, making it difficult to answer questions like: What is really important? Are there dependencies? Which pieces are locked by contractual commitments?
• The customer is typically not part of the team and in the high pressure to deliver it is easy to loose sight of who wants what we are building, why it is important, and how does the customer expects it to work.
• With multiple, distributed teams and individuals there is much more information to track and things easily fall through the cracks.

How to Break Down Backlog: Strategies

I’ve written about the need to break down large backlogs into tiers, but the big question is how? As backlogs get larger it becomes critical to have a way of defining the weight of multiple prioritization criteria to produce refined, intelligent backlogs. As criteria and weighting change, these intelligent backlogs can be automatically updated. In the Accept360product these prioritization criteria are called “strategies”.



Smart Requirements

Because teams in large projects are not self contained and customers cannot be part of every team, simple user stories are not enough for each team to manage their decisions.  In the rush to complete a sprint, shortcuts are often taken – risking that the end result misses the mark or negatively impacts the work of other teams.   To avoid this user stories need to carry a much richer set of information in addition to the description of the story. They need to be “smart requirements” and include:

• References to the customers who requested the capability, why they requested it and how they expect it to work
• Use cases and definition of affected personas
• Links to the strategies or prioritization criteria that they fulfill, so it’s always clear their strategic impact
• Dependencies from and to other user stories and the teams who own them.

Empowered Team Members Make Informed Decisions

Not being able to deliver an important feature in a release is always painful for me and from what I have seen it’s the same for anybody involved in a project. Some internal stakeholders and customers are bound to be upset. But this approach has helped me make informed decision with an understanding of the impact. It has also allowed me to proactively communicate the impact to the people affected. I find that people tend to be much more flexible and understanding when care is shown about informing them of a change instead of leaving them to discover it on their own and be surprised.

I’d love to hear what your experience has been in this area.

Each requirement has a web of relationships with customers, stakeholders, market elements, risks, and competitors

In my last post I talked about the fact that agile methodologies are all about “doing the most important thing first.” This post is about figuring which is the “most important thing.”

As a product manager or product planner, how do you reconcile the following:

• Too many ideas
• Too many customers clamoring for their pet enhancements
• Engineering teams who have lots of “cool” things they want to implement
• The sales force screaming about the “must haves” of today’s “deal of the day”

Prioritization is a problem whether you’re doing waterfall or agile, and whether it’s a new product or an existing product. In the agile context, you have to determine your most important story, then execute on that story. Then on the next most important story, and so on.

This is easy to say, isn’t it – just do the most important thing first! But there’s a slight problem – how do you know what’s most important? If you’re a product manager or product planner, you have many constituencies, each with their own set of priorities, and each with more than you can possibly accomplish. You have to consider: customer needs and their desires (often as important as needs); company goals and strategies; your technical capability to execute on the story; tactical sales force needs; and let’s face it, personal assessment of the importance by everyone from the product manager to the engineer to the CEO herself.

And if you don’t come up with a prioritization someone else will – maybe an engineering manager, maybe the VP of Sales. And they’re not in a position to necessarily make the best decision for the company as a whole.

Now once you do make a decision, as the product professional, how do you justify it when those with axes to grind seek you out, or call you on the carpet in the executive board room?

For all these reasons, you’d better have a system – and it’s best if that system is visible, takes into account the interests of all the stakeholders, and in general helps you find the “right answer.” It’s even better if the system is not just qualitative, but quantitative, and traceable. This sounds a little like a spreadsheet, but as lots of product managers have discovered, spreadsheets have a host of problems:

• It’s hard to represent all the relationships you want to capture – to customers, market themes and other strategic elements, risks, competitors, etc.
• They aren’t very transparent
• They are terrible for acting as an enterprise knowledge base (if even stored in a sharepoint or wiki), and
• Who wants to, or has time to, create a big spreadsheet model?

So, you want something that’s a little like a spreadsheet, but is also

• Transparent
• Enterprise
• Purpose-built to handle the desired relationships to customers, market segments, competitors, risks, and marketing themes.
• Provides out of the box analysis

Well, I have one of these, and as a PM who didn’t have one in my last job, I must say it’s changed my life.