I guess we are all more or less used to working in rapidly changing environments and this has basically become the standard nowadays, there is no turning back anymore. In software development constantly changing requirements, surprising customer needs and personnel leaving and entering the ongoing project are no news to anyone. Not to mention organizational changes. It’s just how things are, and we need to cope with it, right? In a sense yes, one either goes with the flow and adapts or, well, drowns. On the other hand, with proper guidance no one needs to drown but to stay afloat and keep on going.

Especially when a company shifts from the traditional way of working to a new one the transition period can be rough. I have witnessed this a few times when agile or lean processes were introduced to replace whatever was in place before. In most cases the ideas behind the change are valid and well justified. However, the implementation of plans on grass root level is not all fun and games at all – reality does not match the theory.

“Most times the new process dribbles in, bits and pieces are taken in use while still keeping parts of the old model.“

How do workers see what is going on? Usually a high level Director makes the announcement and gives estimated timelines when everything is in place and operations running better than ever, some training follow and that’s it. “More information from your managers” is the usual closing line. Soon after, either department by department or all at the same time, the new model is in place. And here lies the issue. Most times the new process dribbles in, bits and pieces are taken in use while still keeping parts of the old model – since some parts are supposedly better to do that way as long as the new process is properly in place and proven robust. Developers, testers and managers alike try to keep up what is going on and how things are done. Implementation and schedules are replanned, and at the same there is the everyday work to be done.

“If transitions were easy, I wouldn’t be writing this.“

What can be done? If transitions were easy, I wouldn’t be writing this. Usually there are valid points for changing ways of working, I’m not saying that. It’s just that how the change seems unprepared and even chaotic. There are questions as “should we as a team learn this by doing, or with a mock-up project on the side”or “instead of company-wide hassle should this be in place with projects X and Z first” and “how is is possible the guys next door do not know this and do not follow the same process as we do”. I understand the costs and time it takes to fully train and prepare staff to have a new perspective on how they work but it feels in the long run it would be better.

People are different. I give you that. Some learn everything by attending a few classes, some need to study on their own time and some need hands-on experience. Whatever the way, I strongly feel that by first introducing new processes to workers without the pressure of delivering actual products, and giving them a chance to peer-to-peer training, it is possible to scale up the usage of whatever is new. It does not happen by drawing boxes and diagrams and saying “make it so”. There is always some grudge against any changes, that is the human nature. By changing how people feel can smoothen the transition since everyone already have begun the adjustment. So, all in all, start from the bottom up. And start early.

– Sampo

• Blog
|
• Software development