Scrum resourcing woes

I ran into some interesting problems when implementing some Scrummaging practices. One problem that I faced had to do with idle time of projects members.
The company I’m currently working for does its projects using the waterfall approach. The structure of the company supports the waterfall, the way of working of
the individual departments, their geographical locations, the strict separation of roles etc are all optimized for the ‘throw over the wall’ culture.
After some evangelism some managers got convinced to give Scrum a try on their projects. The projects had started about a year ago, but in that year they
had been working on architecture and requirement documents. So everything up till now was waterfall oriented. Funding was ‘fixed’, functionality was ‘fixed’, release date was ‘fixed’ etc. Now that we had the architecture and requirements we ‘only’ needed to build the system.

Once we got started with actually implementing Scrum, the first thing we did was to ask for project members. We hired testers, designers, developers, integration specialists etc. Because the project uses various technologies we had to get developers, designers, testers etc for technology X and other
developers, designers etc for technologies Y, Z etc. When faced with this I realized that it was not going to be an easy task to create teams where people can
take over each others work or even help each other out. We ended up with three Scrum teams. Each a cross functional team specializing on a particular technology. Not ideal, I would have liked to had cross technology teams, but that was the best we could get. We got the teams seated together as much as possible.
We helped our PO get a product backlog, did our estimation and sprint planning meetings and we were ready to go……
During one of the early stand-ups:
Team: we cannot test a thing!, Scrummaster: why can’t you test? Team: well, we do not have any testing environment set-up. We asked ‘them’ for one and now they are working on a offer. They’ll send it to us within two weeks. Once we accept their offer and sign it, it takes a few more weeks for them to setup the hardware, configure it etc!!!!!
Oeps, the team has a demo in three weeks!
Scrummaster: Ok, what can we do? Team: we can test and demo on our development environments!
The teams are ready to go…..
Team: we cannot completely develop our functionality!, Scrumaster: why can’t you develop? Team: well, we do not have the right permissions on the application, databases etc so we cannot deploy a thing. We asked ‘them’ for the permissions. They said it’ll be done within two weeks.
Oeps, the team has a demo in three weeks!
Scrumaster: Ok, what can we do?, etc etc etc
There were a lot of these kind of issues. To solve these issues the teams completely depended upon other departments.
Because the organization is waterfall oriented these delays were no problem ’till now. When the architecture and high level requirements documents are ‘done’, you claim
a few requirements analysts to deepen the requirements. Then you get them of your payroll and hire a few designers etc. At the same time you apply for the hardware, permissions etc. By the time the requirements and design phases are over, enough time has passed and the other departments had enough time to provide the things needed by the project. By the time you get to actually developing software all infrastructural issues etc are resolved. And all this time the project have had a small number of people on the pay roll.
One of the projects failed three consecutive sprints because of these issues. The other project had a lot of idle time during the first two sprints
but finished them successfully. On both projects the managers opinion is that partly thanks to this Scrum approach a lot of money was wasted. Not a good start when you’re in the first steps of implementing Scrum. You need success so that in a next project you can implement more Scrum in the organization!!
The lesson learned here is that we should have identified and solved these kind of organizational impediments before starting with the Scrum part of the project. Do not hire a lot of people until you have these fundamental issues resolved…. Having a sprint 0 would have been very handy indeed. In this particular situation you use it to identify these organizational impediments and come up with a solution for them. Once you solved these issues and the teams can actually start, then its time to put them on the payroll and start using Scrum.