We recently produced a webinar here at AccuRev, co-sponsored by Rally Software, about the Top 10 Factors for a Successful Agile Implementation. Next up is number 9, selecting an Agile Pilot team. We mentioned in our last post that the Pilot team is one area we need executive commitment on. The next logical step in the Agile adoption process is getting the right Pilot team to use the Agile methodology successfully.
The success (or failure) of this initial Pilot team is really going to hold the success of your Agile adoption across your organization. If this team were to fail, people are going to view Agile as a methodology that fails, and not necessarily the team itself. So this could hinder or even kill the adoption of Agile across your organization. Choosing the Pilot team is a very important first step as we start to move towards Agile adoption and implementation.
Once again we’ll require support from upper management, but this time because running an Agile pilot is going to impact the teams around this Pilot team. It’s going to impact their customer base. It’s going to have resistance from some developers in the organization and management in the organization. Everybody feels a bit of resistance towards change, right? Agile adoption is something that’s going to make us better, make our product better and allow the ability to deliver better features and better products to our customer base.
One area that I want to talk about is that the team needs to be properly trained and coached. I mean this absolutely, sincerely. I’m not talking about, “Let’s get one of the guys in my organization an Agile book and have him read it and then go teach the Pilot team on how to do Agile.” I’m talking about a professionally-trained organization from somebody that knows how to do it, from somebody that has done Agile development before. Someone who knows its pitfalls and can actually lead and educate your team on how to do Agile and how to do Agile right. That’s very, very important.
Next, the team should be committed to delivering features. The reason for this? One of the common pitfalls during Agile adoption is going after too big or too small of a product. To alleviate this problem, get the team to commit features, going after one particular piece of a larger product. For example, let’s say maybe you have a product that has a GUI portion, a Core portion and a backend database portion. We might suggest you go after the GUI portion of that particular product and allow that team to go Agile, so as to see some immediate and very visible results. Again, this is a great way to deliver something concrete, to see commitment, and to see goals being achieved. This is all based on selecting the right project for adopting Agile as a Pilot.
There are actually four areas of importance when considering a Pilot team; Duration, Size, Importance and Senior-level sponsorship. What I mean by duration is identifying a project that is not too short, but not too long. We don’t want an extremely short project so people don’t have time to settle into a cadence and I don’t want to select something too long so it takes forever to achieve a goal – we might suggest 2 to 3 months.
We also want to look at the size of the team. We don’t want it too small or too large. So we’re looking at a single mid-size team. Too small, and people might think, “Agile worked for that little, small Pilot team but is it really going to work in our larger development organization?” And too large may give too much complexity for that first Pilot team. So it is good to start with a single mid-size team – need I mention the 7 +/- 2 rule?
The level of Importance of the project is critical to the visibility of success. The project that they’re working on should be important to the company. The GUI project that I mentioned, very visible. They have to succeed or there’s going to be a major problem with the product. So everybody is motivated to have that team succeed and when they do it’s going to be noticed. Success or failure… it’s going to be very VISIBLE!
Lastly is the Senior-level sponsorship and having a key business sponsor to back up the Agile Pilot team. As we run into resistance or we run into problems, we need to have somebody there to fight the good fight and to smooth those things over. Remember, this is the direction of the organization and it is in the best interest of the organization.
Great, so we’ve selected our Pilot Team… now what?
Yup. It’s true. The tried and true development approach of Waterfall that we’ve been using for years was an example of what NOT to do for software development.