Updated Big Picture Graphic

The Big Picture has evolved quite a bit over course of the Big Picture Series. Here’s the latest tip revision of the graphic. Refer to the series itself for elaborations.

5/09 Update: Added Portfolio Managers.

Changed “Release (PSI)” to “Release Increment” to better reflect the intent. No one understood what a PSI (Potentially Shippable Increment) was, and it doesn’t exactly roll off the tongue.). Also, some are using the word “Train” (as in Agile Release Train) for this milestone, because the connotation of the word “Release” is overloaded and can cause unnecessary palpitations. (as in “You’ve got to be kidding, we can’t release a product every bla bla bla”). I’ve been thinking about the term “Releasable Increment” for this event also.

Big Picture (Updated 5/09)

Big Picture (Updated 5/09)

Agile Enterprise Requirements Information Model – Subset for Agile Project Teams

In a recent post, A Lean, Scalable Requirements Information Model for the Agile Enterprise, we introduced the requirements information model that underlies the requirements-related elements of the Big Picture series. While presenting the model in UML form may seem a bit of a geek fest, it’s the best way to describe the model in relatively unambiguous terms. In a follow on post, we described What’s Lean and Scalable about the Model and promised to later describe the model from the perspective of Agile Project Teams, Agile Programs and the Agile Enterprise. In this post, we’ll describe the model as it applies to Agile Project Teams.

But first, here’s a look at the requirements meta-model.


Agile Requirements Information Model

The Model Subset for Agile Teams

In the Big Picture series, the Agile Project Team (Agile Team for short) is highlighted below:


Agile Teams in the Big Picture

The critical role of the Agile Team itself within the agile enterprise has already been described in this post.

In accordance with the lean and scalable principles from the last post, it is a) the simplest thing that could possibly support the needs of all stakeholders and b)  particularly sensitive to the needs of the team members, in that the Agile Team is concerned with only a small subset of the requirements model. Moreover, that subset is quintessentially agile in that the artifacts described are consistent with most agile training (at least Scrum and XP) as well as common practice. (In other words, it isn’t mucked up with administrative overhead, manual traceability, reporting, detailed requirements-cram down, or any of the other ways enterprises can unnecessarily burden the teams!).

The elements of the model that the teams base their work on are extracted from the model and illustrated below:


Since most of the work (90-95%) involved with delivering enterprise software in an agile manner is done by these teams, using only these simple artifacts and relationships, it’s worth the effort to define these items and relationships more explicitly. We’ll do that in the following sections.

Backlog Item

First, we note that Story, pictured in the center, is a “kind of” Backlog Item. (The triangle indicator connecting Story to Backlog item is the UML generalization relationship, indicating that the thing the arrow points to is a generalization of the special case of the pointing thing. In other words, in this case, Story is a special kind of Backlog Item. This also implies that there are other kinds of backlog items as well).

The term Backlog was first introduced by Scrum where it was described as Product Backlog. In our enterprise model, Product can be a pretty nebulous thing as teams may be working on APIs, subsystems or whatever so there are multiple types of backlogs in the Big Picture. Therefore, our use of the term Backlog is more generalized than in Scrum. In the Big Picture, we described the particular backlog we are talking about here as the Iteration (Story) Backlog as can be seen below.


This Backlog is the one and only, definitive, source of work for the team. In this case, this particular Backlog (Iteration (Story) Backlog) holds all the work items (represented as Stories) that the team has identified. It is local to them. It is their repository for all identified work items and the contents are typically of little concern to others in the enterprise. This is a workflow “separation of concerns” which provides the team with a local work sandbox. They manage it, tool it and put things in and out of it as it suits their needs in meeting their iteration objectives. If “a thing to do” is in there, it is likely to happen. If it isn’t, then it won’t.

Note: Within the team, maintenance and prioritization of the Backlog is the responsibility of the Product Owner, who in turn is a full (or maybe half) time resident of the Agile Team. The role of the Product Owner in developing, prioritizing and maintaining the backlog is outside the scope of this post. For more on that role, see posts in the Product Owner and Big Picture 3: Role of the Product Owner category.


The team’s Iteration (Story) Backlog consists of all the work items the team has identified. In the meta-model, we call these work items Stories because that’s what most agile teams call them. (Strictly speaking, “work items” is probably a better term, but we aren’t trying to fight agile gravity with this meta-model!) So for our purposes, we’ll define Story simply as

