Note: This is the first post (AERP-1) in a series on Agile Enterprise Release Planning which I hope to continue over the next few weeks. They’ll be labeled AERP1-n, so you can eventually read them in sequence, front to back, if you like.
From the last post, Yes, Enterprise Agility is Hard, I noted:
“I’ve also come to the conclusion that effective Release Planning (agile, synchronized, multi-level release planning that is) is one of the critical keys to understand and implement agility effectively at enterprise scale. While I covered it somewhat in Chapter 12 – Smaller, More Frequent Releases and in Chapter 18, Systems of Systems and the Agile Release Train, I didn’t emphasize it as a significant and somewhat stand-alone enterprise practice that I now see it to be. To address this shortcoming, I’m writing an article on release planning from the inside out, i.e. an experiential, day-in-the-life emulation of a team lead experiencing an enterprise release planning session. This article should be published in the March 12 edition of the Agile Journal, Sharing Agile Successes. In addition, I intend to describe it more succinctly in some upcoming posts this week.”
When transitioning an enterprise to agile, I don’t generally start with the larger enterprise practices (Part III of the book), rather we (meaning me and a number of other coaches I know) typically start teams in what I call “heads-down-iterating” mode. Getting started with agile is difficult enough that first things must come first, and first, development teams must master, or at least have experienced, the basic project management and engineering practices of software agility. Forget the long term objectives for now, focus on what you can deliver and how you go about doing it in an agile, incremental, and quality-embedded way. After all, you can’t build an agile enterprise out of non-agile teams. And you can’t build a big, high quality system out of quality deficient little bits.
To start, many coaches start out by just getting the component teams organized and starting them iterating. This requires some basic reading at a minimum, and ideally some coaching and training. It also requires some time – at least 60-90 days – just to get the basic patterns down, and as I noted in my last post, even longer to master.
In order to help the teams succeed, companies often need to ignore many of the existing process and governance practices, or at least provide a short amnesty for those teams while they experiment with the new model. After all, an agile team can’t run very fast while trying to conform to non-agile milestones like “test plan complete” or “Milestone 2’s 50 point checklist”, or “software requirement specification approved”.
This problem/state of the enterprise is also paralleled in larger companies who are starting to see agile growing from the “bottom up”. Teams are doing stand-ups, software seems to be working and available more frequently and something is definitely different afoot. But in all likelihood, the types of documents, reviews, milestones etc. the company has insisted on prior (we respectfully note that all of which were originally designed to help, not hinder teams on their quest for quality and productivity) are not being followed well, or even at all. This causes a lot of consternation in the executive ranks who are responsible for governing these activities. After all, they are ultimately responsible for the outcomes and their jobs, if not the company’s future, hangs in the balance. It’s also possible that the agile teams may have “thrown out the baby with the bathwater” (for example, a corporate governance requirement that “all components must be subjected to a threat assessment review” in order to assure newly developed software meets security requirements, cannot be safely ignored).
At about this time in the evolution of the company, the entire agile initiative is threatened and if this stage of development is not recognized and addressed, it will “die on the vine” right then and there.
Moreover, the example above is just one example of the many concerns that are appropriately raised at that time. The question naturally arises in executive offices: “If this agile thing is to work, how do we answer the types of questions that some of our original practices were designed to address? Questions such as:
- What is the vision the teams are currently working against?
(“after all, there is likely no marketing requirements document or software specification, so how do we know what they are doing. Even if we trust them, isn’t it our job to take this company in the right direction?”)
- What will we ship next and when will we ship it?
(there is not likely to be a pert char around anymore. Even worse, some agile teams might be telling management, “we’re agile now, we’re adaptable, we’re empowered, and we don’t have to tell anyone what we will ship or when”)
- What longer term architectural initiatives must be addressed across multiple teams?
(“if architecture emerges, how do we impose common infrastructures, usability guidelines, security solutions, etc”)
- How do we communicate common requirements across all teams?
(example: “Can they all decide on their own what programs get internationalized, in what languages and when? That will be chaos.”)
- How and when do the teams coordinate their interdependencies?
(“we know they should work together, but they are too big or too distributed to make that natural. Are they talking about the right things? After all, they aren’t sending us plans, documents or status reports anymore”)
- How are our resources allocated to the important, prioritized initiatives?
(“How do we know whose working on what and whether the priorities are being addressed in a way to assure ROI. We don’t see documented plans any more, so how do we know who is working on what and when”
Fortunately, these are the types of questions that Agile Enterprise Release Planning (AERP) is designed to address. And we must address them, or our initiative will likely fail. So we’ll look further at this important practice in upcoming posts.
Scaling Software Agility 