Q:The main difference between LeSS and other known frameworks is that it requires organizational re-design. What possible consequences of LeSS adoption can be expected at an organization that has a inherently complex organizational structure (multiple hierarchical levels and organizational layers).
Gene Gendel – Scrum Alliance Certified Enterprise Coach (SA-CEC)
The Panel’s Answers
Although LeSS is definitely about organizational re-design, the same can be said for Scrum. A Scrum team is self-organizing and cross-functional. Organizations that want to embrace Scrum usually don’t have self-organizing and cross-functional teams yet.
Therefore, a properly introduced Scrum has inevitable effect on organizational design, albeit limited to one team and team’s direct environment.
Therefore, LeSS is not unique in requiring organizational re-design.
Nevertheless, in comparison to Scrum, LeSS makes these effects explicit and has a product-wide reach. Important to notice is that “product” in LeSS is primarily defined from customer point of view.
Therefore, definition of a product tends to be broad.
The main aspect of this product-wide organizational effect is teams, how they are formed, what is team’s focus and how teams collaborate. The principles behind how teams work have also effect on management and many other roles. E.g. “Customer Centric” and “Whole Product Focus” principles require feature teams that are aligned with creating end-to-end customer-centric features into one fully integrated product after every sprint. Implication of this is that any roles or groups of people with special authority and responsibilities who stand between customer and teams or between teams are not preferred. They often become team members with whole product focus.
One effect is strong decentralization of decision making towards the teams.
Overall result is descaling in the number of roles, organizational structures, dependencies, management positions, sites, and number of people. In this process, people’s jobs are safe, but roles not.
Some of the *possible* consequences (in order):
- People quit
- Implicit/explicit resistance from the management layer
- The greater organizational system fights the change
- Delivery gets slower
- Exposes real organizational issues
- Blame the framework for organizational issues or real meaningful change
- Human resources become software engineers
- More fun in the work place
- Managers become leaders
- Real teams with a sense of urgency and purpose
- No organization capable of outlearning their competitors
- Happier customers
- More revenue
The key understanding given here is what LeSS is and why it exists. LeSS is an optimisation of organisational design to shorten cycle time and maximise flexibility. The amount that an organisation will adopt LeSS is directly related to this understanding by the senior management and their desire to optimise for these things.
Not everyone wants to optimise around these two outcomes. However, most organisations that face competition will need to move towards them otherwise they will struggle against those who have.
LeSS achieves this optimisation by building upon Scrum without changing Scrum at all. LeSS is Scrum. According to the Version One surveys, and the data collected by Scott Ambler (creator of the Disciplined Agile Framework), the hardest challenge for organisations is that the culture (the way we do things around here) is not optimised for product delivery. The culture must change to enable Agile to scale.
We know from Larman’s Laws, that Culture follows Structure. It therefore means to change culture, we must change structure. In complex organisations, this is like untangling several big balls of string tangled together. Changing structure is not straight forward, often there are wicked problems to solve, and certainly trade offs instead of binary choices.
To enable the kind of structural changes to optimise for software product development, we must first put in place enablers.
You can expect to have to put these in place. These are:
- Automated testing, a mind-set of continuous integration, and scripted deployment. This is to enable shared code ownership.
- Shared code ownership model. This is to enable feature teams across a product.
- A program of pairing, training, and sharing knowledge through community of practices. This is to enable cross functional, generalising specialist teams.
- Cross Functional generalising specialist teams. This is to enable flow through the product development and to optimise around low work in progress, short cycle times, and ability to change priorities quickly.
- Management as leadership. Where the role of management is to provide the environments for teams to excel and become better. This enables teams to make decisions about the work they are doing without escalation. Autonomy is one of the primary motivators on the journey of high performing teams.
- Less meetings. Most meetings are a direct consequence of dependences across teams, hand offs, and escalated problems due to lack of autonomy. This enables more time spent producing products and improving the system.
Therefore, organisations can expect to see structural changes, cultural changes, flatter hierarchy, better quality products.
February’s Q&A Panel
How should a scrum team deal with a situation where the “scrum master” / team leader does not appear to be following scrum principles and values?
January’s Q&A Panel
The passing of another year allows us to pause and reflect on the previous year, as well as to set out a path to further develop and address the challenges for the upcoming one.
What then, for you, were the key learning points, either from the numerous thought leaders in attendance at AWA events in 2015 or from your own experiences, and where do you think there is further work to be done in 2016 to ensure even more success with respect to scaled agile adoption?
Enter a Question
Volunteer to Answer