On the surface it may seem much easier to start building new Agile teams from scratch. Our situation at Borland was such that the company had a crucial need to greatly improve the reliability and predictability of the development organization. We were about to embark on new development in a new location and thought it a perfect place to start. Agile development appeared to be the best choice for injecting continuous change and improvement into the development organization and we thought the best way to start our transformation would be to build a model site from scratch. This site would then serve as a baseline culture that we could roll out across our four other development sites.

We quickly discovered the task was not nearly as simple as we initially thought.

First, we had to put in place a core team of a few developers, a technical writer, and a quality assurance engineer. During the selection process each candidate was screened relative to his or her understanding or experience with Agile. However, given the specific engineering skills that we required and given our time constraints, we were simply unable to start with a team of seasoned Agile practitioners. My guess is that this will be the case for most organizations taking the first steps toward Agile adoption.

What we learned is that if you’re building a new team and your technical interview team has limited experience with Agile, it’s a good idea to include an Agile consultant in the interview process. He or she can conduct an Agile skills assessment and determine whether candidates are a ‘cultural fit’ to adapt to the Agile principles.

Once the team has been selected, the first step is to make sure each new team member has some level of understanding of the Agile principles and how to implement them properly. In our case, with no real-world Agile experience and no Agile “purist” among the interview team, it quickly became an issue among the team members as to whose interpretation of a principle was correct. The best way to implement said principle was also up for debate.

While Scrum and Agile training can do a great job of getting team members up to speed on Agile principles, it is limited in its ability to help the team understand the best way to implement them–especially when the pressure is on (and when isn’t it on in a real-world development organization?)

When you have a team of people that are somewhat new to both Agile and the company, keeping them aggressively moving towards a business goal while remaining true to Agile principles can be difficult. The reality is that people tend to revert back to behavior that has personally served them well in the past, which can have negative results if not checked. For example, the “hero mentality” (the lone developer that can solve any problem) is not conducive to building strong, self-organizing teams. Another example is that often people who have worked within a traditional technical hierarchy tend to revert to authoritative decision making.

Change is difficult. Period. And it is especially hard for people to change deeply ingrained habits and behaviors; even more so when they are under pressure to deliver. However, in order to reap the longer-term benefits of Agile you need to make sure that the team is generally adhering to the principles. You, as a manager, must keep in mind that the long-term goal is to improve overall productivity and team performance--not simply to implement Agile. While this may mean some short-term losses in terms of efficiency and productivity, the end result is worth it.

To solve our issue, we decided

You do not have flash or javascript support.

Average (1 vote)

Reply