The following article was posted on InformIT yesterday: A Contemporary Framework for Agile Product Management in the Enterprise.
Pieces of it have been spread around this blog before, but this is a fairly standalone piece describing my view of the changing role of the product manager in the agile enteprise.
Below is my updated presentation from Agile 2009 yesterday. Thanks to those who attended.
Hiren Doshi is doing a good job of describing various considerations around the feature vs. component teams discussion and on the practical application of the three tier Big Picture model for larger and distributed enterprises, at his blog at www.practiceagile.com. His ongoing, experience-based perspective is lucid and practical so I’ve added his blog to the blogroll. For those interested in this thread, check out these posts on the feature vs component teams debate.
Readers of this blog are likely aware that effectively implementing software agility at the enterprise level is no small feat. Even for the fully committed department or enterprise, it can take six months to a year to introduce and master many of the basic agile practices and a number of additional years to achieve the productivity and quality results that fully warrant the effort of such a significant enterprise-wide transformation. As challenging as this process may be however, a number of large organizations have made the transition before us and patterns for success have started to emerge.
In my discussions with teams, managers, and executives during over the last year or two, I often struggled to find a language for discussion, along with a set of abstractions and an appropriate graphic that I could use to quickly describe some of these patters of “what your enterprise would look like after such an agile transformation”.
In doing so, I would need to be able to describe the new software development and delivery process mechanics, the new teams and organizational units, and some of the roles key individuals play in the new agile paradigm. In addition, any such Big Picture should highlight the requirements practices of the enterprise agile model, because those artifacts uniquely carry the value stream to the customer.
Eventually, and with help from others, I arrived at something that worked reasonably well for its purpose. I call it the Agile Enterprise Big Picture and it appears in Figure 1 below.
Big Picture
Figure 1 – The Big Picture of Enterprise Agility
Over the last year, I’ve described the Big Picture fairly extensively in a length series of blog posts under the series https://scalingsoftwareagility.wordpress.com/category/big-picture/. However, in blog series form, it’s hard to get the gestalt of this somewhat complex construct, as the posts are fairly short and quite numerous. Frankly, it takes some hard work on the part of the reader to piece together “the Big Picture of the Big Picture”.
So I’ve written the whitepaper below, wherein I explain the Big Picture at a level of detail conducive to the overview, summary level. You can download it here:
The Agile Enterprise Big Picture (2)
I hope it delivers some value to you, and as always, comments are welcome.
Prompted by the discussion of feature and component teams, a reader recently sent in the following question:
“I have a user story, that on its face, appears to have been structured in such a way that it simply cannot be independent. That is, the story itself cuts across teams, and even across product lines. If the story were to be broken down any further, it would only be into its constituent tasks. Moreover, it appears the cross cutting nature of this story will lend itself to the necessity of creating a virtual team of sorts as it will take individuals from many teams to coordinate. Moreover, we have identified many new stories of this nature.
The team involved is rather large (300+) and spans several countries. So I suppose what we may be looking at is one very large project team with many sub-teams and that many stories may impact many teams. My first inclination is to suggest that if a story such as the one above exists, then it should be decomposed into smaller stories that each team can work towards. However, I’m struggling with the lack of delivering anything tangible on a per story basis.”
Here was my response:
=============================================
Drew,
Your first inclination is generally the best one. At enterprise scale, many features span teams. This is indeed the common case, especially as the customer value stream pile moves up the stack to where they are using multiple products, web services, or whatever, in new and innovative manners. However, there should be no reason to create new teams, or programs, just to coordinate content of this type.
Don’t worry so much about the fact that each team-level story doesn’t appear to deliver user value by itself, (although you should take every opportunity to see if you can define team-level value stories that deliver value to their users too) as that is taking the user value story metaphor too far. Since you can be dang certain that the bigger feature is delivering value to your customer, it doesn’t matter that some team is having to build an adapter-API –widget-whatever, or has to refactor some code that they wouldn’t otherwise have to refactor. It’s just part of what they do to deliver larger end-user value.
Indeed, this is such a common occurrence in the enterprise that the Big Picture was designed in part to address it: Here’s how it’s handled.
Big Picture
If you are organized this way, you should be able to handle any number of larger spanning features. In the Big Picture, features and stories are just “content” to the teams prioritized backlog. The process just runs and runs, without the necessity for reorganization.
Whether currently organized by feature, component, product or service, if you attempt to reorganize every time a cross cutting feature comes along, everyone will spend too much time figuring out where their desk is or who the product owner is, and too little time cutting code.
Note: also see the following post on the same topic.
Scaling Software Agility 