In my presentation for Agile Tour 2009 in Montreal, I will explore how we can elevate Agile to the business solution level. Agile shines in software development, but should it stop there? I had the opportunity to push Agile beyond its comfort zone.

At first it involved including purchased products, or make-or-buy decisions, in the Agile development process. While doing that, I noticed that we had to separate effort from cost. Originally, work time (or effort) is the only "cost" in Agile. But when we purchase a COTS (component off the shelf) as part of the solution for example, the relationship between cost and effort becomes insufficient. I solved this by attaching to work items a cost tag that is independent from effort. With this simple extension, we elevate Agile from software development level to software solution level.

In subsequent projects, I wanted Agile to encompass the entire project. The project can for example require adjusting business processes, marketing services and products, deploying software products, training people, and yes, developing software. However, work items that do not pertain to software products require more extensions to reflect these characteristics. The demonstration of work done, for example, is not as obvious as for a product feature. The results of non-product work items are less tangible and are sometimes observable only at later iterations. A marketing work item (shown below with a Scrum-style story index card) is a good example. Part of the cost ($3000) does not depend on the effort (50 hours), and part of the demonstration of "done" will only appear in later iterations when feedback can be measured. The capability of taking any value-producing activity into account, and not only product features, brings Agile to the business solution level.

Elevating Agile beyond software development is not just about expanding existing frameworks. It's first and foremost a question of mindset. Indeed still now Agile is used, introduced, and promoted essentially by software developers, who have a bias for diving headfirst into software development and neglect looking at a broader - and better - approach to the solution. Exposing Agile developers to business will expand their view and help elevate Agile to the business solution level.

This article provides an overview of issues that arise when scaling agile projects and organisational paradigms that help solve these issues. The analysis is based on personal experience and some research (see references at the end).

To preserve agile strengths, all agree that the team size should be limited (upper limit is 8-to-12 depending on opinions). Consequently, scaling agile necessarily implies setting up a multi-team organisation.

Additional needs for multi-team agile include (but are not limited to):

• Handling cross-team impediments
• Ensuring alignment with strategic objectives
• Dividing the work among multiple teams
• Integrating the work of multiple teams in cohesive product releases
• Maintaining a common foundation of practices and tools across multiple teams
• Facilitating the emergence of a sound product-level architecture

We will explore a few organisational structures that may help cope with these extra needs. These structures are provided as a starting point and should be adjusted and combined according to the context. Rather than focusing on a specific agile framework (such as Scrum), we will use framework-neutral terminology. You can easily map these practices to your agile framework of choice.

The organisational paradigms consist essentially in setting up one or more additional teams to deal with the issues mentioned above. These additional teams are:

1. Coordination Team
2. Integration Team
3. Meta Team
4. Support Team

Next: Coordination Team

Pages: 1 · 2 · 3 · 4 · 5 · 6

I often faced the following dilemma:

• either use a process framework such as IBM RUP that might be too complex for the situation at hand and has therefore to be heavily customized,
• or set up a process framework such as Scrum that lacks practices to manage some more complex areas of the project.

If like me you often ended up in this awkward position, I suggest you seriously consider OpenUP (Open Unified Process, a lightweight, open source, agile offspring of RUP). Not only the process framework makes sense, but on top of that you can rely on the equally free Method Composer of the Eclipse Process Framework to easily tailor the process to your needs. Compared to two years ago when I first looked at OpenUP, the process framework and the tools are now mature and enjoy the support of a thriving community of people who, like me, struggled to find an agile framework that can scale.

I invite you to read this short article from Bjorn Gustafsson: OpenUP - The Best of Two Worlds.

Yesterday I had the pleasure to present at Agile Montreal User Group (AMUG). Great folks! The topic was Agile and Management, the Missing Link. The presentation was in French. For those for which it is not an obstacle, the PDF version of the PPT is available here.

Agile et Le Management

After successfully applying agile principles to software development for several years, agilists are looking to expand the scope of agile. The presentation focuses on expanding Scrum practices just enough to satisfy basic project management needs. The audience was most interested in initial planning and project status. Indeed, contrarily to what some extreme agilists think, being agile doesn't allow us to ignore these needs. The trick is to answer these questions while remaining agile, avoiding the pitfall of burying agile practices under administrative overhead.

Looking back at the last few years, I can't help but notice that agilists tend to integrate some traditional techniques as they bump into agile limitations, and similarly traditional methodologies progressively embrace agile principles to reap the benefits of agility.

For example, I am currently working on a presentation that helps agilists make the link with non agile stakeholders and management. How can a ScrumMaster answer the questions "how much will this project cost?" or "should we make or buy?" for example. Some might say that this goes beyond the purpose of agile. They are wrong. There is no valid reason to restrict agility to project execution and leave the rest to traditional approaches. Expanding agile practices to bridge these gaps is actually quite straightforward.

Note that the goal is not to agilify the whole organization, but simply to position agile at solution level, and not just at software development level.

Conversely, traditional methodologies are progressively adopting agile principles. Some, like IBM Rational Unified Process (RUP), made the turn years ago to integrate core agile practices. Others, like PMBOK, only pay lip service to Agile and even avoid using the word. Some methodologies produced agile spin-offs, like OpenUP for IBM RUP.

This is all good news for IT professionals and their clients. Indeed the combination of practices, whether traditional or agile, according to the situation at hand, is certainly more constructive than the bickering of righteous traditionalists vs. agile evangelists (yes, agilists can be narrow-minded too).

I expect the convergence of agile and traditional approaches to give rise to a new generation of practices that expand beyond software development and leverage the collaborative effect of agile organization. Actually I'm not only expecting it, but contributing to make it happen.

(I loosely use the word "methodology". It might refer to software development process, project management, organizational paradigm, or whatever stands for "the way we work" in your mind.)