We’ve all been “Agile” for years, but many companies find that letting software development teams decide when a new system or product is ready doesn’t fit very well with commercial plans. The idea of a backlog of work, constantly adjusted in response to commercial changes is very desirable, but for many organizations the scale at which development actually takes place means that teams cannot be completely self-sufficient. A single Scrum team, for example, should ideally have no more than 9 people, which has a limited development capacity. More teams are often needed to deliver a product in a sensible time frame, so they must operate within an overall architecture and roadmap, which doesn’t change constantly. So now we have “Scaled Agile”, in other words, development teams that follow Agile development principles, but with additional roles and functions to ensure effective planning and coordination across those teams.
There are currently three flavours of Scaled Agile being practised – Disciplined Agile Delivery (DAD), Scaled Agile Framework (SAFe) and Large Scale Scrum (LeSS). In brief, the approaches work as follows. DAD is derived from the Rational Unified Process and comprises a number of phases: Inception – includes planning and design; Construction – includes development and testing; Transition – includes preparation for release and support. Each phase is iterative, so the Construction phase can be carried out using Scrum, XP or another Agile approach. Otherwise, it is close to a waterfall development approach. SAFe has the concept of Agile Release Trains, which consist of multiple agile development teams working in a tightly synchronised way. The Agile Release Train starts with a formal scoping and planning session, runs for a specified length of time and then releases a product together. The definition and management of the product backlog priorities is done by the program team outside the development teams and it does not change during the period of the Agile Release Train. There are separate specialists who support the development teams, such as System Architects, who have their own backlog of work. In the LeSS approach, in the Scrum teams remain independent, except that they share a product owner, who prioritises the backlog for all of them. There is joint planning at the beginning and a joint review at the end of each development “Sprint” to ensure that the teams are working to same priorities, but the teams self-manage during the sprints.
Choosing your organizational journey
How to choose? It depends on where your organization is on the Organization Journey, as created by Simon Powers of Adventures with Agile. The journey correlates approximately to Maslow’s five basic human needs, where each level of comfort can only achieved if the levels below are satisfied : Physiological, Safety, Love/belonging, Esteem, Self-actualization.
In the Organization Journey, these needs are reflected the types of organization that have evolved as human societies have become more sophisticated. The most basic is the “wolf pack”, where individuals don’t see themselves as separate from the group. This is still apparent in modern gang culture. The next stage is the “army” model, where there is very clear rules on how to behave and individualism is not encouraged. This is not a model seen in many commercial organizations, but in government departments and some religious organizations. One type more commonly seen is the “machine”, identified by F.W. Taylor, where there are distinct, clearly defined roles for each individual – the cogs in the machine, which work together highly efficiently. An individual can take decisions, but within proscribed boundaries. Examples of this type can be found in many large corporations, particularly in manufacturing. The next stage of evolution is the “Community” or “Family”, where individual responsibility and empowerment are encouraged. The most obvious example of this type would be small, start-up organizations, but the model does equally apply in larger, more established organizations. In this case, individuals can contribute in varied ways, they also feel a sense of belonging and of being held in esteem. Finally, there is the “self-realized” model, which correlates to the ultimate human need defined by Maslow. In this fractal model, each individual has equal authority to make decisions and promote ideas. There is no leadership hierarchy. An example of this in the commercial world is Zappos, a retail company focussed entirely on customer service.
How is this relevant to the approach to scaling agile? These organization types sit on a continuum of control and trust. The less sophisticated the type, the higher the level of control of the individuals; the more sophisticated, the higher level of trust in them. So if an organization wants to keep close control over development teams, a “machine-like” approach will work better. If the organization wants the teams to have greater independence, for example in a highly creative industry, and its products are not integrated, a “community-like” approach would be most compatible. The Scaled Agile frameworks sit at different stages on the journey.
The ins and outs of Scaled Agile Frameworks
So back to the Scaled Agile frameworks. The DAD approach is an easy way of moving from a waterfall to an agile development approach. For example, some companies find the formal inception phase important before the development begins, so they follow DAD. Thoughtworks and Lastminute.com followed this approach in the transition to agile development. Similarly, the SAFe framework allows a business to maintain tighter control over the content and timescales of a software delivery. This was an important aspect for Travis Perkins when they introduced an agile development model. The LeSS approach works well for organizations already structured in self-defining teams, each containing all the skills needed to deliver working software. The commercial side of the business is represented inside the team, in the Product Owner role. Moving from waterfall to this approach requires more organizational change, but this can be very welcome, as JP Morgan discovered.
At 1E, the Engineering department has been organised along product lines for some years. The Scrum teams responsible for our legacy products have a dedicated Product Owner and have all the skills they need to design, develop, test and release working software. However, to deliver new products in a commercial timescale, we need to have multiple teams working on the same codebase. For us, moving to the LeSS model makes sense. The Product Owner will work with more than one team, setting priorities for the product as a whole; the development teams will plan together, but will work through their backlog independently. The cultural fit is perfect too. One of our core values is contributing to the 1E community – each employee is trusted as an individual and as a professional. (“Belonging to the 1E community – Social, ethical and sharing sunshine, 1E’s attitude to our colleagues and customers combines genuine happiness and respect.”)
It really depends where an organization sees itself on the Organization Journey. Does it like individuals to have clearly defined roles and responsibilities, part of the overall mechanism of the business, or does it trust its people to come up with ideas and carry them through, drawing on the skills of each other. Do they belong to a well-oiled machine or a family – like 1E?