A Story is a work item contained in the team’s iteration backlog.

User Stories

While that definition is simple, it belies the underlying strength of agile in that it is the User Story that delivers all the value to the user in the agile model. Indeed, the user story is inseparable from agile’s goal of insane focus on value delivery. In the meta-model so far, the User Story is not explicitly called out, but rather is implied (as a shorthand) by the Story class.

To make the User Story explicit, we need to extend the simple model a little as seen below:


With this small addition, we now see that the backlog is composed (primarily) of User Stories and anything that isn’t a User Story is an Other
Work Item. Other Work Items include things like refactors, defects, support and maintenance, infrastructure and team overhead. We’ll discuss the rationale for calling out these Other Work Items specifically later, but for now they appear primarily to help the team’s better estimate the time they actually have to deliver User Stories.

I’ve described the User Story briefly in the post Enterprise Agility–The Big Picture (5): User Stories and the Iteration Backlog, but since this key construct does most of the work in the agile model, it’s worth investing some more words here.

User Story Basics

User Stories are the agile replacement for what has been traditionally expressed as software requirements statements or Use Cases and they are the true workhorse of agile development. Developed initially within the constructs of Extreme Programming, they are now endemic to agile development in general and are taught in most Certified Scrum classes as well. In our model, we’ll define a User Story as:

A User Story is a brief statement of intent which describes something the system needs to do for the user.

As commonly taught (at least in the last few CSM Scrum courses I have seen), the user story takes a canonical (standard) form of:

As a <role> I can <activity> so that <business value>

(Note: While searching for the origin of this nifty form, I received the following email from Mike Cohn ” It started with a team at Connextra in London in 2003 and was mentioned at XP2003. I started using it then and wrote about it in my user stories book that came out in 2004″.  Thanks, Mike.)

In this form, User Stories can be seen to incorporate both elements of the problem space (the business value delivered) and the solution space (the activity that the user does with the system). For example: “As a Salesperson, (<role>) I want to paginate my leads when I send mass emails (<what I do with the system>) so that I can quickly select a large number of leads (<business value I receive)”.

LOTS has been written on applying User Stories in agile development. The good news is that it is now so common that I don’t have to elaborate further here, as that is not the intent of this post nor the meta-model. For that, I refer you to the many books on Extreme Programming and User Stories.

Acceptance Test

Ron Jeffries, one of the creators of XP, described what has become my favorite way to think about User Stories. He used the neat alliteration, Card, Conversation and Confirmation to describe the three elements of a User Story. Where:

  • Card represents the 2-3 sentences used to describe the intent of the story.

Note: In XP and agile, stories are often written manually on physical index cards. More typically in the enterprise, the “card” elements is captured as text and attachments in agile project management tooling, but teams often still use cards for early planning and brainstorming.

  • Conversation represents fleshing out the details of the intent of the card in a conversation with the customer or product owner. In other words, the card also represents a “promise for a conversation” about the intent.
  • Confirmation represents the Acceptance tests which will confirm the story has been implemented correctly.

With this simple alliteration and XPs zealousness for “all code is tested code” we have an object lesson in how quality is achieved during, rather than after, actual code development.

Relative to our model, however, we have represented the Acceptance Test as an artifact distinct from the (User) Story itself as seen below:


There are many reasons why we did this, which I won’t belabor here, but in any case the model is explicit in its insistence on the relationship between the Story and Acceptance Test as follows:

  • In the 1 to many (1..) relationship – every story has one (or more) Acceptance Tests.
  • Done when passes. A story cannot be considered complete until it has passed the Acceptance Test(s).

In this manner, the model explicitly supports the agile “all code is tested code” quality mantra. Every User Story has at least one Acceptance Test which must be passed before the Story can be considered to be done. Very direct. Very explicit. Very cool.


And finally, we find our way to the Task model element:


As you can now infer from the graphic, stories are implemented by Tasks. Tasks are the lowest granularity in the model and represent specific work items to be performed by specific team members to accomplish the story. In our context the definition of a Task is:

A Task is a small work item, either stand alone, or necessary for the completion of a Story

Tasks have an owner (the person who is going to do the task) and are estimated in hours. The burn down of task hours represents one form of iteration status. As implied by the 1-to-many relationship expressed in the model, there is often more than one task necessary to deliver even a small story. For example:


In other cases, it’s common to see a mini-lifecycle coded into the Tasks of a Story. For example:

