News

One of the common misconceptions we come across when discussing an Agile transition is “Agile doesn’t scale”.  Needless to say, at Software Education we firmly disagree and we have experience helping large organisations implement “scaled Agile” using a number of approaches.  Our courses discuss the “scaling” challenge and we work with change leaders to help them identify the appropriate approach for their organisation.

The first question we ask is what does the organisation mean by Agile at scale?  The approach we recommend will depend a lot on the answer to this question and will be unique to your context.

There are many possible approaches to tackling the “scaling” question, and as always we advocate taking a carefully considered context-driven approach to selecting the way you choose to adapt your organisation.   What’s right for your team, your organisation, your environment?  There truly is no “one right way” – an Agile adoption is about cultural change and shifting people’s behaviour to more collaborative, cooperative and adaptive ways of working, not about implementing a set of processes or practices.

Consider aspects such as your level of Agile fluency and the elements of context identified by Philippe Kruchten in his “Octopus Model” and work with your teams to identify what is needed to best achieve your organisational goals.

There are a number of well-publicised approaches to large scale implementation of agile practices; Software Education’s agile team have experience with and knowledge of a number of them, and are able to help our customers identify the different elements which may be useful depending on the organisation’s context.

Here are a few of the possible approaches to the “scaling”, but please recognise that there truly is no single “right” way.  Rather look to help your teams BE Agile and then find the processes & practices which will help best achieve true organisational agility.

• The Scaled Agile Framework (SAFe) is a branded approach which has gained a lot of publicity lately.  We regularly get asked about SAFe in the classroom and in client conversations.

We see SAFe as being possibly relevant in very large organisations that are building software-intensive products to sell to defined markets. SAFe is for big, tightly interdependent and software-intensive products. If there is a need to build a single very large product which has multiple parallel streams of work which need to be coordinated, with a single reference architecture and tight dependencies between the work items and a need to build underlying technical architecture as part of the project.

It may also be useful in internal IT development with very large teams where the products being built have tight coupling and common architecture.

SAFe also requires that all teams across the organisation are working at the same level of Agile maturity, which may not always be the case.

There is quite a lot of controversy surrounding SAFe, as can be seen in this InfoQ article.

One of the risks of an approach such as SAFe is that it can seem like a panacea – very prescriptive and not context-aware.  Beware the snake-oil salesman who promises you that implementing a defined set of practices will make your organisation work better.

SAFe implemented in the right context with a clear understanding of the cultural aspects and in an organisation with mature agile adoption could be very effective, adopted as a way to “buy agile” then we see it failing like any other heavy process-driven approach.

Software Education courses reference this approach and we discuss in the classes the potential uses and pitfalls of this way of working.

• If the need is to have a number of teams evolve an architecture (such as implementing a Services Oriented Architecture) incrementally while rapidly delivering products to market rapidly then there are other factors which apply.  For this environment, one of the end-to-end models such as DAD, DSDM or (more likely) an adaptation of them for your organisation may be more appropriate.

These methods have an identified set of initiation activities which are used to ensure projects fit within a portfolio; they ensure that project teams are enterprise aware and follow enterprise-level standards.  This approach allows for growth in teams through geographic distribution, supports partnering and outsourcing and is highly adaptive in its implementation.  This is the model which we find works best for many of our customers and is embedded in the Software Education Agile process, again with the strong caveat that part of the implementation needs to be tailoring the approach to your specific needs.

• Where teams are largely independent, products have very loose coupling and the goal is to speed time to market by having more work done in a given time period then a straightforward Scrum-of-Scrums approach may be appropriate.

• If the product teams are working on independent activities and there is little or no need for coordination across them, then scaling becomes merely an employment/engagement issue with a need to ensure that team members’ skills are constantly evolving to meet the current organisational needs – here we recommend the need for good communities of practice, cross-functional teams and strong facilitation skills in the teams.  There is nothing particularly special about scaling in this environment, it just requires a lot of trust and maturity in the organisation.  Arlo Belshee talks about this approach in his blog.

At Software Education we truly believe the goal should never be to “go Agile” or to adopt any particular framework or approach – the goal is to help make your organisation more effective, deliver value to your customers sooner, engage your teams more deeply and help make the world of software development more “humane, productive and sustainable” (the mission of the Agile Alliance).

This is what we aim for when we help our customers BE Agile, rather than just doing Agile, or trying to buy Agile.

Posted by Sharon Robson and Shane Hastie