Agile*Product*AI

It always seems to happen. Your nearing the completion of the final sprint. The company is excited for the new product, features, and or services to be made available to the customers. And it happens. The dreaded email arrives. Their is a defect that we absolutely can't ship with. And worse - its "architectural". I'm a bit embarrassed to admit that nearly every significant release I've been involved with has had this scenario. The email goes out, the team panics, management panics, the company panics. It's the end of the world! This just happened for us on the Serena Agile On Demand project. Well, we did some of the compulsory panicking, but got our wits about us and got back to work. A few of our developers when dark for a few weeks to better understand the root causes. Testers rallied around them and provided them data and performance metrics. But after a couple weeks, we hadn't made progress and the release was at risk. Well, what we were doing clearly ...

No, you're not really stupid. I just wanted a provocative title to get your attention! As I've been getting ready to bring Serena's new Agile On Demand product to market, I've spoken with several customers that are trying to optimize resource utilization to improve the throughput of their organizations. This is the classic PPM approach. In PPM, we manage our projects and resources down to a very fined level of granularity. And many Agile/Lean approaches can be effectively blended into PPM practices. But be careful with resource management. In Agile, it’s the team that is the unit of management. And we want to work on optimization of the team's velocity. Not an individual's utilization. We do this by putting teams together and keeping them together for as long as possible. If cross functional teams are built and sustained, empirical data shows us that their throughput (velocity) will increase overtime. And for large problems, we can breakdown the work using a var...