9
Jul/08
0

Driving Changes, For What?

A while ago I was driving loads of changes to our team, but now when I look back at them, most of them didn’t really succeed.

Most of the time I noticed that only thing we needed was a little kick now and then to remind people about ‘that thing’. We didn’t need full processes, we only needed some simple guidelines to follow. I started driving these changes because I had seen similar things working in big corporations, even I had used them, but those didn’t work in a small dynamic team. In short :

  • Most of the changes backfired.
  • Those changes that were driven didn’t get implemented as imagined.
  • Don’t asume something is going to work only because it is working for somebody else.

What was the ultimate problem in here? I didn’t know what the team wanted – how did they wanted to do the development?

After that I have learned to listen the team better, I do not drive any unnecessary changes, or at least I try to avoid doing that, neither I drive any specific development methods like Scrum. Rather driving things I want to introduce new things to our team, that way I’ll be able to see very fast if the new thing is going to get any wind under its wings or not. Also this faster than starting to driving things that will probably fail, I have more time to do real development and let the team decide if the change is really needed.

The goal of development processes is to help the team improve, to make high quality products faster.

Post to Twitter

Comments (0) Trackbacks (0)

No comments yet.

Leave a comment

No trackbacks yet.