Most IT organizations around the world have realized the effectiveness of Agile Software Development. An Agile Development team delivers working software at frequent intervals of iterations, which not only increases customer confidence, but it also reduces risk and increases business value considerably. But is agility only to be considered for development teams? Definitely not. Being Agile needs a huge change in the mindset of the entire organization. In a small organization where business and IT work very closely it might not be such a challenge for the business leadership and stakeholders to create a homogeneous Agile Structure within the organization, but for larger organizations where the business is often cut off from the IT, if agility is left only to IT then it will be an assured failure, because agility cannot be limited to the development teams, whereas the business follows an age old hierarchical structure. So what is the way around?
Dean Leffingwell came out with a very interesting model for enterprises who wants to practice enterprise wide agility; it is called the Scaled Agile Framework (SAFe). It looks like this-
In this framework you have essentially 3 levels- Portfolio, Program and Team. The Portfolio level decides on the Strategic themes that should be worked on , creates Portfolio Epics out of them and assigns them to the Program. At the Program Level the Epics of the Portfolio are further refined and broken down into features which are then assigned to teams to be delivered in Iterations spanning a Release Train. The framework looks really nice and seems to be quite promising in terms of creating a homogeneous agile organization. But is the framework really Agile? Will it actually help an enterprise become Agile?
To answer these questions let us take a look at the Agile Manifesto-
Now if we compare this to the SAFe framework, we may get some answers.
Individuals and Interactions over Process and Tools
The SAFe is mostly about defining a process and workflow for delivering software. A portfolio first decides what needs to be done, then it is assigned to a program, which then assigns it to a team. So the team, the Product Owner, the Scrum master, the Technical Architects are really just a “pawn” in the process and there is hardly any interaction or feedback happening in assignment of work. SAFe fails.
Working Software over comprehensive documentation
After implementing SAFe organizations are still delivering successful software at each sprint/release. SAFe wins.
Customer Collaboration over Contract Negotiation
In SAFe I really don’t see a way where in you can involve customers in Sprint Reviews or Release Reviews. Maybe you can, but it is not really evident from the framework. Let us consider we can collaborate with Customers at the end of every sprint. SAFe wins.
Responding to change over following a plan
This one is a little tricky, because if you see SAFe, the Program is planning Agile Release Train which comprises of multiple sprints/iterations and whatever has been planned in the release train is being worked on by the development teams. If there is some feedback given by customers at the end of the sprint , then first the changes have to be captured at the Program level, then it has to be communicated at the team level, the same also needs to be updated at the portfolio level. I see this thing getting quite messy. So honestly, I don’t see much scope of responding to change in SAFe. SAFe fails.
So as we can see SAFe is failing on two points and winning on two points; now the call is absolutely yours whether you want to use SAFe or create your own Enterprise wide Agility model. If I were you I would have created my own Agile Enterprise Framework fulfilling the Agile Manifesto.
In my next article I will propose a plan for the same. Please wait till then.
How would you plan your Agile Enterprise?
Agile Product Leadership 