Over the past several years agile techniques, including Scrum, have become the predominate way that software is produced in organizations across the world. Of course that wasn't always the case. Early on during the transition there were a lot of hotly contested debates between the pro-agile crowd and the traditional project management/waterfall crowd. Today if software isn't developed using agile techniques it's definitely an exception to the norm.
Similar to how there was a transition from waterfall to agile in software development, we appear to be in the early stages of examining alternative ways to structure organizations. And just as there initially was a lot of resistance to agile principles, there is similar resistance to changing organizational structures. Some of the newer concepts include flattening/removing hierarchy, revisiting the role (and need) of management, removing centralized authority, and challenging the ways that organizations make decisions just to name a few.
This resistance is often caused by several factors. Often there's a fear of the unknown. When people don't fully comprehend a new concept, often instead of researching the subject they simply fill in the blanks with whatever their imagination comes up with. Additionally there's can be a fear of losing control. If you are in a position of power, a challenge of the status quo means there's a chance that you might lose the control that you currently have. Of course it's reasonable to question things and not blindly accept what you are being told. However, if you're not well informed on the subject matter, you're simply not capable of having an informed opinion.
While many of these concepts are controversial, and there's no general consensus (yet) as to what approaches are best, these emerging movements do indicate that there's a lot of ways to improve the way that organizations are run and structured. Actually it would be rather foolish to assume that there's no room for improvement. Much of what we do today is based on industrial age management practices and we've come a long way since then.
Many of these ideas have merit, while others may not pan out. I'll save those discussions for future postings. Rather I'd like to draw on a story to help illustrate a point. About seven years ago I worked for a company that was transitioning from traditional project management techniques to Scrum. While the developers were on board with the changes, there was resistance from the QA lead. He was used to having detailed specs from which to draw up his test plans. As we were now starting to be agile, the exact nature of the UI was not defined and it could change during the course of a sprint. He argued that this made testing more difficult, and that as a result we should change how we ran our projects. Another developer on the team brought up a point. "It's our job as a group to efficiently produce high quality software. If you are unable to do so using your current techniques, you need to change."
His point was blunt, but it was a good one. We were changing how we developed software as it was a better way. Just because it caused him to change, it wasn't a good reason for him to hold the rest of the group back. While he might have to relearn things, it was what was needed. He could accept the need for change or could be stubborn and continue to resist. At this point the world had changed; it was up to him if he wanted to move forward with it.
Just as the QA lead had to decide if he wanted to change, so will organizations as they continue to compete. We changed how software was developed, to the betterment of the organization. Some team members had to change how they had done things for years, and it was a challenge. In the same way organizations have the opportunity to change the very way that they are run and structured. Just because things have been done a certain way for a long time, isn't a good reason not to change. There undoubtedly will be resistance, although ultimately the organizations that adapt will have the best chance to succeed.
Similar to how there was a transition from waterfall to agile in software development, we appear to be in the early stages of examining alternative ways to structure organizations. And just as there initially was a lot of resistance to agile principles, there is similar resistance to changing organizational structures. Some of the newer concepts include flattening/removing hierarchy, revisiting the role (and need) of management, removing centralized authority, and challenging the ways that organizations make decisions just to name a few.
This resistance is often caused by several factors. Often there's a fear of the unknown. When people don't fully comprehend a new concept, often instead of researching the subject they simply fill in the blanks with whatever their imagination comes up with. Additionally there's can be a fear of losing control. If you are in a position of power, a challenge of the status quo means there's a chance that you might lose the control that you currently have. Of course it's reasonable to question things and not blindly accept what you are being told. However, if you're not well informed on the subject matter, you're simply not capable of having an informed opinion.
While many of these concepts are controversial, and there's no general consensus (yet) as to what approaches are best, these emerging movements do indicate that there's a lot of ways to improve the way that organizations are run and structured. Actually it would be rather foolish to assume that there's no room for improvement. Much of what we do today is based on industrial age management practices and we've come a long way since then.
Many of these ideas have merit, while others may not pan out. I'll save those discussions for future postings. Rather I'd like to draw on a story to help illustrate a point. About seven years ago I worked for a company that was transitioning from traditional project management techniques to Scrum. While the developers were on board with the changes, there was resistance from the QA lead. He was used to having detailed specs from which to draw up his test plans. As we were now starting to be agile, the exact nature of the UI was not defined and it could change during the course of a sprint. He argued that this made testing more difficult, and that as a result we should change how we ran our projects. Another developer on the team brought up a point. "It's our job as a group to efficiently produce high quality software. If you are unable to do so using your current techniques, you need to change."
His point was blunt, but it was a good one. We were changing how we developed software as it was a better way. Just because it caused him to change, it wasn't a good reason for him to hold the rest of the group back. While he might have to relearn things, it was what was needed. He could accept the need for change or could be stubborn and continue to resist. At this point the world had changed; it was up to him if he wanted to move forward with it.
Just as the QA lead had to decide if he wanted to change, so will organizations as they continue to compete. We changed how software was developed, to the betterment of the organization. Some team members had to change how they had done things for years, and it was a challenge. In the same way organizations have the opportunity to change the very way that they are run and structured. Just because things have been done a certain way for a long time, isn't a good reason not to change. There undoubtedly will be resistance, although ultimately the organizations that adapt will have the best chance to succeed.
Comments