The situation is common. Adoption of the new architecture has been slow (or non-existent). If you are to hit your roll-out targets, you have to find a way to accelerate it. But for some reason, no one seems to be picking up your latest advancement and rushing headlong into a new type of implementation. At the same time, no one provides any significant reasons for this reluctance. The feedback does not call out weaknesses in your design. In fact, the little feedback you've received was positive. It's just that they choose to roll-out new functionality using the old, tried and true approach. Since you have spent the majority of your time nurturing this new architecture, you are personally invested. Your frustration starts to build as you see opportunities missed and weeks pass. After some time, it begins to feel as if the reluctance is just an unspoken, negative judgment of the new stuff; of your new stuff.
In fact, the real reasons that the adoption is slow has very little to do with the architecture at all. The slowness is understandable and you really should have predicted it.
The choice of which architecture to implement can be made weeks before the design phase of a project even begins. It is made when the development team is first asked to size the effort. Is it small, medium, or large? These early sizing estimates carry with them many unspoken assumptions. One of those is the inherent assumption that the new solution is built using the current architecture methods. the development team bases their sizing estimate on their experience from the past, and that experience was with the old stuff. So, the architectural status quo is inherently selected from the onset of the project. As the project gets further down its time line, this direction puts down roots and is more difficult to change.
Undeterred, you keep selling the new architecture as the second coming of sliced bread. The project has started to roll, so a plan is taking shape. There are already dates. The new way sounds good, but developers can already see schedule risk. Has this new stuff been used before? Is it fully baked? Can it fit within the original estimates? The most common developer concern is whether the architect will stand beside him and be accountable for any cost and schedule overruns. Can it (or you) be trusted?
The developer will start to balance these risks against the benefits to them. Unfortunately, new architectures do not always benefit the developer. The new designs may improve a dozen areas of the system, but ask the developer to implement more complicated code to realize those benefits. When developers don't see the value first hand, they may start to question the direction again. The newness of the approach can cause misunderstandings, frustrations, and re-work. The new architecture starts to get labeled as more difficult to use, slower to implement, or providing no real improvement over the existing approach.
A better way to come at this situation is to introduce this change from within the development group.
To begin this process, you must identify the architecture change leaders in the development group. Every group has one of these. This person is passionate about finding better ways to do things and willing to share those ideas with the group. They attend conferences, read blogs, and challenge you on your ideas. When you ask where they expect to be in five years, often their answer is "In your role". These are the junior architects, but they are still in the developer ranks, and that is important because other developers see them as one of their own.
The second step is to truly inform this change leader about the new architecture. If you have picked the right change leader, they will be excited to understand it better. Go over the primary benefits that the new design provides and explain why those are important from a business viewpoint. Explain all aspects and be honest about the trade-offs that are made in the design. Make sure that you cover the common objections that a developer might have to the new design, since they will likely hear them, too.
You also need to listen carefully to what this person thinks about the new architecture. Consider carefully whether any of their suggestions could and should be implemented. Any new system is not perfect, and a sincere consideration of suggested improvements will foster teamwork between you and the change leader. They may have a better appreciation for how the architecture fits into other areas like configuration management or deployment administration.
Having done all this, you are then left with a much more willing participant in your roll-out. They will be eager to apply the technology since they understand the benefits better. They will be more prepared to create the best implementation, and will keep you informed as to their progress without direct oversight from you. If issues pop up, they will work closely with you to resolve them not only for the project at hand, but for the benefit of the architecture itself. They have been transformed into a stakeholder and will carry this attitude back to the development group. There, they are seen as a trusted resource with highly regarded insights about the new stuff. They become your architecture's primary evangelist and knockdown the obstacles standing in the way of its adoption. Suddenly your latest architecture starts to find new life. You have infected your development group with an "adoption virus".
0 Response to 'Infect Development Groups with the Adoption Virus'
Post a Comment