Success of the Agile with smaller teams have got the attention of enterprise. The question is whether such high velocity with higher quality development can be duplicated when scaled to enterprise size.


To bring scalability, we must first understand where does agile gets it agility!


Our experience of transforming our small waterfall services team into agile product team over last two years, told us that agility comes from three sources:

  1. Focus on story to get DONE (a smaller unit than application (waterfall) or even feature)!
  2. A dedicated, multi-functional team that works collaboratively, autonomously to get this story DONE, and
  3. Early feedback of customer, ensuring early and guaranteed delivery of business value.

A focused, dedicated scrum team is thus the heart and soul that ensures agility of Agile and hence can not be increased from 6-8 to 20 or 200 for enterprise. Look at the agile team as an $50 entree in a chic restaurant. Thus, scaling restaurant’s operation is not offering buffet, but creating and managing multiple teams that can simultaneously feed hand-crafted $50 entrée to 500 patrons a night. You get the idea!


And there lies the real challenge in scaling. Like in chic restaurant, there needs to be lot of preparation, well defined, synchronized workflows, roles, and responsibilities. This is exactly what different enterprise scale frameworks are trying to provide! These frameworks define terms, workflows, roles and responsibilities. SAFe, for example, provides workflows that connect product definition to program planning and software development through portfolio. Also the roles and responsibilities in each of these modules.


Since these are agile enterprise frameworks at steady-state, the initial challenge becomes how to transform existing waterfall enterprises to these steady-state workflows and roles, etc.


Here is what I mean by transformation: assume that a 5 people agile team get DONE 10 stories through a 2 weeks’ iteration. An enterprise team of 500, will need to have 1000 stories backlog ready at the start of iteration timebox. Not only that, come next iteration 2 weeks later, another 1000 stories need to be ready again. Over the year, your team needs to define 26,000 stories ready for development.


So the transformational challenge, is ensuring a steady stream of stories to feed your 100 agile teams, at the rate of 1000 stories per two weeks’ iteration. (These calculations always make me appreciate the prep a la carte restaurant has to do to serve 500 people a night.) This will require modifying and adding to your existing organization, mostly enhancing team size, capabilities and processes to achieve these stories.


A quick deep-drive on- how do handle 26000 stories a year? An enterprise with 500 people, most likely will need to start categorizing their products in one or more product lines. Similarly, to manage backlog of 26000 stories, it will need at least three levels of backlog hierarchy as Epic > Feature > Story. Assuming average 50 stories per feature, 50 features or 2500 stories per epic, this backlog classification can handle 26000 stories in about 11 epics or an epic release a month. Next is to ensure that there is a product line + systems group that has capacity to create 2000 stories every two weeks.


Traditionally, most organizations assume that having larger developers proportion in team is the key to agility. We saw that once you go agile, your team composition changes considerably. Then again you may want stories to be groomed close to say 80-90% before iteration starts. Define too early, and they do not allow flexibility; define too late and development can’t finish. So optimizing out-of-phase of story definition/grooming with development is a key consideration in transforming enterprise.


After ensuring product and backlog scaled structure is in place, program management need to be scaled, along same line – people, capabilities, process. Finally, task management needs to be scaled by providing and managing task container hierarchy of program, release and iteration for multiple teams. Here lies the challenge of managing the interconnected stories across teams and sequences and so. Then again, testing workflow changes lot more too!


Thus, scaling agile in an enterprise will require transforming team compositions, bringing in newer workflows, techniques, roles and responsibilities. While current frameworks tell you where to reach, the challenge lies in how to reach there or how to transform, while continue to deliver on daily basis. For now, that is topic for a next article.


Also, this in no small proportions brings out a need for an agile development tool that is built for enterprise grounds up, and build for transformation from waterfall to agile. Building enterprise capabilities on a top of an agile project tool, is like building a skyscraper on an existing home. This was the key in building SoftALM® – our agile ALM tool on enterprise scaled model from day one and then developing SoftAgile™ as enterprise project tool.


Throughout this you might have noticed, the agile team is really staying 6-8 people strong. And it is the enterprise that needs to regrouped, scaled and hence transformed.


Essentially, it is not scaling agile for enterprise, but it is the enterprise that needs to be scaled or transformed to leverage agility!


Top