Story 51 – Select photo for upload
Task 51.1 – Define acceptance test     Juha, Dean, Bill
Task 51.2 – Code story                            Juha
Task 51.3 – Code acceptance test       Bill
Task 51.4 – Get it to pass                        Juha and Bill
Task 51.5 – Document in user help    Cindy

In most cases, Tasks are “children” to their associated Story. However, for simplicity, our model also supports stand alone Tasks. With this construct, a team need not create a Story simply to parent such an item as “order 8 Gig more memory for the new file server”.

Well, that’s it for our description of the meta-model as intended to be used by Agile Project Teams. In an upcoming post, we’ll look a little higher in both the Agile Requirements Information Model and the subject organization and describe how to apply the model to Agile Programs.

A Lean, Scalable Requirements Information Model for the Agile Enterprise

For those of you who have been following the Big Picture series, you may have noted that one element of the picture is the “requirements information model” that flows down the right side. This element of the model describes agile terms for expressing system behaviors at various levels of abstraction. (See below).

Big Picture with requirements model highlighted

The Big Picture, Highlighting the Requirements Model

In summary form, the model implies the following requirements-related elements and relationships as illustrated below.


For Big Picture purposes, this is an adequate explanation which helps the enterprise to understand the new labels for “requirement like things” in enterprise agile methods and the way teams use these new things to describe intended system behavior.

However, while the Big Picture supports “hand waving” descriptions of this complex problem, it does not define the exact nature of each element nor the critical relationships between them. For this purpose, my colleague, Juha-Markus Aalto, Director of Operational Development for Nokia S60 Software Unit, and I have been working on a semantic meta-model for agile enterprise requirements information management. The model also serves as the technical underpinnings for the requirements elements of the Big Picture. The need for the more definitive model is driven by two factors:

  1. The need for clear definition of each artifact type, so teams can be coached as how to use the appropriate element (ex: feature, user story, task) at the appropriate time
  2. The need to make explicit the relationships amongst the elements of the model (user stories, acceptance tests, features, etc.) to support tooling automation, which will provide enterprise- level support for status reporting and portfolio estimating and planning.

Last week, Juha-Markus presented this model at Object Days at the Tampere, Finland, University of Technology. His full presentation can be found here.

Lessons Learned at (truly) Enterprise Scale Agile Adoption

The purpose of Juha-Markus presentation was not the model itself; rather it was to describe how this model supports the enterprise level agile practices being deployed in the development of Nokia’s S60 Software Platform and Applications. Nokia’s S60 Platform is a software platform for mobile phones that is currently amongst the leading smart phone platforms in the world. The Platform is built by an extensive network of software teams who are applying Scrum to increase the productivity and quality of their local efforts. S60 in turn, is built on top of the Symbian OS, further coupling the efforts of the Nokia development teams to the many software practitioners of this critical supplier. Nokia S60 teams’ experiences in scaling agile across a large number of intensively collaborative software teams represents some of the most advanced agile thinking and practices, at the greatest scale, of any that I am aware of.

These experiences serve as an excellent object lesson for others in (really) Scaling Software Agility. For more on this topic, I refer you to Juha-Markus’ presentation which will provide a fuller understanding of some of the challenges the S60 teams are addressing with their new agile model.

The Requirements Information Model

The purpose of this post, however, is to introduce the requirements information model that we have been collaborating on. The most basic form of this model (more in future posts), as represented in UML form, is shown below.

A Lean, Scalable Requirements Information Model

A Lean, Scalable Requirements Information Model

When compared to the Big Picture, it’s obvious that the Big Picture graphic is an oversimplification of the reality of large scale, agile system development. While the elements of Epic, Feature, Story, Task and Backlog are described in the Big Picture and elaborated in supportive posts, the elements of Strategic Product Theme and Acceptance Test have not. These are described below:

  • Strategic Product Theme – this information model adds this, new and highest level element to the information hierarchy. Themes provide a well-defined set of core value propositions that in turn, drive portfolio investment. They define the key strengths of the enterprise, deliver on strategic initiatives and solutions, and drive long-term competitiveness. Themes, in turn cause the creation of Epics, Features, and Stories that deliver on the themes value proposition. (In the Big Picture, Themes can be considered to be the various “slices” in the portfolio management pie chart at the upper left)
  • Acceptance Test – moving all the way to the bottom of the stack, the model also highlights the critical role of the acceptance test in agile development. In turn, this encapsulates two key agile quality principles: 1) there is always at least one acceptance test for every story (in agile, all code is tested code) and b) a Story cannot be considered “done” until it passes the test.

