“Get an inside peek into internal Microsoft development practices as Chris Adams documents his team’s move to Agile using Team Foundation Server (TFS) 2010, starting out with the Microsoft Solutions Framework Agile v5.0 process template and eventually switching to the Microsoft Visual Studio SCRUM 1.0 template.”
In a recent issue of MSDN magazine, I wrote about our team’s journey to Agile software development and I wanted to share that it was released. I’ve written a lot about experiences our team has gone through in trying to move from a waterfall style of development and to a more iterative approach using Agile techniques – powered by TFS 2010. Using Agile inside of Microsoft is, to speak softly, like trying to turn the Titanic 90 degrees in 60 seconds – its “tough” if not nearly impossible. The reason I say this is that it works great for “a” team – it really begins to become a challenge when you are partnering with other teams to build software as many teams have their own “process.” The team I lead is fighting it and doing our best to move to an Agile model.
Inside Microsoft, you find a lot of “Agilebut” or “SCRUMbut” engineering teams. If you aren’t familiar with this term it simply means that you are doing some form of Agile but not these parts of Agile. I find that many of the teams are saying that “we don’t write functional specs” so we are Agile which is ironic because no where does it say you have to stop writing specs. In fact, Agile doesn’t have a “rule” of no documentation but instead just says it values people interactions over documentation. This is the Agilebut methodology that is rampant across the world.
The one thing I will tell you, which is completely my opinion, is that aligning to a specific type of Agile development process and locking into it is your first mistake. The competition between several types of Agile, for example, SCRUM vs. Kanban, is absolutely nuts in my opinion. If you are adopting SCRUM, you must do everything SCRUM says or your not SCRUM?
Let’s look at the definition of Agile and talk about it –
The key point to look at there is the fact that it says to move quickly, but with control and skill. Agile teams have a huge amount of discipline when they are executing properly. The first mistake I find is that you are making is trying to find a specific-type of Agile development to align to. Instead, find what you like about any of the methodologies – whether is in XP (Extreme Programming), SCRUM, Kanban, – and make them a part of your Agile process. We are closely aligned to SCRUM but … we don’t have SCRUM Masters, or Product Owners. We have Program Managers, Developers, and Testers. We aren’t changing our titles so that we are now using SCRUM. Guess who runs our daily stand-ups? Program Managers. Guess who drives our interactions with customers? Program Managers. Adaptive nature is the best strategy I’ve found to allow Agile to fit into your team, your organization and that is exactly what we are practicing each day.
For our software development team, we document our process in a document called the “Master Agreements” that we continually update and discuss. It is the agreement that drives understanding of our process, our dynamics, etc. and is a summary of the methods we use for development. It will consist of various different parts of different types of Agile, a buffet of sorts to steal a term I saw at TechEd 2011.
I hope that you take the opportunity to read the article I wrote, if for anything, to learn how we slowly but methodically moved our team to Agile. If anything, notice how we don’t use parts of the TFS agile process templates –> the last thing you need to do is to shove a square peg into a circle. The team needs to focus on doing what is natural and align their tools to that process which, in the article I wrote, shares some of how we did this.
The ironic thing is that anything I wrote in this article is potentially going to change by this time next year because our team cares more about learning, adapting, and improving individually, as a team, and as an organization.