Introducing Scrum in a company: when is the time to hit the emergency stop button?

I'm writing this blog entry after my experience when trying to set up a scrum-like process at my current company. I recently stopped my efforts and want to discuss with you how you estimate: When is the time you must admit you failed or simply when is the time to stop fighting?

But back to history: After some painful project failures last year I enganged a little bit into agile software development and read a lot. Like many others I was immediately fascinated by the idea and concept (and I am still). So my boss asked me to take four colleagues for three months to evaluate different processes and develop a software development process fitting our department and company. We developed what's called a "Scrumbut" - Scrum with some adoptions to local structures and a little bit of more focus on planning than in "classic Scrum". Well done, we reached our goal at the end of March and then were heading for the first project to show how the process works. I was engaged as a Scrum master for that project and already had some struggles with the dedicated project owner not willing to write user stories but write hundreds of requirements instead. As time went by the PO started to see the sense in user stories and slowly started with my help to write some stories from the requirements. I know it's not the best to approach like this, but when you introduce the process new to department and people you have to do some compromise. I am not an experienced scrum master neither, so we both tried our best. After some first frustration we both (PO and me) found out how we could turn most of the requirements into user acceptance tests and were quite amazed. So this started to evolve and I was eager to take the further steps: After estimating the business value presenting the PO's ideas to the developers and letting them estimate the effort of the user stories (planning poker). This was when I was confronted with the following facts:
  •  Actually there was no development team available. Instead of taking our guys and start developing the first user stories they were all engaged in other projects which should have been finished long time ago.
  • My boss is hot for outsourcing. That's what he's really planning. So the head of development - a guy which I had some severe conflicts last year with up to the point of no way to reconciliation and eternal war - pointed out he'd like to approach the project like this: Taking only two of his developers and let them do the estimation job. Do the development offshore and those two guys would write the tasks for the offshore developers.
  • My boss had further plans with me: Knowing that I would clash with the head of development sooner or later he chose to give me another task. I should find somebody taking over and do the job of the scrum master.
Knowing all this I pointed out to my boss that the chosen project wasn't probably the best fit to try the new development process with. I argued that if we proceeded like described we'd try to do too many steps at a time. As far as I understood outsourcing isn't impossible with Scrum, but at least it won't make things any easier but often too complicated. I understood that companies which are already adept with Scrum and use the process successfully since several projects might try to do the outsourcing step. And even then such projects frequently fail due to the difficulties arising when trying to do an agile process with distributed teams. I don't say it's impossible, I've read there are examples where this really worked. The only thing I'm trying to say is when you're totally new to the process and try to make your first steps, outsourcing is like trying to fly loopings when you're having your first flying lesson. It's almost a guarantee for failure.

My boss shared my point of view and admitted that this project wouldn't perhaps be the best fit for the new process. The only frustrating thing about it: Things won't change for other projects. We have no developers of our own as well for the other projects.

The following points were the killer criteria for me to stop engaging:
  • Not having a development team at hand
  • Not the offshore developers do the estimations but some "coordinating developers" in Germany (those two colleagues named)
  • There'd be no team work but the old command & control like approach instead: Colleagues here'll do the brain work, offshore people will only do the programming, just like assembly line workers, with no brains of their own inside, no concerns, no questions, no vision. This is supposed to fail in my eyes.
  • No scrum master available: Nobody at hand if I don't do the job. Nobody trained to do it. I'm not too sad about leaving this project as it will separate me from the head of development. I'm done with that guy.

What I'd like to know if you think that trying it with outsourcing would have been an option for you. What would you have been doing? How about all the consultant people: How do you handle such situations? I know there may be some prerequisites within our company already dooming the project. Anyway I'm not the person giving up too early. Do you share my concerns and can you follow my reasons to stop this project (for myself)?

I'm excited about your comments.


Cheers,

Stefan

Kommentare

  1. I have read your blog and i got a very useful and knowledgeable information from your blog.its really a very nice article,about the oracle on-line coaching supplier gained the high commonplace name through worldwide for its teaching.
    Oracle fusion financials training

    AntwortenLöschen

Kommentar veröffentlichen

Beliebte Posts aus diesem Blog

Using a shared local network folder in a Windows environment as Git repository

Migrating an old .NET application including Crystal reports to the new world: A tale from the valley of sorrows

Using the MOQ framework to compare objects or: why equals are (not always) equal