Following the launch event for our Agile Foundations book, these questions focus on the benefits of understanding all agile frameworks and dealing with shared resources.

Do you see the Agile Foundation course becoming something that holds value for people who want to become more agile without automatically going to Scrum Alliance or becoming a Scrum Master?

(Peter Measey) I am a Scrum Master and I am very behind scrum and all the other agile approaches. Is scrum ‘the’ answer? No. Is agile ‘the’ answer? No. It’s about bringing these things together pragmatically so they create something that works for the whole organisation, there is no ‘the’ answer. In my view, yes I would say Agile Foundations is a superb place to start because it talks generically about agile rather than being biased to any specific agile framework. It gives you the opportunity to assess if and where you would use scrum or extreme programming; do I need to scale this; do I need project management capability; and so on.

It does keep it generic rather than focus on one particular framework. So yes it gives you the opportunity to understand all the different frameworks, how they might fit together and then you can make the choice that really works for you.

At a recent webcast, I heard Ken Schreiber describe his answer to scaling scrum as being scrum, scrum and only scrum. How will that work for scrum.org over the next 12 months if they continue on that track?

(Radtac) When you implement scrum at a team level, do you just focus on scrum techniques? No, you bolster them with other things, maybe underneath, maybe on top. So would not have to do that with scale as well? Possibly.

From our point of view you have to add other techniques and practices to scrum to make it successful anyway, in a pragmatic way.

As individuals we’re all different. As teams, we’re all different. Projects are all different; I’ve never seen two programs look the same. Having one framework that is the answer to all problems is not pragmatic. Understanding the context and finding the right approach for an organisation is really, really important.

You are dealing with people and if you really want to make progress, you need to make progress at the speed they’re prepared to travel at, and in a way they’re prepared to travel.

How do you deal with shared resources and not being able to have full feature teams?

(Radtac) In essence what we try to and do in all agile approaches is form feature teams. What is agile about, it’s about getting value out to the business as continuously as possible. Forming feature teams gives you the ability to deliver features in short timescales, hopefully every couple of weeks.

However you might be in a situation where you’re developing something over a couple of thousand people and you might have component teams (teams that can only focus on delivering components that, only when integrated, create features). But ‘inspect and adapt’ your approach over time, this is the whole idea of agile. Do what makes sense in the environment in which you’re trying to do it.

In this specific case (can’t form feature teams), I would suggest in the medium to long term, work with the resourcing team to solve the issue, otherwise you will have people who need to switch between teams - that will cause a huge amount of ‘context and task switching’. There is a lot of science behind context and task switching being just about the lowest productivity way you can work. However if you’re in that reality, a number of the agile frameworks talk about ‘core’ and ‘support’ teams, scrum for example. You have a core team which contains a core group of people and skills required to deliver features, supporting the core team there may be support teams or people. Implementing core feature teams stops context switching, support teams will be context switching, however it minimises the effect. Core and support teams are recognised in the agile world as one of the ways to deal with the issues you raised, however, we would strongly suggest you change the organisational issue that’s causing that to happen. That won’t happen immediately which is why something like core and support teams can help in the interim.

Get permission to make it an experiment. Don’t try to convince the resource department that you’re trying to change the world. Suggest an experiment that is short term; try it for a three or six month period. Frame it with a deadline; dedicate these people for now and then afterwards if you can demonstrate the value that contributed, then you can start to build a conversation with some kind of empirical data.