Lastly, the Non-Functional Requirement is a primary element in this model, which reflects the role these special requirements play in the development of enterprise class systems. (These were called out as auxiliary elements of the “Vision + in the Big Picture.)


That summarizes the primary elements of the lean, scalable, requirements information model. To the new or smaller team Agilist, this model may seem relatively complex and perhaps not very agile, or at least not “the simplest thing that can possibly work”. However, experience has shown that thinking about the solution space in these varying levels of abstraction is in fact, a simplification of the problem at enterprise scale and encourages agile thinking throughout the organizational hierarchy. I’ll describe why in an upcoming post.

Enterprise Agility – The Big Picture (14b): More on Agile Portfolio Management and the Legacy Mindset

Note: This is part of a continuing series (see the Big Picture Category on this blog) wherein we introduced an overview graphic intended to capture the essence of enterprise agility in a single slide. In a series of continuing posts, we have been working our way from the bottom (stories, iterations and the like) to the top where the enterprise vision and portfolio management resides. This post is one in a miniseries describing the last big icon on the upper left – Agile Portfolio Management.

The Big Picture - Agile Portfolio Management

The Big Picture - Agile Portfolio Management

In the last Big Picture Post, we introduced the portfolio, along with the challenges that agile teams are likely to find as the impact of their new and more productive models wends its way to the Project Management Office (PMO), which in some cases can be the “mother ship of potential agile impediments.” We also introduced the excellent DTE energy case study: Establishing an Agile Portfolio to Align IT Investments with Business Needs. This case study is an example of how an agile enterprise can first recognize, and then successfully address the significant changes necessary to allow the emergence of true enterprise agility benefits.

Since that post, I’ve been thinking that I would expound on the legacy mindsets that called out in the case study. But I’ve decided I can’t. They are just too well done and so symptomatic that I decided just to repeat them here. However, the accompanying descriptions and paraphrasing are my own. These are based on my own experience from two perspectives; 1) then, as an executive, managing portfolios and carrying some elements of these mindsets, and 2) now, as an agile executive attempting to change those very same mindsets!

The legacy mindsets called out in the DTC case study are:

  • Widget engineering – The belief that software development is a repetitive, controlled and manufacturing-like business, rather than Research and Development. “Draw it up and build it like you drew it,” goes the thinking.
  • Order Taker Mentality – Also known as “build what we tell you to build”. Founded on the belief that the customer is always right, seemingly all-knowing and under the assumption that they actually know what their requirements really are. The teams should just build it.
  • Maximize utilization- The belief that if all resources aren’t fully utilized on paper then they won’t be fully utilized in practice. “They’ll just be idlers, wasting their time, waiting for their next assignment.” goes the thinking. “Fully assign them or lose them”.
  • Control through data – The belief that
    with the right kind of data – earned value metrics, design reviews, requirements and test plan inspections – we can tell where we are on the project. And then if we still can’t tell where we are, we’ll just ask for more detailed data until we can.
  • And we can plan out a full year of projects- Conveniently disregarding our last 20 years or so of experience in failing to predict projects a year in advance, we assume it’s a failure of our planning, not a failure of the basic paradigm. “If we only planned in more detail, we could really get it right this year.”
  • Get it Done – The belief that our best case plans can be reality if we only try hard enough.
    Also known as: “That was the plan we agreed to, now execute it.” And “when the going gets tough, the tough get going”. And lastly, the infamous “we know it’s impossible, that’s why we hired you for this job.”

Perhaps it’s obvious from my elaborations that I tend to get somewhat passionate about this topic. Perhaps it’s because my guilt shows through. Surely, I have been on the other side of this fence before iterative and incremental, and now agile, development methods proved their extraordinary worth. So, I know as well as any that if these legacy mindsets are not addressed, they will kill the agile enterprise initiative as surely as a fixed content/fixed schedule 60 hr/week death march.

Here’s why. The table below shows the manifestation of these problems in practice (as described by DTE along with a few of my own) and the real problems they create for the nascent agile teams.

Mindset Manifestation Problems
“widget engineering”
Fixed schedule, functionality planning

Big Up Front Design/Analysis (BUFD)

Long range plans

Resources fully committed up to a year in advance

Analysis paralysis

“order taker mentality” Build what we tell you to build

