One of the biggest challenges with my current position is that there is a lack of buy-in for Agile. My company has decided that Agile is a good thing and is working toward introducing it to all developers. Agile really does not lend itself well to a top-down implementation. Given values of self-organization, shared concerns, and organic process, it feels wrong to force feed it to developers.

The team I work on gradually built up its current set of practices as a team. Things were introduced gradually and we learned quickly that small, incremental change was more effective than unilateral, sometimes arbitrary directives. We spent a lot of time working with the stakeholders in our company to explain what we were doing, why we were doing it and getting them involved in the process. We were not always successful our first time, but we managed to evolve as a team and to make things work successfully.

In contrast, top-down directives move very slowly through a company. It is much easier for a small group of developers to say “Let’s do a quick standup meeting every morning” than it is for a C?O to say “Here is Scrum. Learn this and use it.” Top-down directives start out vague and expect the Org Chart to figure out what is meant by the directive, to create a plan, and to implement it.

This is a non-starter in my eyes. If you ask an established PMP/Waterfall/Big Design Up Front person for a project plan to implement a new process, you are going to get exactly what they are used to giving you. They are going to spend a lot of time and energy designing a plan for a bunch of processes that may or may not work. The plan very well could be the best plan ever and completely work, but are you willing to bet your whole company on it?

One of the biggest problems I’ve seen with this approach is that there are not solid relationships established between different aspects of the company. If your sales, customer service, and professional services teams are not on the same page as your developers in terms of incremental release, product ownership, transparency, and tight feedback loops, you will have difficulties.

One of the advantages of already working with an agile mindset is that I believe that by “embracing change” I can help overcome these problems. I don’t mind the fear in a salesperson’s eyes when I ask if I can speak directly to a customer. I look forward to learning what it means to “capitalize” a software product as an asset. I enjoy listening to customer service people explain their problems to me and finding ways to help them out. This is what I do as a software developer.

At the end of the day, I’m glad that the company has decided that the way I’m already doing are things that should be considered best practices. I am thankful they are finally catching up.