Agile is getting hot. Really hot. But not all companies have adopted these principles for software development. That's my situation. I work in an area that's just starting to leverage Agile. One of my past contracts developed strictly in a waterfall environment. It was heavy with process and difficult to manage the red tape. Needless to say, it was riddled with a ton of overhead and regulations that did not allow for much flexibility. Though multiple project process failures and persistence on my part and a few others trained in scrum, we finally were able to get some buy-in to the Agile process. There were a few things this company did absolutely correct to enable success and I've tried to carry these forward into my new contracts.

The Nudge

Taking the experience I've had in working with companies that are learning to adopt Agile principles, combined with the training I've received, hopefuly you can leverage these lessons in your space: 1) Educate all management - whenever you try to sell a new idea of any kind, you must educate everyone this idea may touch. If you are going to bring a new methodology into an organization or group, you need to get buy in. This can be accomplished in many ways including standard presentations and conversations. I took a grass roots approach to bringing it in. Just leveraging a few things to make a subtle change can sometimes be enough for management to get curious. You also need to know your numbers and stats. While words are great, management typically needs something to measure potential success by, or failure. If they can see a comparison between where they are now and where they could be, they may get interested.  Find some good resources (like mountain goat software) and let those organizations support you. 2) Listen to the fears - When speaking to management or anyone taking part in the change, listen to the fears. They are real. If you can't get past them, you can not be successful. 3) Get training - Make sure that if you are attempting to bring a new method into an organization, you should have some training yourself. It is also essential that the entire team (including management) should be trained in the method you want to use. Training will help the team to get comfortable with each other, but it will also help to eliminate fear for the masses. Training will also be a sign from the organization their investment in the process. If they are not willing to provide training or purchase it, then they may not be very ready. 4) Get a coach - Encourage the organization to bring someone in to help guide and direct once the project gets started. This outsiders perspective will be extremely beneficial to the team. They typically can cut through the red tape of organizations and help get the team and management off to the right start.  They are the objective resource that can define things for clients in ways that will leave your relationship in tact. 5) Get a team commitment - Most agile practices subscribe to a dedicated team. It's essential, although may be seen as too expensive or not practical for the company to handle. Whatever the commitment, document the status and potential impacts/risks in case you can't get a team full time. 6) Collocated - Can you get in one place? While teams can work in different areas, it is a large challenge. If the leadership is not committed, this will make it even tougher to move forward. If you can't get everyone in one place, try to secure a room that enable the team to focus together whenever they want. 7) Advertise - Advertise everything. It's not just enough to get management and the team to buy in, you must get everyone else to as well. It's important to become a PR representative for your team. You must find ways to communicate out and up (and down). You need to create value, because it's typically not seen right away. 8) Set up guidelines and expectations - Loosely, make sure you have expectations created for the team. If you are bringing something completely new in, make sure the entire thing is documented. Some examples are how cycles work, planning effort, product backlogs vs. iteration backlogs, how to document etc.