Agile*Product*AI

The success of agile approaches depends on how close you are to your customer. This is an indisputable fact. So, if you’re an independent software vendor (ISV) that is producing commercial software products (like me at Pacific Edge Software), then how do I get my customer "on the team?" It’s likely not possible or practical and this is where effective Product Management kicks in. The Product Manager (PM) is the proxy for the customer on an agile team in an ISV or for that matter any company building products for customers that they are at least once removed from. Being on an agile team will change how a product manager elaborates and drives their product to market. And I've had some interesting challenges on retooling classically schooled PMs (some of them didn't make required adjustments and didn't survive the organizational change). While the roles and responsibilities are the same, the behavior patterns must change. The PM is integrated into the development tea...

User Stories and Epics are inadequate to capture and express critical elements of product design.  User Stories are fine grained and atomic – remember they are “implementable” within a single Sprint.  Epic Stories tend to be semantic free containers of Stories.  Creating sophisticated applications with rich application interfaces requires pre-production activities to validate Epic and User Stories with product design considerations such as usability and architecture.  We experienced this on our latest project.  Ironically, this was while building an Agile On Demand solution for work management for teams (and teams of teams) using agile methods to create software!  The team had been Sprinting together for quite some time.  Probably in the neighborhood of 15 or more 3 week Sprints that included 3 releases to production of a SaaS product.  As we approached the completion of the third release, we started getting pretty clear feedback from some team me...

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