We are the boss of you

False agreements. No buy in.

Misses innovation contribution from teams

Failure to meet expectations


No empowerment, lower motivation

“Maximize utilization” Resources committed long range

100% allocation before “what if”

Key resources assigned to multiple projects

No time to think or innovate

Dedicate resources to task or lose resources

Thrashing – lost productivity of most valuable resources

Exhaustion, burnout

“we can plan out a full year of projects” Detailed wbs, earned value metrics, fully loaded Gantt charts Plans are immediately obsolete, but not treated that way

Earned value metrics don’t reflect actual progress

“Control through data” Fine grain reporting and overhead

Milestones that are not reflective of process or progress

Reporting overhead slows actual development

Annoys and de-motivates the teams

“Get it done” Belief that best case plans must succeed Deferred recognition of plan vs. actual

Late discovery and re-negotiation

Loss of credibility, mistrust

You’ll probably recognize many of these mindsets, manifestations and the problems they create for the development teams. Many enterprises do. In one recent presentation I made highlighting the DTE case study, one PMO executive said “just delete DTE and put in [our company name here] and there you have it”!

Well enough crabbing and I’m sorry if I offended anybody. I just thought it important to walk through this pain field one last time, making sure we understand the problem so that the imperative for a solution is really, really apparent.

In the next post in this series, I promise to move to a more productive and proactive set of ideas to address these problems. One giant step further to actually becoming the agile enterprise.

Enterprise Agility – The Big Picture (14a): On Agile Portfolio Management and the Legacy Mindset

Note: In the post Enterprise Agility: The Big Picture, we introduced an overview graphic intended to capture the essence of enterprise agility in a single slide. In a series of continuing post (see the Big Picture Category on this blog ) we have been working our way from the bottom (stories, iterations and the like) to the top where the enterprise vision and portfolio management resides. In this post, we’ll start a miniseries to describe the last big icon to the left – Agile Portfolio Management.


The Big Picture 14 - Agile Portfolio

A Particularly Relevant Case Study

Recently, while researching this topic for another purpose, I ran across an excellent case study from DTE Energy called: Establishing an Agile Portfolio to Align IT Investments with Business Needs. The article was written by Joseph Thomas and Stephen Baker and presented at Agile 2008. Unfortunately, I did not attend this presentation while I was at Agile 2008, but I found the whitepaper published in the proceedings. It appears to be available at http://submissions.agile2008.org/files/CD-ThomasBaker-EstablishAgilePortfolio-Paper.pdf and I highly recommend it for those readers of this blog that have
product or asset portfolios
(and you know who you are).

Here was the introductory “grabber” for me:

“Those who implement agile software development and agile project management in a traditional corporate environment may encounter legacy corporate and IT processes that reflect legacy mindsets and cultures- These remnant processes, mindsets, and cultures represent opportunities to improve the systemic value that agile approaches are capable of enabling.”

This is a reminder that team agility does not automatically engender enterprise agility and in most all cases, the team is just the beginning. The article is surely relevant to the enterprise perspective, because when it comes to scale, DTE Energy is right “up there”:

“DTE Energy, a Fortune 300 is a diversified energy company involved in the development and management of energy related businesses and services nationwide with $9 billion in annual revenue and 11,000 employees. DTE Energy’s Information Technology Services (ITS) organization, now consisting of over 900 people, provides leadership, oversight, delivery, and support on all aspects of information technology (IT) across the enterprise.”

Illustrating the maturity of thought reflected in the article, DTE Energy’s IT teams have been implementing and extending agile practices in their enterprise since 1998, moving through CMM levels II and III via agile practices. They have almost a decade of agile adoption upon which to build their ongoing learning. As reflected in the case study, DTE also illustrates Kaizen Thinking (continuous thirst for improvement) that is the hallmark of top enterprise agilists. Evidently it is just this thirst that drives the agile initiative ever upward until it hits the level of portfolio planning and decision making at DTE.

The Transformation Starts on the Ground

The title of the article, along with the maturity of DTE’s agile implementation efforts, also reflects the fact that building the agile enterprise is a “ground up” exercise. The primary work must start with the development teams themselves. They build all the code. If they aren’t agile, no one is. Thereafter, dealing with many of the challenges at the corporate level, (with the Project Management Office (PMO) often being the control room of the mother ship) is likely to be a significant challenge that must be addressed. For it is there that projects and programs are initially formed, budgets and resources are determined, governance is established and longer term (and not particularly agile) external commitments are typically made. If not successfully transformed, many of the potential benefits of the agile enterprise – time to market, productivity and quality, ROI, revenue and profitability growth – may be heavily mitigated.

