I’ll be giving a keynote on Scaling Agility with the Scaled Agile Framework at the upcoming Scaling Agile (Scrum) conference in Frankfurt on July 5th, 2012. On July 3-4, I’ll be delivering my Leading the Lean|Agile Enterprise two-day workshop. You can check it out and register here.
I’ll post additional details on the conference when more information becomes available.
Sorry for the late post (had a nasty bug lately), but tomorrow I’m keynoting a live Rally in-person (we are here now, in Dallas, Texas ) and virtual event (live webinar) entitled Agile Portfolio and Program Management in the Scaled Agile Framework. In this webinar, I’ll be discussing the important role that an APPMO (Agile Portfolio and Program Management) organization plays in 1) Strategy and Investment Funding, 2) Program Management and 3) Governance. I’ll also be describing some of the legacy mindsets that can prevent a truly agile approach to these functions, and more importantly, what can be done about it. I’ll provide a brief update on the development status of the Scaled Agile Framework as well.
Rally will also showcase their new solution – Rally Portfolio Manager – which supports high-level program prioritization, team and project alignment to investment strategy, business view of program status, fact-based governance, and Roadmapping. If you are engaged in any of the portfolio or program management functions in your enterprise, you should take a serious look at this solution. (Yes, of course, a fool with a tool is still a fool, but an enterprise without an effective strategy for tooling large-scale agile development may be the biggest fools of all).
Chad Holdorf, agile ninja at John Deere, will also be describing some of his real-world experiences in bringing agile portfolio management thinking to John Deere’s Intelligent Systems Group.
The event will start at 9 AM CST and you can register here.
Rally will make the recording available post-event, so I’ll provide an update here as soon as its posted.
I’ll be holding a rare, open-enrollment version of my Lean|Agile Leadership Workshop in Wellington, NZ on 28/29 February 2012. It will be hosted by Assurity, a Rally-enabled partner. You can register by emailing training@assurity.co.nz.
Here’s the flyer that Assurity is using to promote the workshop.
Assurity Lean Agile Workshop Description
I’ll also be holding the workshop in Sydney (7/8 Feb) and Melbourne (14/15 Feb). You can register for these workshops at Agile University.
(Since its summer then, maybe some of you colder-climate-bound folks will come down to play in the sun and also attend the workshop? We’ll be serving tea!)
We’ve added a Lean Agile Leadership Workshop event in Wellington, New Zealand (It was Auckland at one point, but it moved, sorry) on Feb 28&29. Also, the Australia dates have been changed. The new dates are:
Sydney – Feb 7 & 8 and Melbourne Feb 14 & 15.
Sorry if that caused any confusion.
You can register through Agile University here.
As I’ve noted on this blog before, delivering my two-day Lean|Agile Leadership workshop to managers and executives is one of the most fun things I get to do. Even more importantly, it has a major benefit in preparing leaders, managers and executives to lead, rather than follow, this critical business transformation. After all, no enterprise can be leaner than its executives thinking.
Most of these workshops are delivered at a client’s site. However, I do have two public workshops scheduled in Sydney (February 7&8) and Melbourne (Feb 14&15), Australia in February 2012. You can register for these workshops through Agile University here:
In my Agile 2001 presentation (Five Keys to Building the Lean|Agile Enterprise), one of the keys I described is the question/statement to the effect of whether or not your enterprise can be leaner than the thinking of those executives and managers who pilot the ship. Although I was rushed during the presentation time (my continuing scope management challenge), I received a few interesting questions on the topic, so I though I’d post that snippet here. It’s not quite self explanatory, but it gives you the gist of the idea along with a few suggestions for what you might be able to do about it.
I continue working with a number of software enterprises in the throes of large-scale agile/Scrum rollouts. Whether it be a new rollout, or one where the next set of potential achievements and impediments rest at the door of management, one thing is increasingly clear: these rollouts will not reach their full potential until first, mid, and upper-level management is fully on board.
Since Scrum often starts bottom-up, or at least the training focuses almost exclusively on the team level, perhaps our expectation has been that awareness of the initiative at the management levels was enough. Perhaps we thought that that mangers would naturally fold into the mix and provide the requisite support and leadership needed for success at this next level. However, how we expected them to know how to do that was not so clear. Moreover, the popular chicken-pig Scrum story does not help. After all, who is the chicken and what is their role if it is not to be engaged actively in the operation of the teams? Even the role of the ScrumMaster, which in so many ways is a proxy for more effective management leadership of the team, can be as much of a conceptual barrier as it is a breakthrough. If the ScrumMaster mentors the team, what’s does the manager do? Wait patiently outside the room for a full report?
To this end, I have personally had to reset my expectations for managers in these large-scale lean/agile rollouts. It is simply not sufficient to be supportive. Rather they must be engaged, empowered and sufficiently knowledgeable to be able to lead, coach and drive the transition.
Doing, so however, requires some orientation and training which does not appear off-the-shelf from the Agile or Scrum community. To this end, I’ve created a two-day course that is designed specifically for managers and executives in such a transition. You can tell from the learning objectives that this is a serious undertaking:
1. Provide a principled, lean and flow-based product development foundation for improving competitiveness, economics and return on investment in product development
2. Introduce basic and advanced agile principles and practices as a contextual reference for a large-scale agile software development transformation
3. Introduce and experience Scrum as a potential mechanism for implementing team-level software agility
4. Introduce and explore the Agile Release Train as a means to provide strategic alignment and visibility across the enterprise
5. Introduce the agile technical and quality practices necessary for software teams to reach their highest productivity and quality potential
6. Provide a leadership framework that helps management facilitate an effective, large-scale, lean and agile transformation
Here is the abstract for the course:
Lean Agile Enterprise Leadership Workshop
It is a serious course, for serious people who understand the potential challenges, impact and competitive benefits of a lean agile transformation at enterprise scale. If this is potentially of interest to your enterprise, ping me.
Most of my workshops are delivered at a client’s site. However, I do have two public workshops scheduled in Sydney (February 21-22) and Melbourne (Feb 28-29) in February 2012. You can register for these workshops through Agile University here:
I just noticed that a recorded copy of my live Agile 2009 presentation is posted on line at http://www.infoq.com/presentations/scaling-best-practices. It’s my basic scaling software agility overview (not that scaling itself is basic, however) and it may add some depth and additional commentary to some of the content on this blog.
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.
As the title indicates, in the last two posts (Part 1 and Part 2 – and also be sure and check the comments from others) I’ve described the conundrum of organizing agile teams at scale, and said I’d provide some additional input from others along with some recommendations.
Given the advantages and disadvantages to each approach – essentially the balance of immediate-value-delivery vs. architectural focus and potential for reuse, the agile enterprise clearly leans towards the feature team approach, as there can be no question on the immediate value delivery velocity benefits and the focus of the teams.
However, as we’ll see below, the answer is not that simple, and it’s likely that a more balanced approach may be required.
Mike Cottmeyer opined:
” Our first really important decision when thinking about how to scale agile is determining if the feature team approach will work or if we should consider a component team model. Feature teams are THE starting place for agile organizations. They are loosely coupled and highly cohesive and their inherent independence from the rest of the organization makes product development significantly faster and easier to forecast.
That said… many organizations are dealing with issues that make the feature team approach difficult to implement at scale. These companies are developing products that are actually systems of systems. Integrating disparate systems… disparate technologies… disparate build environments… disparate locations… disparate cultures… and disparate organizational politics into a single integrated feature team is not always advisable for even a moderately sized development shop. For these organizations… the component team model represents a viable scaling alternative.
Yes, there are increased coordination costs associated with running large projects through component teams. Hopefully those costs are offset by the value of multiple products leveraging those commonly shared components. Many organization will have to take a hard look at the feature team approach and examine at what scale the feature team approach will break down… because at some scale they WILL break down. “
Even in light of this advice, we must also recognize that features and components are both abstractions and the line is not so clear. One person’s feature may be another’s component.
For example, TradeStation Securities builds an on-line trading system where “charting market data” is a key capability for the trader. A few collocated agile teams work together on the charting function. They are some of the world’s foremost experts in charting real time data of this type. On the surface, that looks like an excellent example of a feature team, as charting certainly is a major feature of the system.
However, when new online trading capabilities are developed, such as “trading foreign exchange currencies (Forex),” new chart functionality must be added. However, driving this new chart functionality are major components such as streaming data, account management and interfaces with Forex exchanges. Is the new feature value stream described as “trading Forex all the way through the specialty chart function?” If so, that would make an obvious vertical feature stream and the teams might reorganize by taking some members of each component team and create a new vertical feature team for Forex trading.
Or, is the feature “trading of Forex” plus “charting Forex”, in which case the charting team is already organized appropriately? Is the charting capability a feature set or a component? Both? Does it matter what you call it?
Even in the case where it is clear what you call it, is a feature team always the best choice? Keith Black, VP of TradeStation Technologies, notes:
“When we first interviewed Scrum coaches their view of Agile was solely focused on feature teams, this threatened to kill the initiative. Online trading requires a great depth of expertise and industry knowledge at many different levels. We could not reasonably form feature teams that included members from every component area. For one we’d have to increase our staff, and secondly the feature teams would be too large if they covered every facet of the trading process end to end.
Therefore, for our transition to Agile we organized around component teams and through maturity we are now in special cases putting together feature teams where it makes sense. This works for us because feature teams are excellent at driving an initiative through completion.
However, in some cases they still don’t make sense. For example, if you have twenty feature teams and they all rely on a common component, such as a time-critical online transactional processing engine, it may be inadvisable to have 20 different teams sticking their hands into this critical component. Rather, you might choose to have these changes controlled by a single Agile component team that can broker the needs of the 20 teams and make sure they don’t step on each other’s toes, or jeopardize areas they don’t understand by making changes for their particular features.”
In the larger enterprise where there are many teams and many, many features, and systems that are in turn composed of system, the answer will likely be a mix of feature teams and component teams. Indeed, even in the modest-sized agile shop, a mix is likely to be appropriate. Ryan Martens, founder and CTO of Rally Software (as agile as an organization as any that I am aware of) sketched the following, five-agile-team org chart and its “feature paths” for me:
Figure 1: Five-team agile organization with various feature paths noted.
Ryan went on to note:
“While we don’t think of it in these terms as such, three of these teams (ALM1, ALM2 and PPM in the top) would be readily identifiable as feature teams. One, (Infrastructure and Ops, on the bottom)” is clearly a component team. I don’t know what you’d call the one (Platform and Integration) in the middle, because it sometimes originates it’s own features, and sometimes is simply a supportive component for other features.”
He concluded with some sound advice:
“What I would recommend is that you don’t get too hung up on the labels and the organization at the start. We think of maturity in stages: Flow, Pull and Innovate. In Flow, it’s about getting organized into agile teams and getting the value stream flowing in an agile manner. For Pull, its about leaning the work in process and having backlog maturity so that teams can pull from the backlog and implement in an order that makes the most technical and value sense. In Pull, I’d think a feature team could be a logical evolution for many. However, it’s getting started in Flow that is most critical and hardest step, and if you have to reorganize the enterprise before you begin, you may never begin at all.”
Based on all this input and well-articulated arguments from both sides of the feature teams vs. component teams debate, what is my recommendation?
Interestingly enough, at real scale (think 30-40-50 teams), features are such spanning items, that this whole argument can become almost silly, and those cases, a broader “program based” (groups of teams collaborating) organization model (not unlike the charting teams feature/component pod above) must be considered.
But in the more typical, modest size enterprise or business unit (5-10 teams), my recommendation is to apply feature teams wherever practical, but to optimize neither for features nor components per se, but to optimize around collocation. Pick feature teams if they are already collocated. Pick component teams if they are already collocated. The communication, team dynamics, continuous integration support, and velocity benefits of collocation are likely to far exceed the benefits of the perfect theoretical organization, especially when the benefits of one approach vs. the other are not always so clear, as the various opinions indicate.
As your agile organization matures, you’ll be so competitive that you’ll have lots of opportunity to inspect and adapt your model and evolve your organization in a way that makes sense to you. But in the meantime, maybe nobody will have to move!
Scaling Software Agility 