Some challenges that I have encountered as an Agile Coach working in large organisations adopting Scrum and how you could approach such a scenario.
We want to adopt Scrum, but we are not willing to change anything
There is often a belief that brining in Scrum is going to be just a set of new practices for the development team and they can get benefits without changing anything. I have discovered that it is best to address this one early with the organisations senior team, otherwise they will be wasting their time. So education is important, a workshop with senior stakeholders usually does it, just getting them thinking what it will mean for the organisation to deliver working software in vertical slices rather than building it in layers, what will it mean for the organisation to have dedicated teams. These initial workshops help me and the client understand if they are ready for Scrum.
There can be only one
Different change initiatives sponsored by different members of the executive team, this can be particularly painful if you are working with the organisation to move them towards agility, but you discover some other change initiative designed to get control by introducing more management and more structure. There can be only one change initiative, therefore work to join them up, however if they are in conflict work with upper management to see what is most important for them now, sometimes organisations need to take a step back before they are ready to move forward. Just make sure they have the information to make the right decision for them.
The Agile antibody
Sometimes there will be executives who say they are behind Scrum, but behind the scenes they will be fighting a rear guard action to protect their domain, maybe even trying to kill off Scrum inside the organization. This is not always obvious at first, but it will become so when teams struggle to work with their area of the organisation. We obviously want them onboard, so an approach I would use here is to try help them understand how they could benefit from a new world using Scrum. For example the head of testing may be interested to know how in Scrum testing is central to the development process, that they would have much more scope to influence the quality of the products.
This post is republished from my old blog
At the Munich Scrum Gathering (2009), Harvey Wheaton from Supermassive Games did a presentation entitled “Growing Self Organising Teams”, which was exceptional and I found it very inspiring, the presentation can be found on the Scrum Alliance web-site. In the presentation one slide caught my attention and it was how the team had used a Cool Wall, inspired by Top Gear (popular car show in the UK). I thought that would be an excellent tool for a retrospective and used it at the next opportunity, this is how I used it. Picture not great, but you get the idea…
Using the Cool Wall to Gather Data
The team was asked brainstorm team practices/team customs/patterns/ways of working, each team member then took it in turn to add their practice to the cool wall, and share it with the rest of the team. Sub-zero was for practices where the team felt they were world class, seriously un-cool was reserved for practices that really weren’t working.
I then asked the team to vote for the practice they wanted to work on, I had forgotten my sticky dots so we used marker pens. The team actually picked a practice from Un-Cool as the stuff in seriously un-cool was out of their sphere of influence and the ScrumMaster was dealing with it already.
Using the Cool Wall to Drive out Actions
Once we had selected a practice we had some discussion to understand the root cause. We then moved to generating actions by asking ourselves what we need to do to move this practice one column to the right. Remember you only want a few actions otherwise nothing will get done.
To keep with the car theme I then asked the team to say given their project, what mode of transport they most felt like.
The approach worked well and really helped to create a picture of the work the team does, and uncovered loads of stuff that the ScrumMaster could work on to help the team improve. Also we only spent an hour doing it.