In my previous employment as a software development manager I decided, for reasons now irrelevant, not to implement Scrum "by the book". Instead, I implemented a continuous improvement process. Since the team believed in agile development and I am familiar with its concepts, things evolved in the right direction.
A year later I realized how close our process was to Scrum, making me wonder if we would have reached the same process faster by beginning with a "big M Methodology Implementation" of Scrum and letting the continuous improvement that is core to Scrum drive us from there.
When I joined Salir.com, I found myself managing a development team which completely lacked any process. We were essentially in "code and fix", management had a poor opinion of the team's productivity, and the team was burnt out by management's pressures and lack of appreciation.
So I thought there was little I could break and decided to implement Scrum "by the book". It took 1 sprint to hone things out, and on the second we were doing Scrum pretty right, according to this scrum checklist.
3 months later, the results are astonishing. The team has re-gained management's appreciation, and productivity is perceived as orders of magnitude higher.
I have concluded that, when the current process is unsatisfactory, implementing agile "by the Scrum book" is better than doing it gradually.
5-dec-2009 update: I've stumbled upon a posting where Rachel Davies advocates the gradual approach -- and where she discusses the criteria that should guide the decision for one approach or the other.
Showing posts with label scrum. Show all posts
Showing posts with label scrum. Show all posts
Thursday, August 27, 2009
Subscribe to:
Posts (Atom)