Guest post by Timofey Yevgrashyn, Ciklum
Today more and more enterprises are looking into agile approaches as the answer to their needs. It doesn’t matter if a big company starts scaling agile with or without acting Scrum teams. What matters is the way the company goes from the “let’s-scale-agile” decision to the visible results of scaled agility.
Why scale agility? A few thoughts.
One could say that the apparent reason to apply scaled agile practices is when you have many agile teams that are cross-dependent and working on the same product(s). But it wouldn’t be true as in our practice; the number of people doesn’t drive managers to even start thinking about applying methods above the team level.
What interesting is, the decisions to scale agile often come from the top. The feeling of “something is wrong with the business” on the top level is much higher than that feeling at the team level where the use of Scrum or other agile methods usually starts.
While talking to more senior management, the problems could emerge through the main “pain” areas, which have been reported in a number of agile development studies. Briefly, these areas are quicker time-to-market, better quality of the product, higher engagement of people and higher productivity. One or another, or even combined pain feeling in these areas, leads the enterprise management start thinking about better methods or development practices that could help coordinate many agile teams. The company management itself, or with the help of consultants, realizes the need for scaled agile. And so they start looking for already known frameworks such as the Scaled Agile Framework® (SAFe™) or experiment with their way.
Scaling agility doesn’t come easy.
It is worth mentioning that an organization structure is the result of that company’s history. Rarely (not to say never) is organizational structure architected in a scalable way from the beginning.
To be able to deliver better software and respond to change at the same time, an enterprise should overcome the major pitfall in scaling an organization. This pitfall is the traditional mindset of project-oriented companies instead of value-oriented companies.
Many of you have seen the triangles picture. It shows how the sequential phased approach (aka waterfall development) is compared to agile development methods in their view on three cornerstones: (1) scope, (2) time and (3) teams – resources and/or budget:
Many organizations with a desire to scale agility still approach projects in the old, traditional way. The business part defines the total scope, and the software development part (or a vendor) is expected to estimate and plan how many resources and months they need to deliver what they were told.
At the same time, the agility of an organization means delivering what users need and cutting out waste from the original ideas to maximize value. This demands that an organization build a structure that, at regular pace, delivers a working product and then just balance out the decisions of what to do next in order for the business to develop.
What companies do before scaling.
Organizing people and communications around value streams is one of the major changes that happens when a company decides to scale agility. Even if the decision “let’s scale agility” is supported from the very top level, and everyone is eager to achieve this state quickly, there’s still a long way to go.
In our practice, this change requires management and key people to review how the organization earns money and delivers value. Often the discussion on how to organize teams around value streams requires changes in the team’s composition. This leads to the human factor and necessity to take this change carefully.
While the top level, or portfolio level, usually focused on value streams alignment, the other part of the organization should review roles, responsibilities and authority levels. Looking on the team and program levels, the need for coordination between teams emerges and, thus, different roles are needed. Nevertheless, these new roles should not be mapped directly to the old company structure. Built from the agility point of view, the duties list for these roles would include: serving, coordinating, and enabling as the primary drivers.
SAFe produces recommendations on what functions are needed on different levels. But like any other framework (LeSS, DAD or simple Scrum), SAFe should be used with care and deep understanding of why the role is needed and what value it brings to the enterprise.
Above organizing around value streams, it’s worth the reminder that an actual software development team is just an intermediate phase from the end-to-end value stream point of view. This makes dependencies on the upstream (usually product analysis and requirements preparation activities), requiring a seamless integration with the downstream (usually stabilization, packaging or deployment).
While both boundaries are meaningful, alignment with the upstream – and especially with business decisions – is critical. As our head of consulting mentioned once to a client, “There is nothing worse than having a great software development team with a great and optimized agile processes, doing wrong things.”
Such initial misalignment in practices makes it apparent that the organization should learn additional methods for content/requirements handling and practices at the program and portfolio levels to support agility at scale. As experience shows, it takes time for those responsible for the content of the product to adapt these methods to a degree where agile teams see the difference between before and now.
Furthermore, if your organization hasn’t had a rhythm of delivering working and demo-able product on team levels, it is risky to launch a joint program with many teams working together and call it scaled agility. The gravity of non-delivering could pull back any well-educated and well-coached organization.
A Program cadence (sometimes called “a release”) is a higher level of the rhythm and alignment achieved when business, content and delivery people can agree on what, when and how. Even if an organization plans their first-ever release cycle together with starting sprints on the teams level, still it would take time before management in charge of the “let’s-scale-our-agility” idea could clearly see benefits and results.
Something would go wrong, definitely.
It seems quite a clear path of activities that an enterprise goes through from decision to actual scaled agility:
- Reorganizing around value streams;
- Identifying the missing or new roles and responsibilities;
- Embracing additional Backlog handling methods on all levels (Portfolio, Program, Team);
- Achieving a rhythm of delivering working and demo-able results and then aligning on the high-level cadence such as a release;
- Adapting continuous culture change and keeping up the momentum
- Our observations show that even having a clear guideline and proven scaled agile framework in-hand, many companies will deviate and take this path differently.
One of the major obstacles has always been, and remains, company politics and old-fashioned culture that oppose the initiative of agility at enterprise-scale. Even with support from top management having a long walk to go, scaling agile challenges persons and ambitions, and causes fears and uncertainty with every decision.
One of the major signs will be a continuous culture change that regularly happens. Such a culture shift could manifest itself in small improvements handled by a team daily. Or it could be regular, healthy and actionable retrospectives, or in a high-level alignment that allows many people to plan together and deliver what’s intended, without a big overhead.
The motto that helps my colleagues and myself be patient on this is “Scaled agility is not the goal, rather a direction.” Thus, even being armed with clear steps and frameworks, we continue helping our clients incrementally to gain value from transforming to scaled agility by inspect-and-adapt all the way.