Size Matters
I came across some interesting material from Rally Software Development recently which closely aligns with what I consider the most important elements of effective software development techniques. One of the things I particularly liked about the whitepaper Rally has published (Tactical Management of Agile Development: Achieving Competitive Advantage) is that it provides more visibility into the somewhat nebulous concepts of "Release Planning".
In their paper, Leffingwell and Muirhead, describe Release Planning as the exercise which occurs at the start of a project where product owners, the development and customers (or their proxies) agree on the set of scoping and scheduling activities around which each iteration should occur. They identify a lightweight process where they have abstracted several high level workflows, specifically "Define Release Objectives", "Scope Release" and "Schedule Release". This creates a Release Roadmap which they emphasize is a coarse grained release plan which is neither comprehensive nor guaranteed. This exercise could be a 2-3 week effort based on the size of the project which sits well with how I would advise an organization embracing a larger program initiative.
They also distinguish between "Schedule Driven" or "Scope Driven" projects. The former is defined as having a specific date which is required for implementation and based on this scope is adjusted based on the team's commitment to deliver and velocity observed over progressive iterations. Scope Driven identifies a list of prioritized backlog items from which a schedule is derived. The thing I like specifically about focusing on two general approaches is that there is considerable value in picking a specific metaphor at the start of the program and moving forward with that goal in mind.
Too often I have seen organizations attempt both approaches although typically this is difficult to see initially. It typically occurs when there are two or three groups with equal decision making capacity in the program. You know this is happening when you hear a group of key stakeholders agree that they want to apply a schedule driven approach but you hear one of the stakeholders add something to the effect of "After we define a solid architecture" or "Once we have a good handle on the business requirements". These statements are so nebulous and open to such wide interpretation they essentially prevent a Schedule driven approach from being applied. The architects will head off and debate Hibernate versus OJB for several weeks, the business representatives will disappear and hold lengthy all day meetings trying to agree on what business processes are currently being performed. Both of these activities might have value but they shouldn't cloak the fact that the project should be more scope driven (which by the way might include architecture validating activities not just business value activities).