Project oriented organizations focus entirely on getting a related set of intent packaged into a container called a project and seeing that entire container move through from requirements generation to software release. Release-Orientated organizations are singularly focused on continuously getting releases out the door that maximize business value delivery without being constrained to only releasing related business intent in the portfolio. To achieve the continuous release of software systems, organizations must apply lean thinking and principles to every aspect of their delivery frameworks and minimize the overhead associated with making releases with high quality. While Continuous Delivery has become a very popular destination for many software engineering and IT shops, Release Orientation goes well beyond the rapid feedback and rapid test and release cycles of Continuous Delivery. Release Orientation is focused on realizing value through regular and frequent solution releases going into production (or customers’ hands) – thereby realizing continuous value for the business. In other words – Continuous Concept to Cash.
Recent Posts
We are happy to announce that Naeem and Brian will be Keynote Speakers at Agile PA on Wednesday, May 14th, at 6 PM. Our session is called “Hop Onto the Release Orientation Trolley”. This session will first be presented at Scrum Gathering on Tuesday May 6. This session builds on concepts from our Scrum Alliance article, “The Big Lever” - so take a look!
Here is a reprint of my article originally published with Scrum Alliance in March 2014. Enjoy!
Been blazed and confused for so long it’s not true . . .
So, your Agile transformation journey has been underway for a few weeks, a few months, or maybe almost a year. You have blazed a path toward agility. But, much like the Led Zeppelin song (Dazed and Confused– please, you don’t have to be from the ’70s to get the Led out!), there is a huge pause in the middle of the journey, and now you are not really sure if you are going anywhere.
Happy to report that I took the Certified Scrum Profession (CSP) exam this morning and passed with flying colors! My biggest reason for working towards the exam was using it as a forcing function to do a whole lot of reading about a variety of agile subjects. Over the past 8-9 months, I read the following titles and added to my knowledge base using mind mapping software (I love iThoughtsHD on the iPad):
I have a new article published today with Scrum Alliance on why release orientation (vs. project orientation) is so important to being agile and critical to scaled agile.
This article is about the third and final alternative to the Ideal Team Structure – feature teams with mixed-composite skill teams.
In the last article, I outlined the Large Feature Team pattern as a first alternative to the Ideal Team Structure (ITS) if your organization cannot make the immediate leap to the ITS when transitioning to agile solution delivery. In another article, I provided an overview of the concepts of feature teams and components teams. In this article, I will discuss the second alternative using a combination of feature teams and component teams.
In previous articles, I outlined the guiding principles for organizing agile teams (start here if you haven't started the article series yet) and described the Ideal Team Structure (ITS). This is the first in a series of articles to describe various organizational design patterns to start the journey to the ITS given the real possibility that your large organization cannot switch to the ITS immediately upon starting the transition to agile software delivery.
I spent time outlining the guiding principles for organizing agile teams in my last article. With the challenge of delivering business intent where changes to 10’s of platforms / components are needed and we only have developers and testers who specialize in singular platforms / components - how do you organize? There have been many books, whitepapers, and blogs (see here, here, here, and here). talking about the tradeoffs of feature teams (which can also be referred to as business vertical teams or product-aligned teams) and component teams. A feature team spends their days delivering user stories that are highly reflective of needed business intent whereas component teams spend their time delivering user stories that are generated by the feature teams because they need components outside of their scope of knowledge or responsibility modified to deliver the overall solution.
Much of the writing on feature and component teams puts feature teams in the “good” camp and component teams in the “bad” (and sometimes “evil”) camp. With the challenges outlined above, to some degree, component teams might be a necessary evil. The key is that your initial organizational design has feature teams as well and that you are creating an obvious maturity path towards possibly eliminating the component teams by pushing that component skill and knowledge towards the feature teams through knowledge sharing and architectural simplification. Ultimately, the goal is to create feature teams of generalizing specialists, living and collaborating right with the BIG’s (Business Intent Generators), and able to create and modify 100% the system components needed to delivery that business intent – the Ideal Team Structure (ITS).
Before I get on with describing the less-than-ideal organizational models, I thought it would be useful to spend some time describing what the Ideal Team Structure looks like to paint the picture of the target. And what better way to paint the picture than with a picture…