So you’re using scrum or another agile method in the development team, possibly in more than one team, but at this point it is still seen very much as a development practice and nothing to do with the rest of the organisation.
If your scrum adoption is successful then you will frequently find that its influence will spread out into the organisation especially around the sprint cycle with the business aligning itself with the heartbeat of an iteration. This doesn’t mean that all parts of an organisation will adopt scrum practices but they will at a minimum understand how the process works and what, if anything, is expected of them.
To get a wider adoption in an organisation there are often several hurdles to overcome some of the most common ones are: Resistance to change, Scheduling work between teams, Clients and Job security.
Resistance to change
This is perhaps the most difficult hurdle to overcome, to do so needs the senior management within a company to recognise the value in scrum and sponsor its adoption within the organisation.
If you do not get this support from senior management you will run into problems, people will resist any changes that may be suggested by a scrum team to improve the business or changes in their own processes to help with the scrum team(s) e.g. people accepting the product owner role, business prioritisation of work to be done, etc.
If you don’t already have ‘buy in’ from senior management then the easiest way to resolve this is to get one or more members of senior management involved in the scrum process so that they can see how it works and the value that they gain through it. If they can see the process at work and understand the value they gain through it vs. how waterfall projects run they can promote it to other members of management.
If you follow this approach then you must be confident that you will succeed in completing all the work committed to and deliver something of business value, you need to set yourself up to succeed. If you fail then the management is likely to write the whole thing off, and whilst you may be able to continue with various agile practices and processes you will have to wait a while before attempting to convince management to adopt a different process.
You also need to ensure you get the right person in management, you need somebody who is interested in trying something new, open to change and willing to talk to other members of management and fight your cause.
Scheduling work between teams
If you have a project/product that spans teams, or teams still working waterfall, or simply need to co-ordinate with teams/departments elsewhere in the business you can run into problems scheduling when work will take place or just delivery of completed work.
To get around this the scrum master needs to engage with the other teams scrum masters/managers/product owners to co-ordinate when work will be done, delivered, ready for use etc.
The goal is to ensure that the separate parts of the organisation are able to deliver what is expected when it is expected, a side effect of this is that other non-scrum teams tend to start adopting some scrum practices to try and ensure they are meeting their commitments.
If the other teams are also doing scrum then it is usually just a case of ensuring the product owners, if they are different people, to understand cross team dependencies so that stories are prioritised correctly and which sprint they should be delivered in.
If teams do not wish to engage in the process you may need to follow the ideas in my last post in relation to scheduling work where a business arbitrator decides what work is done and when to ensure that the business works in a co-ordinated way.
Frequently business people are worried about the perception of the company by clients when they adopt scrum and the fact that the team is working in sprints so that delivery dates generally need to fit in with the sprint schedule and that this can be seen as inflexible because the team won’t accept changes to stories they are working on during a sprint.
In my experience the exact opposite is true, when you explain to clients that you are following the scrum process that they will be intimately involved, that the team will be delivering working software at the end of every sprint and that they are able to change the exact details of what they want up to the point where the story is included into the sprint then clients generally are very happy.
Scrum is no longer an unknown process, a lot of people in the business world understand what it is and if they don’t then take it as an opportunity to sell it to them, get them excited about the process and their involvement in it.
If the client is a little unsure their doubts usually fade when the team starts delivering working software, it inspires confidence that the software will do what they expect; react to changes that the client wants so that at the end of the next sprint they can see their changes have been implemented and their confidence will increase.
When people first learn about scrum, the ‘self managing team’, continuous improvement, etc people often worry about their role in the organisation, they fear their role will disappear and as such they will lose their job.
Its only natural that this will happen and the way to help people overcome this is educate them about the process so that they can see that although their roles may change they won’t lose their jobs.
People may not be happy with a change in their role and this is again where senior management support is required to help the individuals through any transition period to find a suitable role/position within the organisation as it transitions to a new way of working.