Successful Agile Teams All Buy Into a Process
Joining a team that doesn't know or is resistant to Agile can be as unpleasantly shocking as jumping in a pool right after the jacuzzi. You see people spending hours planning and committing to every hour that that will be working in the next two months. You are given hard deliverables like mockups and copy that are not intended to ever change. It is evident right away that it is not possible but the team accepts the task because it appears that they have no choice. Things will get done at the end of the sprint but mostly because the team all decided to work together to pull off a miracle. They worked all night and negotiated with the business to extend the time or change requirements. When you think of the amount of teamwork that goes into making a waterfall project appear successful, it is a shame the effort went into politics and not the software. The most important thing is to make sure that team is still pulling together to make the project a success and that means that you, the agile snob, need to be involved. You can not be resistant simply because you know a better way because agile requires the team to be a unit and the team will simply not follow you at this point. The truth is that your teammates may have already invested hours making tweaks to this process to bring it where it is with the company's political environment in mind. There are a lot of valuable lessons already learned in your teams current process and a brand new agile process would fail without them. So you need to commit to the existing environment and learn how to do it as well as possible before you can suggest change.
Some say that Agile is not the right tool for all projects. Packaged software and database administration cannot be done iteratively. I could go out on a limb and say that Agile can be used anywhere, though specific disciplines like Scrum and XP are specifically designed for development of large web applications and will not always be ideal for other types of projects. Kanban is an interesting example of an Agile process adapted from the automotive industry, leaving behind the traits that don't apply to software. Strengths in your process will be inherited while others will be adapted or discarded. It may not be practical for your team to ever move to a specific agile style but instead you will develop your own Agile style.
Larger projects can be especially difficult to convert to Agile. Projects where their are teams whose members are, sometimes a world away, are common in large companies. Tools like the scrum-board, are only effective when a team is in the same location. Creative solutions need to be developed to bridge the gap between time zones and cultures to create the camaraderie you need for a successful unit. I honestly think that the most successful teams will be in the same room every morning for a stand-up meeting, and you will compromise a little bit with every constraint. It is up to the business to balance the varying degrees of value in having a distributed team against the efficiency of a unit. Regardless of what the business decides we have to make it work and I have seen some great efforts to bridge the gap. In my current role, our two distributed teams meet after every successful launch in one of our cities and share a lunch. We also have a simple online tool that provides us with a focus of progress. This is like our Scrum-board but it obviously does not provide the personal connection. We can see our teammates progress at a glance and the interface makes it simple to update our status for all to see.
Some important players in the waterfall process are the heroes. They are team members or managers that take on most of the political burden for the team on one or many subjects. These people are the glue between each of the functional silos. These people talk to designers, developers, and testers day after day and really keep the trains arriving on time. Most of the cross functional communication is facilitated by these hero figures. The downside to being so dependent on heroes is that without these people, the project would halt. These are the only people that have a consistent view of everything that is happening in their function. Moving to an agile process means that the silos in your process will be removed and there should never be a need for one person to be responsible for communication between the team members. The people who were once the heroes are free to develop or if a manager, remove roadblocks that are raised by the team as needed. The team and the stakeholders will not be comfortable breaking their dependence on this figure. Team members would have to assert themselves more and the business would have to trust them to make the right decisions but a process dependent on anything less the whole team is not agile. The change needs to happen slowly with each member of the team pitching in on something outside of their area of expertise. I know it is easy to let the heroes keep doing all of their magic behind the scenes, but everybody will benefit by learning what they do and simply getting involved.