Visual Studio 2012 Update 2 – Great update but not a great updater for Build Controllers/Agents
This is just a short post this week, as I’m preparing for a very exciting 2 weeks. The first week has a lot of Kanban training (50+ people) in California and then I’m off to Chicago for LeanKanban North America 2013 where Imaginet will have a booth showcasing the Kanban/Agile/Process consulting side of our ALM Practice.
To kick this off, I have to repeat what is hopefully very common knowledge out there in internetland – Microsoft has released Visual Studio/TFS 2012 Update 2 and this is a very exciting release for me. Included in this release are the new Kanban boards along with the new board editor to go with the WIP limits that were put in for Update 1! If you are trying to do Kanban on TFS, you need to to check out Update 2. If you haven’t been introduced to it yet, check out the Imaginet webinar I did talking about Kanban on TFS 2012.2.
One of the other things that Microsoft spent a lot of time on for Team Foundation Server 2012 Update 2 was the actual update process. You can check out Brian Harry’s blog for a many more details, but it does talk about the improved update experience.
One thing that is conspicuously absent though is any talk of an update for the build controllers and/or agents. That is because there were no improvements to the update process for them. This wasn’t obvious from anything I could find on the web, and as I struggled using the updater to update a client’s build agents from 2012 RTM to Update 2, it eventually came out on our internal Imaginet ALM mailing list.
Now, as unfortunate as this may seem, the TFS team did give us a great new feature in TFS 2012.2 that makes this installer issue a non-event. I’m taking this quote from the Brian Harry blog referenced above:
TFS 2010 Build controller/agent compat – We’ve received feedback that simultaneously updating all TFS build machines along with the TFS server is not practical – particularly in large organization where there can be hundreds of build machines, many of which aren’t even known to the TFS administrators. Because of this, in update 2, we have added support for TFS 2010 build controllers and agents – so you can update your TFS 2010 server without updating your build infrastructure and your builds will just keep working. In general, we expect to continue this pattern from here forward – a new TFS server will support build machines from one major version back. This adds the additional benefit this version that you can use the TFS 2010 build servers on Windows XP (in the event you need to do that) while the TFS 2012 build machines don’t support XP. Based on the feedback we’ve gotten from our MVPs, this change is very popular and makes people’s lives much easier.
It was my desire to have all machines in the TFS ecosystem updated and running on the same version but this is no longer required where build agents are concerned, and there were no significant updates to the build controller/agents that I know of, so I decided “Let’s see how this compatibility feature works!” and left the build controller and agents alone. That was on Friday though, so I don’t have an update on how they are actually working though! 
I will post an update when I hear from the client how things are going! <crossing fingers>
So my advice to you is if you want a completely up-to-date TFS ecosystem, uninstall then re-install TFS on build server (recreating what was there) or if you don’t care that much about keeping everything up to date, just do nothing and leave your build servers at 2012 RTM. I’m sure by Update 3 or 4, Microsoft will get the update working nice and smooth for everything! It is something that is important to them.
The Kanban Method – Change Catalyst with No Changes Planned
I was recently delivering some Kanban training at Yahoo! to a great group of people who were all struggling with many of the same problems we all deal with. Overburdening, long lead times for features and quality challenges, all of which exacerbate each other! Almost all of these people described having been on previous process improvement initiatives. Actually, in some cases, they described being in a non-stop process change initiative. And almost all of them were fatigued by all of the process change initiatives and were very weary of this new “Kanban Method” thing that they were doing.
This seems to be a very common problem that I experience. None of the prescriptive methodologies are solving the underlying problems, organizations are jumping from one prescriptive approach to another and employees are getting tired of it.
The fact that the Kanban Method really isn’t like this is one of the things that has drawn me to it. Let’s revisit the first of the 4 Kanban Method values.
Start with what you do now
Straight from Wikipedia – The Kanban method does not prescribe a specific set of roles or process steps. There is no such thing as the Kanban software development process or the Kanban project management method. The Kanban method starts with the roles and processes you have and stimulates continuous, incremental and evolutionary changes to your system.
This is a central tenant of any LKU Kanban professionals approach to teaching or coaching an organization with The Kanban Method. How can you suggest changes if you don’t know what the problems are? How can you expect a change to succeed without understanding the capabilities of the people within the organization?
When the people are Yahoo! were presented with this first value, they were able to almost immediately relax. We started to hear things like
You mean we don’t have do do anything different?
We can use some of these concepts and ideas within our current process.
Both of which are absolutely true and it is important that people understand this when it comes to starting a Kanban Method implementation.
We then present people with the remainder of the values, which are:
- Agree to pursue incremental, evolutionary change
- The organization (or team) must agree that continuous, incremental and evolutionary change is the way to make system improvements and make them stick. Sweeping changes may seem more effective but more often than not fail due to resistance and fear in the organization. The Kanban Method encourages continuous small incremental and evolutionary changes to your current system.
- Respect the current process, roles, responsibilities & titles
- It is likely that the organization currently has some elements that work acceptably and are worth preserving. We must also seek to drive out fear in order to facilitate future change. By agreeing to respect current roles, responsibilities and job titles we eliminate initial fears. This should enable us to gain broader support for our Kanban Method initiative. Perhaps presenting the Kanban Method against an alternative more sweeping approach that would lead to changes in titles, roles, responsibilities and perhaps the wholesale removal of certain positions will help individuals to realize the benefits.
- Leadership at all levels
- Acts of leadership at all levels in the organization from individual contributors to senior management should be encouraged.
All of which suggest that we do nothing but create an environment that will be supportive of the people who will be finding opportunities to change their processes. That’s it! You’ve now started a Kanban Method implementation, which has often been described as an intent more than a prescriptive, concrete set of things that you have to do.
At Yahoo!, after we had presented everyone with a new approach to thinking about how to approach their problems, we did start to give them some high-level tactics which they could apply when they were ready.
Over the course of the next couple days, we then showed them examples of how they could get more information about how they worked (Core Practices in the Kanban Method). And at no time did we tell them that they had to do any of them, but we described the benefits and limitations of these tactics and by the end of the 2 days of training, most everyone had discovered something valuable and told us they’d be trying to use some of these things in their teams right away. We didn’t know which of the tactics that these people would be trying, but we were encouraged that they felt empowered to start trying to use them at their own pace.
Final Thoughts
In a landscape of teams and organizations getting tired of process change initiatives, it was very rewarding and encouraging to find a group that when presented with The Kanban Method, were excited at the new way of thinking and that they weren’t going to be forced to do something. They were very excited that they would discover what their problems really were and then they would plan out their own changes to the process.
Agile Ramblings 