Back in the early 2000s, Toyota had a vision of building the number one best selling minivan in North America. Their current minivan, the Sienna, was small, underpowered, and badly needed help. Yuji Yokoya was given the job of re-engineering the Sienna. There was just one problem, Yuji, lived in Japan. He did not know the people or places that he would be engineering for. Believe it or not, Japan is nothing like North America.

---

One of the greatest frustrations of TFS up till now has been the complete inability to edit files while disconnected from the TFS server. The other is the inability to edit files outside of visual studio without some hackish steps to force TFS to recognize the change. In 2012, Microsoft has stepped up and introduced local workspaces that fix this issue.

---

In my last post I showed you how to get started using TFS in the cloud. By itself, this is very cool, but setting it up for source control makes it even better. In this post, we will work through the process of setting up source control and getting code checked in.

---

One of the greatest barriers to entry for many developers getting into TFS is the setup and install of the system. Fortunately, Microsoft has made it possible for anyone to stand up an their own private instance of TFS in the cloud. Just a few clicks of the mouse and you can have a fully functional TFS instance including source control, work item tracking, and all the dash boarding you could ask for.

---

Everyone has done it, you know you have too. When someone asks you for a status update on a new feature you just finished coding, you say "That's Done!" Think about what you just said for a minute, is it really done? Can someone use that feature in production for its intended purpose? That's really what done means, right? To the end user, done means ......

---

A wise man once told me that most developers dont care about the why, they only care about the how. That is especially true around process and agile development. Developers want to know "how" to do scrum, but rarely want to know "why" they do it. The issue with this mindset is that scrum and agile in general are highly adaptable. Scrum is full of independent ......

---

Probably the most important principle in all of agile development reads like this... Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. I like to sum this up in one succinct statement, software that is sitting in QA is not providing value to anyone. The most important thing an agile practitioner ......

---

The first step in improving your environment and taking steps to become more agile is understanding what is going on in your pipeline. Many shops today have no concept of where all their various changes are, what state they are in, and when they can expect to get stuff out the door. Dev churns out code as fast as they can and then they lob it over the wall to QA. QA is almost always understaffed and can’t keep up with the mass of code that keeps being flung at them from the developers. When you

---

Agile is one of those super buzzwords that everyone knows. The problem starts when you ask people what it means. It seems that the more people I ask, the more answers I get. One of my standard interview questions is, what development process do you use where you are today? I am always frustrated when they say, we “do” agile. My canned response is “What does that mean?” Very few developers can answer that question. I get the standard, “we have daily meetings and we don’t do requirements.”

---

Over the past few years, I have watched developers go to conferences and be filled with excitement over agile development. We love the thought of the rapid changes and better feedback. We get into the buzzwords like Scrum, and Kanban, and the term Burndown list excites every developer’s inner pyromaniac. Then, we take all that excitement back to our day to day lives and quickly find out that we are not in a position to change the process that is in place.

---