Good article by Jeff Lash about how product managers should keep an open mind about agile development practices and how to adopt them as part of their product management approach.

Good case study / anecdote about how a company responds to competitive pressures in the agile vs. waterfall world.

From the article:

Two years ago, in response to emerging customer needs and a surge of new entries into the network monitoring market, Ipswitch realized it had to pick up the pace of its product development strategy. Although the company's software had been widely regarded as among the best and easiest to use, the game had changed. Overseas companies had started to become serious price competitors. And a number of domestic startup firms, armed with marketing tactics fortified by strong venture funding, had also aggressively entered its space. As a result, unless the company could deliver its products to new and frequently inexperienced customers in ways that would work right the first time, Ipswitch's managers knew their market edge risked being lost for good.

From Scott Ambler:

One of the great debates raging within the IT industry is whether or not agile software development techniques work.  My experience, and the experience of thousands of others, is that they do.  One of several reasons why agile techniques are so effective, in my opinion, is that they reduce the feedback cycle between the generation of an idea (perhaps a requirement or a design strategy) and the realization of that idea.  This not only minimizes the risk of misunderstanding, it also reduces the cost of addressing any mistakes.  In this article I explore this idea in detail. 

Deep analysis of the tasks that must happen in an iteration - development, analysis, testing, etc.  Focus on the problems with staggering them too much, and suggestions on how to properly organize the team around those tasks.

Overview, explanations, and details from Scott Ambler.  This documentation approach can be used for agile and non-agile processes.  It can also be used for product management / development and for business analysis.

Identifies and defines over a dozen principles of agile modeling.  Good introduction or reminder

From the article (by Scott Ambler):

UML 2 activity diagrams are typically used for business process modeling, for modeling the logic captured by a single  use case or usage scenario, or for modeling the detailed logic of a  business rule.  Although UML activity diagrams could potentially model the internal logic of a complex operation it would be far better to simply rewrite the operation so that it is simple enough that you don’t require an activity diagram. In many ways UML activity diagrams are the object-oriented equivalent of  flow charts and  data flow diagrams (DFDs) from structured development. 

The topic of applying agile methodologies to your business processes seems to have become quite popular these days. The benefits of becoming agile are pretty attractive for software companies and yet many of them still do not clearly understand how they could make a smooth transition and whether this “agile” thing really works ...

Useful list of possible approaches to make up iterations in agile product development.

Burndown is a technique used in Scrum projects for tracking the progress within or across sprints. It is an exciting way to track how a team is progressing against a deadline - and we can apply it to any form of project-status. In this article, we will apply it to documenting business processes.