Should we use a framework like SAFE or LESS to bring agile into large organisations?

Editors warning – sorry this article is a bit long, but I was in a rush so I didn’t have time to shorten it 🙂

I have found that agile practices work really well for a team, as long as you know the secret of agile (found here).  You can also see some videos on how to do agile really well here.

But helping a whole organisation go agile is a little trickier.

Of course, once we see what happens when a single team get their agile mojo, it is natural that we start thinking about repeating their success on a larger scale.

Quite often we also observe that the thing holding the newly agile team back is the very thing that is supposed to support them – the organisation.

Once the team is successful, people often complain that organisational antibodies are attacking them and stopping them from being awesome. For example, the project office tries to inflict unhelpful measures on the team, such as I noticed a long time ago (see here) and the infrastructure team are being really mean.

Apparently this happens because of the agile team’s strange ceremonies and their constant attempts to spread change through the organisation like a virus.

“But what if we could stop the antibodies attacking them,” People say.

The agile team and the governance teams can, of course, be friends.  We can implement agile governance and it does work (see a bland video here).

But people often want to do more.

“Hey, if agile works for a team, wouldn’t it be great if we could do it across the whole organisation,” They observe, “We really should do something more to scale agile so it works across the whole enterprise. Then we will see some really big benefits”.

Luckily, people have been working on exactly this problem and they have come up with some pretty well thought out approaches (for example LESS and SAFE).

But for purely subjective reasons I don’t like those approaches and for a long time I struggled to understand why.

In my defence, it is possible to apply agile across an organisation without using a published framework or approach.

A while ago I read a book called “Essential Scrum” by Kenneth S Rubin and, with relation to Scrum, I thought the book covered everything that you need to know in order to scale agile – it had some common sense advice for the common issues faced in an organisation attempting to increase its agility.  So why can’t we just read the book and do that?

The book is good, but people seem to read it and say “alas – not here.”

I am not exactly sure why, but people seem to feel they need more than the simple techniques explained in the book.

However approaches like SAFE, LESS and Disciplined Agile  (see a better link here) all seem to be designed to “do agile at scale” and I couldn’t think of a reason to avoid using them.

In fact there are even tools like Rally and Version One that are designed for large scale agile use.  Even the most common tool I encounter (Jira) now has a portfolio management edition for when your team grows up.

This means that there are are both frameworks and tools that are designed to help you do agile at scale – and according to people I trust, they seem to be good approaches and good enough tools.

Yet I still struggled with it all.

If the frameworks and tools exist then I should embrace them to scale agile, yet I don’t.  That means I should probably form an argument as to why you should’t use them either – but I can’t think of a good reason why you wouldn’t.

So I see the need for them, but I just feel a bit resistant to them

Mostly, I have just implemented agile approaches with the people I work with and then used the organisation’s existing project management frameworks to integrate beyond that.

I probably should not admit it but I once used agile with an organisation that were using Prince 2 and ITIL and it seemed to work OK.

But what are we actually scaling?

On the weekend I finally had an epiphany –

I am not sure what it is we are scaling.

I should know what “scaling agile” means because I do a lot of agile stuff, but in fact I actually don’t.

Are we scaling the practices to make them work? That is a bit complicated but not impossible:

Here is a picture of a team doing agile

Here are a couple of teams doing agile together:

They now have a dependency meeting every week that looks forward a couple of sprints and they have a daily “scrum of scrums” to keep track of daily issues. The technical crew also get together to discuss the joint architectural models that impact both teams.

If you want to know what these meetings and things are then send me an email – but they are fairly easy to implement.

Of course it gets harder to scale much bigger than that but it is still quite doable. You can even have some teams doing agile while others are using other approaches.

But if agile is a mindset, then maybe we are not actually scaling the processes, instead, we are scaling the agile mindset itself.  I guess this means we want to turn the organisation into a giant agile-hive-mind (or not?)

So to scale agile, I I thought I needed to know what agile is so I know what I am scaling.

But agile is a general term rather than a specific thing.  So it is hard to find a “little” agile and then pump it up to be bigger.

Re-framing the way I think about the frameworks

I thought about it a bit more and here is where my thoughts led me:

In a small team we already know the secret to predicting which teams will be successful in their use of agile, that bit is easy

Therefore, if we can scale the factors that lead to success for an individual team to “be agile”, then we can replicate that across more teams and bigger teams until our organisation is agile.

