The success of the Agile with smaller teams have got the attention of enterprise teams. the question is whether it can be duplicated when scaled to enterprise size.
To bring scalability, we must first understand where does agile gets it agility!
Our experience of moving our small waterfall services team into agile product team over last two years, told us that agility comes from three sources:
A focused, dedicated scrum team is thus the heart and soul that ensures agility of Agile. Look at the agile team of 6-8 like 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 workflows, roles, and responsibilities. This is exactly what different enterprise scale frameworks are trying to do! They try to define terms, workflows, roles and responsibilities. SAFe®, for example, provides workflows that connect product definition module to program planning and software development modules through portfolio module. Also the roles and responsibilities in each of modules. These process frameworks need to complemented with transformational framework.
Here is what I mean by transformational framework: 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 time box. 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 first 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.) How do you transform team, capabilities and processes that achieve this?
So 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 26000 stories a year. 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 key.
After ensuring product and backlog scale-up 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. Thus, scaling agile in an enterprise will require transforming team compositions, bringing in newer work flows, 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. These were major considerations, why we built SoftALM® – our agile ALM tool on enterprise scaled model from day one and then developed 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!