However, this next set of enterprise challenges is most easily addressed after the teams have first demonstrated  the substantive productivity and quality improvements of the methods. That way, they’ll be standing on their accomplishments and can serve as an object lesson in what agile could do, if only unfettered.

But for readers of this blog series now is a later time and it’s time we addressed the big “portfolio” icon on the top left of the Big Picture

Legacy Mindsets Can Hinder Potential Enterprise Benefits

DTE’s whitepaper starts with a discussion of the various legacy mindsets that can inhibit achievement of the full benefits of the agile enterprise. These include: “widget engineering”, “control through data”, “order taker mentality” and more. This is an important underpinning for the enterprise transformation we are driving, because one can’t recognize solutions to a problem if one does not understand the problem. These mindsets must be understood and addressed before much agile progress can be made at the portfolio level.

We’ll discuss these legacy mindsets, and more from our own experiences, in the next post.

Enterprise Agility-The Big Picture (12): Architectural Runway

Note: In the post Enterprise Agility: The Big Picture, we introduced an overview graphic intended to capture the essence of enterprise agility in a single slide. In prior posts, we’ve discussed Agile Development Teams, Agile System Teams, Iterations , Agile Product Owner, Backlog, User Stories and the Iteration Backlog , Release , Vision and Release Backlog , The Roadmap, Agile Product Manager, and the Release Management Team. In this post we’ll describe Architecture Runway [callout 12] below.


Big Picture 12-Architectural Runway

For any familiar with this blog or my book (Chapter16 of SSA – Intentional Architecture), the topic of agile, intentional architecture is not a new topic. The blog series on this topic is here. A whitepaper in this topic, Principles of Agile Architecture: Intentional Architecture in Enterprise-Class Systems, coauthored by myself, Ryan martens and Mauricio Zamora can be found here. Also, I recently presented a Rally webinar on this topic and you can see that webinar here.

In Scaling Software Agility, I defined architectural runway as:

A system that has architectural runway contains existing or planned infrastructure sufficient to allow incorporation of current and near term anticipated requirements without excessive refactoring.

Continuous build out and maintenance of new architectural runway is the responsibility of all mature agile teams. Failing to do so will call cause one of two things to happen, either of which is very bad:

  1. Release dates will be missed as large scale, just-in-time, in-situ infrastructure refactoring adds substantial risk to scheduling
  2. Failure to address the problem systemically means that the teams will eventually run out of runway. New features cannot be added and the system becomes so brittle and unstable that it has to be rewritten from the ground up.

Architecture in the Big Picture

With respect to the Big Picture, Intentional Architecture appears as a “red thread” through various levels of the hierarchy.

  • Level 3 – At Level 3, Architectural Runway is represented by Infrastructure initiatives that have the same level of importance as the larger scale requirements epics that drive the company’s vision forward. While many architectural initiatives will be addressed routinely by the teams over time, others require elevation to the portfolio level to assure awareness and communication of these important initiatives. They will consume substantive resources and failing to implement them will compromise the company’s position in the market. They must be visible, estimated and planned just like any other epic.
  • Level 2 – At Level 2, Product Managers, System Teams and other stakeholders translate the architectural epics into features that are relevant to each release. They are prioritized, estimated and resourced like any other feature. At each release boundary, each architectural initiative must also be conceptually complete, so as to not compromise the new release, though it may or may not surface itself to the user.
  • Level 1- At level 1, refactors, design spikes, evaluations etc. that are necessary to extend the runway are simply a type of story that is prioritized like any other story. Architectural work is visible, accountable and demonstrable at every iteration boundary. This is accomplished by agreement and collaboration with the system architects (Level 2) and agile team and tech leads (Level 1) who determine what spikes need to happen when, and who work with the Product Owner to prioritize the iteration backlog. (see picture below).

    Architecture is a role collaboration

    Architecture is a role collaboration

In this manner, architecture is a first class citizen of the Big Picture and is a routine portfolio investment consideration for the Agile Enterprise.

In the next Post, we’ll elaborate on the Agile Portfolio Vision.

Enterprise Agility-The Big Picture (10): The System Team

