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 its up and running, in production, providing value. Code complete is just another stage in the pipeline getting us out to really done.
You may say, that is a semantic argument. Your piece is done, so you get to say done. I would argue, its a mindset discussion. As developers, if we think about our piece, and only our piece, we say done when our piece is done. Agile is about picking your head up and looking at more than just your piece. Collaboration and a sense of unity across the entire product team is critical to a successful agile organization. We as developers need to move away from our tasks as "in dev" and "done". We have to get to the point where we think of a feature in development, or in test, or in requirements. We need to pick our heads up and see the whole picture, not just our piece. Next time your manager or scrum master asks you for a status on a feature you just completed coding, resist the urge. Instead of saying, "that's done", give them the actual status of the feature. Your larger team will thank you for it.
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 concepts that can be adapted to your individual circumstances in order to achieve a highly efficient and productive team. However, when you don't understand why you are doing them, you tend to adapt out the good stuff and miss the whole point of what you are trying to accomplish with Scrum.
Probably the most misunderstood and abused concept in Scrum is the daily stand-up. I have seen many instances where developers go through the motions of the stand-up, they even ask and answer all the right questions, but they are doing it for all the wrong reasons. Ultimately, the purpose of the stand-up is for the team to know what the team is doing. The purpose is not for the scrum master, project manager, or team lead to know what the team is doing. When you pull a team together for a daily stand-up, that is their opportunity to listen to what is going on, understand where the pieces they are waiting on are at, know what struggles their teammates are going through, and be able to voice what your own struggles are in an attempt to get assistance or understanding from the team.
At its core, the stand-up is about forming a group of people that are all in this together. In other words, a team... If you are checking your email while your peer is giving a status report to the team lead, you are not part of a team. You are an individual who may or may not contribute to the overall success of the group. If you are "tweeting" instead of listening to the struggles of your peers, you may be doomed to repeat their pitfalls.
So, tomorrow in your stand-up, put your phone down and make eye contact with every person that gives their update. Ask yourself, "How does that impact me?" or "Have I struggled with that before?" Have your first response be, how can I help these people out to contribute to the overall success of the group. That ultimately is what a team does.
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 can do is identify valuble pieces of software and get them to production as fast as posible.
Notice that this principle does not specify a timebox, or iteration length or any other such thing. The key is in the term continuously. As soon as you have something that could be providing value, get it out the door.
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.