Agile*Product*AI

I am presenting my post on Agile ROI in a brief webinar today. I will basically go over my previous Agile ROI post with the inclusion of some new materials. Enjoy.

So I blogged on this topic a few months back. You can find that blog entry here. It was a popular post. So much so that we made a webinar out of it with the Agile Journal. Jeff McKenna, Serena's Chief Agile Evangelist and the first Scrum Coach, and Paul Dupuy, an agile black belt and the Product Owner for Serena Agile On Demand joined me for the session. We had a great time and hopefully the attendees found it valuable. You can find the information on the webinar here and a recording of the webinar here. We had far more Q&A than could be addressed in time allotted. I guess the discussion going a little long didn't help much either! So I decided to cross post the Q&A here in my blog. Enjoy (or ignore)! What if the business process isn't defined how does Agile handle business  reengineering?  When the business process is not defined, an agile approach provides an incremental model to explore and define it! Using Scrum for instance, you would work with your Product Own...

There is an idiom in American English that I use quite often. I assumed that it was commonly used – at least here in the States. The full idiom is “as American as motherhood and apple pie”. It’s typically used when you are describing something that is quintessentially American and an idea that very few would disagree with. Its often abbreviated to “motherhood and apple pie” and use when describing something obvious. When I enumerate the benefits of agile methods, they are, well, mother hood and apple pie! Here they are: Ensure the right software gets built through customer collaboration Deliver value early and often with incremental development Optimize production throughput and communication with collaborative, cross-functional teams Rapidly adapt to changing business, market and customer requirements Deliver higher-quality software through test-driven development Provide predictable execution and real-time visibility Ensure the right software gets built through customer collaboration...

After much prodding from Jeff McKenna, I finally got around to reading “Software By Numbers” by Mark Denne and Jane Cleland-Huang.  It’s an interesting read that focuses the software development process on delivering value to customers.  Denne and Cleland-Huang introduce minimum marketable feature (MMF).  The MMF represents the smallest possible decomposition of a feature/capability to which business value can be attributed.  The authors go further to define a software development value chain that is designed to optimize value delivery to the customer.  While I of course have some concerns with the model, I found the underlying financially driven approach very interesting.  It aligned very well with prior work that I’ve done in Project and Portfolio Management (PPM). Software by Numbers got me thinking about Agile.   Specifically around incremental development and how it has an inherent advantages over traditional methods in delivering value to cu...

Sometimes I worry that we are wringing all the agility out of Scrum with the high degree of prescription that I see some teams follow. At times I see backlogs rigorously maintained and scrubbed. Product Owners tightly managing how/when/if the backlog items flow out of the backlogs into a team's sprint. And the team maniacally focused on delivering exactly what was specified in each sprint. The irony here is, that more often I am coaching my teams to execute exactly as I just described! I struggle though with prescriptive scrum on how we can deal with innovation. In my 20 years building software I have seen most interesting innovation come from the individual, not the team. Yes, this will be heresy to the agile zealots. But good Scrum Masters (team leaders) must find a balance between the team and the individual. We must build a culture and environment where not only the team is empowered but where the individual is encouraged to innovate.  Innovation can be encouraged with varying ...

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...