Problems Maintaining Product Development Innovation in an Agile/Lean World

Hi all:


I'll be presenting the following discussion at the Agile Austin Leaders SIG on Friday, March 1st, 2013 at CA Technologies in Austin, TX.  I'm really looking forward to feedback!

@multicastmatt

Sign up:

http://www.eventbrite.com/event/5381488176 

Abstract:

One of the benefits that many product development teams are able to realize when they switch to an iterative or limited WIP process for developing software is (finally!) a ranking of work items on which the team can focus.  Over time, this allows a good deal predictability for the stakeholders of the project, especially when work items have corresponding “done” criteria that are adhered to.  Some organizations are so enamored with the results of this shift that they begin to assemble all members of team into these types of structures, including team members that were previously dedicated to research or advanced product development efforts.  While this is not necessarily a bad decision for these organizations, some face issues with maintaining a level of innovation in the product efforts as there may be a perception that there is neither time nor the people to work on important innovation efforts.  Further, some of these team members may be doing work that is neither challenging to them as individuals nor is bringing the appropriate value to the company.

In this discussion, Matt will help shine a light on this issue that can be especially challenging for a product development company that seeks to maximize the velocity of a product team working against the near-term roadmap but may lose sight of competitive challenges that may change the very nature of the playing field.  He will describe the challenges faced by teams he has worked with both in the past and currently and share what he has learned.  A healthy discussion is expected to follow!

Bio:

Matt Roberts is an agile pragmatist continuing his lifelong learning journey, currently serving multiple teams as Senior Director of Software Engineering and Agile Coach at CA Technologies. His experience is wide-ranging as he has developed software and led efforts to create systems for product development teams to deliver innovative solutions in companies ranging from early-stage startup to publicly-traded companies in both consulting and full-time roles. He has had the privilege of serving the Austin software development community as Agile Austin President over the past two and half years and as Secretary for the IEEE Computer Society over the past eighteen months.
Matt holds certifications as a Certified Scrum Practitioner (CSP), Certified Scrum Master (CSM), and Certified Scrum Product Owner (CSPO).  If you’d like to learn more about him, please visit http://linkedin.com/in/cpgmattr or see his latest thoughts at multicastmatt.blogspot.com.

Communicating Architecture Decisions in Financial Terms

During yesterday's AgileAustin Architect SIG, we had a lively discussion about communicating architecture across various parts of the organization, which was particularly relevant to me as we're now communicating our decisions to a group of about 4,500 where the number was previously less than 40! Good times.

Now that I'm frontal cortex-deep into _The Principals of Product Development Flow_, I stated thinking about communicating architectural decisions in light of economic factors, expanding the communication chain out to the corporate finance types, etc. During this discussion, I remembered a book that I read a while back that presented a series of financial models for software development projects--especially agile software development projects that may be able to fund themselves by releasing the most valuable features early. This one is interesting as it finally gets to that holy grail of terms to couch various technical decisions--total lifetime profit.
The book that I was discussing was _Software By Numbers, Low-Risk, High-Return Development_ by Mark Denne and Jane Cleland-Huang. It was written in 2004 and is still very relevant. While I find that the concepts can be applied in the large, they're also very appropriate to be applied in the context of day-to-day decision making and can be used effectively for arguments for technical debt reduction, doing things "the right way" and so on. The important thing is to frame technical decisions as business decisions, especially when non-technical folks have the final say.

By the way, if anyone wants to borrow this book, just let me know--I'd be happy to bring it to
the next meeting or would just mail it to you.

Thanks again Lee and David for leading this awesome group!

Don Reinertsen's Video on InfoQ - "Second Generation Lean Product Development: From Cargo Cult to Science"

Mike DuVall turned me on to this video the other day: http://www.infoq.com/presentations/2nd-gen-lean where Don Reinertsen discusses framing many of our engineering problems in light of economic tradeoffs. One of the interesting things to see is how the ideas of lean manufacturing DON’T apply to product development (perhaps this is counter-counter-intuitive? J ). This presentation was made during the Lean and Kanban 2009 conference and I believe a number of folks have been discussing some aspects of this for a while, but I’ve also talked to a number of folks who also may not be aware of it.

I often find myself in conversations with teams who have adopted some of the practices of Scrum but are disappointed with the results that they are seeing. When I ask a few probing questions, I find out that they’re somewhat missing the point and have adopted neither the agile principals nor values on top of which the Scrum framework was based. I’m sure the same can be said for adoption of others’ successes where limited benefits are observed. The term “cargo cult” has been used to refer to this type of behavior and this video has a definitely serviceable explanation of the phenomenon.

It’s definitely a bit more of an advanced topic, but shouldn’t be difficult for most folks with a technical background to understand (although you may need to review a few of the bits a few times to get the full meaning). Not surprisingly, Don has a book, which is called _The Principals of Product Development Flow: Second Generation Lean Product Development_ (http://www.amazon.com/gp/product/1935401009/ref=cm_li_v_cr_self?tag=linkedin-20). I IMMEDIATELY ordered this book after watching the video and am now half way through it. By the way, Don Reinertsen wrote the intro to _Kanban_ by David J. Anderson and he is credited for a great deal of influence on this work.

@MulticastMatt