Scaling Agile in Enterprises
Agile is the buzzword today in most enterprise IT departments — where efficient delivery of software business value is enabled via cross functional and self managing teams delivering iteratively and incrementally to end users and customers by working closely with the business. Scrum, Crystal, XP, FDD are some of the frameworks used within Agile with Scrum being the dominant one. Most of them combine principles of small teams, Lean thinking supported with customer- centric design thinking.
For Scaling scrum — There are a lot of frameworks out there like Nexus, Scrum-at-scale, SAFE, LESS, DAD worth reviewing in the context of your organisation. Some of the valuable concepts proposed by these frameworks can be adopted, though the mechanics will depend on the context of the business based on its resource mix, culture and priorities.
The challenge:
Easier said than done — most enterprises are not startups and have monolithic divisions, legacy systems, bureaucratic processes and typical water-scrum-fall model. This model ensures that budgeting process at the beginning (or end) of the year takes place at the highest levels in a “secretly” planned fashion , software delivery for the rest of the year is scrum based and the support is outsourced to an operations or support vendor who ensure events are monitored and tickets resolved in a timely manner following a water-”fall” approach.To add to the mix, there are critical dependancies between agile and non-agile teams leading to friction and delays doing “integration” work.
Since scrum works in smaller teams and delivers value on a Continuous basis, IT leaders relish the prospect of spreading it across the department, divisions and create a roadmap for “Agile” transformation of the enterprise. A fast moving agile and adaptive enterprise is on most CIO’s todo list.
The approach:
Management considerations must include answers to questions like
- Would a big-bang agile transformation work?
- Should we slowly spread Scrum on certain “high value” projects and then gradually build from there?
- How do we form cross functional, self managing (multi-disciplinary) teams given years of silo based approaches to working?
- Are we going to hire internal staff or outsource development work to vendors?
- How do we manage Enterprise Change in areas like Infrastructure and DevOps?
- How do we create a culture which has a ingrained agile mindset across the Enterprise?
Instead of solving for how to “scale scrum” the approach should be directed towards what priorities and outcomes are we trying to solve for the business right now and then break it down into deliverables and priorities based on budget availability for the period in question (annual / quarter).
Essentials for scaling
Spreading: If a small team is able to demonstrate efficient delivery of software by collaboratively working within themselves — then how do we spread these values across the organisation? What is required to champion and spearhead this shift in the way we work across the entire organisation?
Coordination: How do we get teams to coordinate with each other seeing the bigger picture from a customer centric point of view? for eg: This could be multiple scrum teams delivering the same product increment or could be multiple scrum teams working across web and mobile streams trying to deliver a omni-channel experience.
Alignment: While scrum and fast delivery of software is all the rage — senior leadership is concerned with an altogether separate list of KPIs like return on investment, breakeven time, customer traction and loyalty etc (which the CFO has been lured into) . Delivering software on time and making a business of out the software are two different beasts requiring a whole slew of measures to be carefully executed. This is more so ever true for consumer facing software. “If you build they will come is not even a strategy.” Hence the products may need a Chief Success Owner (it could be the Product Owner) and all stakeholders need a common definition of what an MVP is, what KPIs measure the success and potential failure of the product so that the entire organisation is aligned with the expectations.
Since not all divisions are expected to be agile all at once — the organisation should strive for a process to include non-agile teams and have a common language groups can use to communicate and work out their interdependencies. Carefully planned Training, Awareness sessions, workshops need to to take place so people start conversing in the agile language and eventually it becomes a part of the workplace culture. Leadership teams need to instill agile values throughout the entire enterprise and not just within IT.
To begin leadership team should create a series of teams based on the key business priorities and then create a sequence of activities by those teams to deliver on the chosen priorities.
One common approach while drawing out the roadmap is to look at these areas :
- How do we enhance / improve all customer facing touch-points and experiences?
- How are the experiences related with the business process — what are the areas which overlap and how can we significantly reduce waste and make the process efficient?
- What systems can we develop to support the process that enhance the customer experience.
The intent of the roadmap is to clarify how to engage the right people in the right work without creating confusion. This kind of link is especially important when organizational structures do not align with customer behaviors.
Launching Agile Teams:
No agile team should launch unless and until it is ready to begin. Ready doesn’t mean planned in detail and guaranteed to succeed. It means that the team is:
- focused on a major business opportunity with a lot at stake
- responsible for specific outcomes
- trusted to work autonomously — guided by clear decision rights, properly resourced, and staffed with a small group of multidisciplinary experts who are passionate about the opportunity
- committed to applying agile values, principles, and practices
- empowered to collaborate closely with customers
- able to create rapid prototypes and fast feedback loops
- supported by senior executives who will address impediments and drive adoption of the team’s work
So a leadership team hoping to scale up agile needs to instill agile values and principles throughout the enterprise, including the parts that do not organize into agile teams.
The bigger changes are in the ways functional departments work. Functional priorities are necessarily more fully aligned with corporate strategies. If one of the company’s key priorities is improving customers’ mobile experience, that can’t be number 10 on finance’s funding list or HR’s hiring list. And departments such as Infrastructure and legal may need buffer capacity to deal with urgent requests from high-priority agile teams.
To ensure annual budget cycles do not hinder innovation — they need to be completely revamped to support the agile way of working. Long term support for software products also need to be similarly considered as a part of the enterprise strategy.
Conclusion
Adopting agile at scale means more than just plugging a new tool into an existing framework. It requires a paradigm shift at the organisational level, The biggest downfall is not understanding how different this is , and not investing in the learning and support that’s required to build the environment that enables it to work effectively.
So when you think about scaling Agile — begin with
- Do not scale
- Scale Slowly
- Spend ample time on architectural / development standards and streamlining your Infrastructure / Devops setting an automation mindset.
- Socialise the new way of working and agile principles throughout the organisation while accommodating non-agile teams in the process.
Although many frameworks likeNexus, Scrum-at-scale, SAFE, LESS, DAD provide guidance, Once we move past “scale” to the real problem your company is most interested in solving right now, then one of these frameworks and suggested approaches above might make more sense.
References
cio.com, hbr.org, forbes.com
Altaf Rehmani is a Technology Innovator, helped various businesses with Digital transformation projects, Agile Evangelist and a champion of applying technology to enable business growth. He lives in Hong Kong and can be reached via email or twitter. Please leave your feedback and a clap if you have liked this article.
Other articles which may be of interest:
Managing High Performing teams
Continuous team improvements using Agile Retrospectives
Common Mistakes in Agile Implementations