Note: This is the next in a continuing series of posts in the Agile Enterprise Big Picture series, whereby I’m attempting to capture the essence of enterprise agility in a single slide.

I noted the recent addition of the System Team to the Big Picture in my last blog post. While this would have been best explained back near the beginning when I described the agile development teams, we turn to it now for completeness of that thread. In this post, we’ll describe System Teams in the context of the Big Picture.


The Big Picture 10-System Teams

As we described in an early post, Agile Teams are the development/software production engine that creates the code. These are the Define/Build/Test teams of Chapter 9 of SSA and each has the requisite skills necessary to specify, design, code and test their component or feature of the solution.

I am reminded, however, that at the enterprise level these teams alone are unlikely to have all the capabilities or authorities needed to deliver the solution and there is typically one or more System Teams that complement the feature/component teams. These teams work on the same release train cadence as the agile development teams and they share the same mission. In practice, these System Teams typically have responsibilities including:

System-Level Continuous Integration

The larger the system, the less likely it is that the teams and their existing build and CM infrastructure environments can pull ALL aspects of the solution into place on their own. For example, one large scale system consists of four components: a thick Windows desktop client, a server, a separate server that provides interfaces and support to financial exchanges and lastly, a parallel web client/server application set. Each of these system components is built on somewhat differing underlying technologies and it is no small feat to pull these pieces together and run full system validation on a daily basis. So there is a separate system team (integration team in this case) dedicated to this purpose and they are integral to the process. The System Team leaders participate in the daily integration Scrums and also provide a central coordinating point for system level information.

System Quality Assurance

The same analogy applies to system level quality assurance. Running a full validation suite on the system described above takes a small but dedicated team who constantly updates the full system verification and test platforms, runs the validation and assures system level quality such as performance and reliability and conformance to industry compliance standards. In addition, that team can assume the responsibility for testing against the “matrix of death”, which is the umpteen odd variants that occur in the customers supported platform and application environments.

In addition to these common functions, I have seen System Teams take on two other functions as well:

Building Architectural Runway in Greenfield Applications

Building a new application in an agile manner still depends upon early build out of the architectural infrastructure. In some cases, this must be done before even a single feature can be laid in to provide user value. I described this in SSA with the following graphic.

System Team Building Architecture in Early Iterations

In the agile project kick-start mode illustrated here, the first team builds the initial platform, (maintenance and ongoing development of which will eventually assumed by other teams) before the feature teams are added to the project. This can also facilitate a natural transition of resources to the new project as old projects are completed or new hires can be added to the new project over time.

Building Development Infrastructure for the Project

The transition to agile methods typically involves a significant investment in the environment to support configuration management, automated builds and deployment and automated build verification tests for an existing or greenfield project. This may involve analysis, procurement of tools and systems, deployment, scripting, ongoing maintenance etc. This is a complicated and technical task that takes time and typically, dedicated software development-capable resources. Building an initial infrastructure team that is integral to the system release train is one way to assure the commitment, visibility and accountability of those resources. More importantly, it helps assure that the job will actually get done, because the entire release train is dependent upon its success.


This post summarizes my view of the role of System Teams in the Big Picture. Of course, there is no one right way to do any of this and so comments are always very welcome.

In the next post, I’ll continue to discuss the organizational model of the Big Picture, when I describe the role of the Release Management Team.

Agile Enterprise Big Picture Revised, (again!)

For those following the Big Picture series on the blog, you’ve probably already noted that the Big Picture and elaborations have been evolving over time. I supposed it would have been nice to “get it right the first time” but in fact, that wasn’t possible, for without publishing and feedback, there can be no “right”. So I publish and refactor and publish and refactor and publish and refactor. In the meantime, readers have had the benefit of any value I’ve been able to deliver in the meantime.

After all, this is the Agile Enterprise Big Picture we are trying to describe!

In any case, based on reviewers and previewers comments, I’ve come to the conclusion that I was missing one more element that was necessary to describe how the enterprise model works. This element is the “system team”, a team which runs iterations on the same cadence and release train as the agile development teams and carries system level integration and evaluation responsibilities. I did describe it in the book, but I hadn’t included here for fear of overloading the graphic. I’ve now included it:


Big Picture Revised (Again!) Jan 2009

and I’ll describe it in the next post.

I’m also going to insert this revised graphic back on the first introductory post, in case any future readers start there. But I’m not going to bother to redo Posts 2-9, because that isn’t the “simplest thing that can possibly work”.