I don’t really care what “being agile” is, as long as I scale the factors that make it successful.  That way teams can self-organise to be agile as much as they want, pushed to be successful by the same factors that make one team succeed.

It also follows then, that if we can’t scale those factors then we can’t replicate the team’s success across the wider organisation.

All we can do is to let the team be agile and then integrate their work through some translation layer that allows them to deliver their work into the wider “not-so-agile” organisation:

• My web team or internal apps team can deliver using “super-way-cool” agile, but when they need to integrate with 64 other systems then then need to engage IT through the regular channels and this will slow them down a bit in order to avoid them rolling out changes that don’t integrate.
• My process improvement team can deliver continuous improvement, subject to their “vendors” in training, IT and HR being engaged using the usual process for doing so.

Using frameworks to support agile rather than creating it

Now I can reframe my attitude to “frameworks”.

If teams in the organisation have the right factors in place to allow them to be agile, then something called “LESS” offers them a huge library of processes, meetings and suggestions they can adopt. Thus LESS is not scaling the team’s “Agility” but rather offering the team suggestions about how to apply common team practices when an already agile team grows bigger.

Similarly, something called agile for dads Disciplined Agile Development is effective as a source of suggestions for technical practices that can be applied.  In fact they have some good approaches that can be applied to teams in a waterfall setting, who want to find some technical practices that are somewhat agile.

If an organisation wants to look at a model for scaling iterative development across an organisation, where there are lots of dependencies and big clunky systems, then something called SAFE offers the team a suggestion about how the organisation can integrate lots of teams together to be one large delivery factory.

Thus agile teams can deliver their part of a bigger solution to “the train station” and the “SAFE train” will then pick up passengers (and value) from other teams and deliver them all together at the same time, a month or so later.

If a lot of the organisation is still “agile-challenged” or actually getting real value from traditional techniques, then the project management office can provide two sets of project management frameworks, like Prince2 for traditional projects and DSDM (or ATERN) for agile one. This will allow teams to select their delivery model and still deliver within the same organisation.

Development and Release management teams can automate testing and deployment and remove waste by using devops, but still have an outsourced service management approach using ITIL, USMBOK or ISO-something to provide consistency and predictability across borders.

Operations teams can adopt lean operations, service design or continuous improvement, within their scope of influence, without having the whole organisation go lean.

Some good books on implementing lean IT practices (and the mindset) can be found here http://www.poppendieck.com/.  Their approaches will work on a large scale or a small one.  I am told they also do excellent training, but don’t use them because I would prefer you to come to me or Software Education.

There is also an excellent book on implementing service design at this site http://thisisservicedesignthinking.com/.  It will make you feel embarrassed about how little you have done to keep your customers happy and will give some guidance on how to develop a good design thinking approach to services.  Not quite the same as agile but complementary and in many ways a better starting point for customer service.

 But what if we are not agile yet? Can the frameworks and stuff like that help?

Each of these approaches can assist a group of isolated agile teams to merge like raindrops to form an agile stream of value flowing through the business to the customer … although the change may not be as poetic and lovely as that.

But they will assist the isolated teams IFF (if and only if) the factors are in place to support the teams being agile across the organisation in the first place.  None of them actually make the organisation agile.

But all is not lost if the factors are not in place across the whole organisation.  If this is the case then each of the approaches can act as a translation layer, allowing an agile team to co-exist in a “sort of agile” organisation.

So now I know why these frameworks do work – they either link already agile teams or they compensate for the lack of agility in the organisation by providing a translation layer between agile teams and the rest of the teams.

In other words the framework is an accommodation to allow for the inconsistencies in the delivery models of different teams, to remove variance (and potentially innovation or local optimisation).  But this can still add value in making things more efficient without becoming “actually honestly agile”.

This also explains why they often fail – people are expecting the frameworks to make the organisation agile.  But they can never do this on their own – the organisation has to actually go agile to use them.

In fact the first thing the agile manifesto says is that processes and tools should support the interaction of the people.  The people should not become a bunch of tools to support the implementation of a process as an end in itself.

Thus frameworks, along with improved project office methodologies and other approaches all make it easier to capture the value being offered by people that are already agile.  They can also offer efficiency gains in a not-quite-agile setting.

But we need to look elsewhere to understand how those people and teams become agile in order to take advantage of the framework or approach.

Its a long winded and probably harsh view, but that’s where I got to with my thinking.

The next problem will probably be “should we look at making the team agile or making the product agile”.  Then I can finally capture what I think we need to do in order to implement agile on a large scale in a large organisation.