Enterprise Agility-Big Picture (5): The Release Revisited

In the post, Enterprise Agility-The Big Picture (5): The Release, we described that seminal, value delivery construct of the Agile Release. (see Big Picture below).

Agile Big Picture - Internal vs external release?

But as with all the other oversimplifications in the Big Picture, (which at times seems to create almost as many questions as answers) comments and questions have been raised about what makes a Release a Release. In the book, I described the release on the agile release train in terms of an “internal release milestone” as opposed to a GA (General Availability) release.

The reasons for this are many and for further perspective, I refer you to Chapter 18: Systems of Systems and the Agile Release Train and Chapter 21, Impact on Customers and Operations. In Chapter 21, I described at length how attempting to synchronize the team’s internal development cadence with external release milestones is an over-constrained problem. Dates and features never line up to market events; public relations has an information cycle of its own; customers do not always want to adopt your new software at the rapid pace at which it now evolves, etc. etc. (see Chapter 21).

To address this problem, I suggested that the development teams build their own engineering cadence in a manner conducive to the most efficient development operations and build a GA firewall between the internal development cycle and the distribution model. This is illustrated in the picture below:

Agile Release Train GA Firewall

This creates a separation of concerns which allows entities on both sides of the firewall to do their best work without constraining each other.

In any case, with respect to the Big Picture, however, I Indicated the Release milestone is just a Release and that has created questions from readers. From a purist perspective, the release illustrated on this picture is really an Internal Release, which may or may not be a GA Release, (though I’ve decided not to update the picture for fear that would be more confusing to the casual observer). If the internal release is not a GA Release, then the question becomes, why even have it? The answer is that the internal release model is integral and seminal to the agile enterprise model:

1. From a portfolio planning perspective, the internal release frequency is controlled by the teams to a timeframe that makes face-to-face, enterprise-level release planning feasible from a travel and cost overhead perspective. Re-planning happens at these boundaries and hopefully, only these boundaries.
2. From a technical perspective, if  for whatever reason, it is difficult to assure true system level quality at iteration boundaries, then this milestone represent an absolutely Potentially Shippable Increment at the system level and it meets all the reliability, performance, standards compliance, and compatibility that is required for a GA release. Its fast, it’s frequent, it is of high quality and it is available!
3. From a human resource perspective, teams perform best when they work together long enough to be in the flow (the performing phase of the Forming – Storming – Norming – Performing model
   of group development) and that typically takes a release cycle or two, so the release boundaries
   are the best times to adjust teams to address the current bottlenecks in value delivery. This provides teams with the stability they need for high performance, while simultaneously giving the enterprise the resource flexibility it needs to achieve agility.

Hopefully, this clarifies some of the questions and comments on the Big Picture Release.

More on Product Owner vs. Product Manager – Revenue Products need Product Managers not/and Product Owners?

As I’ve noted before, the Product Owner and Product Manager category on this blog still seems to stir the most interest amongst readers.

I just noted that the folks at enthiosys recently published the following article Revenue Products need Product Managers, not Product Owners. (The title is a tad misleading, because in point of fact and as the article points out, agile enterprise ISV’s (independent Software Vendors) generally need both). This is an excellent, summary perspective of much of what is being discussed in classes, forums and blogs as agile crosses the chasm to the enterprise. It’s a short read and pretty much on the mark. Here’s a short introduction:

“Product Managers are responsible for the overall market success of their products, not just the delivery of software. In the Agile world, a new title is emerging – the Product Owner – which covers a small subset of the product management role and can lead to role confusion. Here, we’ll explain why revenue-producing products need full-fledged Agile Product Managers.”

If your organization has, or should have, Product Owners and Product Managers, you should definitely check it out.

And for more on this topic, check out the Product Owner/Product Manager category on this blog.

–Dean

Protected: Protected Post #12

This content is password protected. To view it please enter your password below:

Password:

Protected: Private Post 11

This content is password protected. To view it please enter your password below:

Password:

Protected: Password Protected Post #11

This content is password protected. To view it please enter your password below:

Password:

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

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 (11): The Release Management Team

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 , the Agile Product Owner, Backlog, User Stories and the Iteration Backlog the Release , Vision and Release Backlog , The Roadmap, and the Agile Product Manager. In this post, we’ll discuss the role of the Release Management Team [callout 11] below.

Big Picture 11-Release Team

As can be seen in the Big Picture, in addition to the Agile Teams there is typically another significant organizational unit. There is no standard convention for its name, but it takes on a Release Management Team or Steering Committee role or function (see Chapter 12 of SSA- Smaller, More Frequent Releases for further discussion of this team).

This team exists because even though empowered, the agile teams do not necessarily have the requisite visibility, quality or release governance authority to decide when and how the solution should be delivered to the end users. That is the function of the Release Management Team which is typically composed of managers and others from Layer 2 in the Big Picture. Members of this team may include some or all of the Agile Masters, but more typically includes other representatives of the enterprise, such as:

Business Owners & Product Managers, senior line-of-business managers who focus on the overarching goals of the organization and the content and market impact of the Release. Senior representatives from sales and marketing may also attend on occasion so as to be aware of the status of the upcoming release.

Vice president or director-level managers who have line management responsibility for the teams and are typically ultimately accountable for developing the solution for the marketplace.

Senior, System-level QA personnel who are responsible for final assessment of the solution’s system-level quality, performance and suitability for intended use.

Enterprise architects, CTOs, system architects who oversee the architectural integrity of the solution and have an understanding of how the architecture needs to evolve to meet future requirements.

In many agile enterprises, this team meets weekly to address the following questions:

Do the teams still clearly understand their mission?

Do we understand what we are building?

What is the status of the current release?

What impediments must we address to facilitate progress?

Are we likely to meet the release schedule, and if not, how do we adjust scope to assure that we can meet the release dates?

This forum provides weekly senior management visibility into the release status. This team also has the requisite authority to make any scope, timing or resource adjustments necessary to help assure the release. In this manner, the Release Management Team represents the final authority on all release governance issues and is a therefore an integral part of the Agile Enterprise.

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.

Summary

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”.