
One of the conundrums of agile conversion is that although you are ordered by management to "self-organize," you don't get to pick your own team. You may not have pictured it this way, but your agile team members are going to be the same people you worked with before, when you were all doing waterfall! I know I wasn't picturing it that way for my first agile team, so I thought I should warn you. (I thought I was going to get between six and eight original Agile Manifesto signers. That didn't happen.).
Why "warn" you (as opposed to "reassure" you, say)? Because the agile process is going to reveal every wart, mole, quirk, goiter, and flatulence issue on the team within a few hours. In the old days, you could all be eccentric or even unpleasant in your own cube, communicating only by document, wiki, email, and, in extreme situations, by phone. Now you are suddenly forced to interact in real time, perhaps in person, with written messaging as the last resort. And because this is new to all of you, you will feel stressed out, and you will not be at your best. I guarantee that your first thought is going to be: "how do I vote someone off?"
![]() |
| From starpulse.com |
<more>

So you want to be a consultant. You probably think this will involve yourself talking and your client respectfully listening. Your client will put you in front of her team to present a PowerPoint deck outlining how Everything Will Be Different Now. You will then distribute copies of your Initiative Plan to each of her subordinates. Once you have given everyone their marching orders, they will do exactly what you outlined in orderly fashion.
But just to make sure, you personally will visit offices in New York, London, Paris, Milan, and Tokyo to double-check that everyone is doing what they should. You will shop in Rome, buy gadgets at the Seattle Space Needle, have some fabulous meals along the way, and you will reach 1K Status this year. That is why you want to be a consultant--you want to be consulted!
Not so fast, El Guapo! Overbearing, meddling, quick to take offense and quicker to offend: you aren't James Bond. You are everyone's...mother in law. Yes, even if you are a guy. Guys are the worst mothers in law.
![]() |
| http://www.bizcrecise.com/lifestyle/what-your-mother-in-law-is-trying-to-tell-you/ |
<more>

"Oh for goodness sake, you put it in upside down!"
"I'm sorry, Secret. I thought the pointy end went in first."
-Secret Squirrel and Morrocco Mole, Secret Squirrel
I'm always excited to learn something new, and this week a colleague introduced me to the "Lead/Lag" concept of measuring the performance of a change program such as an agile transformation. He also introduced me to the "Secret Squirrel (and Morocco Mole)" Hannah-Barbera cartoon series from the 1960s, which briefly seemed to be a more interesting thing to discuss, but I'm pretty sure you guys should all pursue that on your own without further commentary from me. We agilists are a fun bunch.
<more>


It is liberating to do big-time development using Visual Studio without Team Foundation Server in the room. I feel 50 pounds lighter. (Those who know me can imagine how good that makes me feel!) This article presents how I develop software for the Microsoft ecosystem using Visual Studio without using Microsoft’s flagship ALM tools. The theme is to find best-of-breed tools and combine them to get something I like, rather than force myself to use TFS, much of which I don’t like.
Let’s start with the desktop tool for editing and testing code. This is where we spend all of our time. I like to Visual Studio when building software for the Microsoft ecosystem since it’s so attuned to working with .NET assemblies. Full stop. Once that decision is made it’s time to look around for how to take advantage of the best of everything else.
There are excellent choices for integrated source control, task tracking, team collaboration, test-driven development and automated build/deployment using Visual Studio as your integrated development environment (IDE). I use these:
Visual Studio 2010 was a fabulous integrated gallery of IDE extensions. It’s easy to load up. I try and only install the extensions I need and actually use to make life better. Here’s my list:
My Visual Studio solution has five projects. You’ll find the source for this solution here on Github.
This is the project for our .NET client API for Mingle. The highlights are:
I use the Mingle Extension for Visual Studio connected to a Mingle system hosted internally here at ThoughtWorks. These screen shots are from a sample project showing how I query Mingle “cards” (tasks). We use a number of default queries (favorites). “My Work” lists things assigned to me and conforms to the identity of the logged in user of Visual Studio. Individual cards open into a tabbed UI for editing card details. A row of buttons across he top of the card window gives easy access to pre-defined transitions like “start development”, “start testing” and “complete development”.
Our work flow goes like this:
The backlog is what you’d expect in an agile model; it’s the list of things we want. We use a secondary category called Do, which is the list of things we are committed to deliver soon. Each of us takes things from the Do pile and moves them into a state we call Doing when we are actually working on something. I never have more than a couple of things in the Doing state. We use Ready to denote things that are ready to release – nothing more needs to be done at all. We batch things together before releasing simply because it typically makes sense not to formally release each and every story as it is completed. In our shop Done means the story is in the end-user’s hands and they concur it is what they want. Done really means DONE.
We batch things together into iterations and releases using properties of cards (tasks/stories/bugs). A nature of our group is that about half the work we do does not need to be batched into releases and Mingle gives us the flexibility to easily accommodate released-based and one-off development in the context of one Mingle project. It is very nice.
One cool feature of Mingle is something we call “murmurs”, a messaging system that can be connected with Jabber instant messaging. Murmurs quite flexible and useful in different ways, all of them important for team communication and collaboration. My team is geographically dispersed in the United States and the United Kingdom. We use murmurs to keep a running “live log” of comments, questions, observations and status. At any given moment any one of us can jump online and review the murmurs history to come up to speed on current status of a project or each other. I do this in the morning when I start work on the west coast of the United States to catch up on what my colleagues have been doing all day in their office near London.
I use the Mingle Extension for Visual Studio to give me access to a lot of Mingle from within the Visual Studio environment. The following diagram shows you the mains elements of the extension, which supports running pre-defined “favorite” queries in Mingle, drilling down into individual cards, editing and composing new cards.
We have exposed murmurs inside Visual Studio as a lightweight instant message window. You can murmur directly into the window OR from comments to individual cards (tasks). My team’s model for using murmurs has become very a easy and thorough way for us to stay current with each other over thousands of miles in real time. Because murmurs are integrated into Jabber our Jabber IM clients light up if Visual Studio isn’t running. Very cool.
This is enough for this post. Next I’ll tear into the joy of using Git with Visual Studio (instead of TFS), automated testing using a combination of MSTest and Ruby (use the best tool for job) and continuous integration using Go.

With the release of Go 12.1 our platform for automated build and continuous integration/delivery directly supports Team Foundation Server (TFS) source control as a source of materials. In this post I want to give you a deeper understanding of using this feature. For reference you can find the official documentation about using TFS materials with Go here.
Let’s start with Go’s pipeline model. Here’s the pipeline I use to build the Mingle Extension for Visual Studio. In a nutshell you are looking at the essence of Go here. It would be terribly difficult to model this using Team Foundation build alone. This pipeline is composed of five “stages”: compile, two phases of automated testing, a stage to acknowledge completion of manual testing and finally a stage that packages the installer for the tested product to be published. Note the seamless integration of automated and manual stages of the pipeline. It is quite difficult to do this with Team Foundation Build alone.
Here are two look at the pipeline, one in-flight. The pointers in between the stages indicate whether subsequent stages fire automatically or await manual intervention. In my case I stop the pipeline after the completion of automated testing for a bit of manual testing. When all the manual tests are completed we trigger the resumption of the pipeline through to the end.
Imagine a world where that “publish” stage is polishing off a deployment of your e-commerce app built from Team Foundation source control. You can see how powerful this is.
This pipeline interacts with TFS in several ways as it proceeds. Let’s dig deeper.
Here is the configuration for pulling build material from TFS:
The compile-build stage runs a job that executes MSBuild from a batch file.
The job is configured as a Custom Command that runs a batch file containing:
msbuild /t:Rebuild /p:configuration=%1 /fileLogger /flp:logfile=buildlog.txt /flp1:logfile=builderrors.txt;errorsonly /flp2:logfile=buildwarnings.txt;warningsonly vsc.sln
This build produces a number of “artifacts”: logs, a library of automated tests and the testable executable product that will ultimately be packaged for release.
Stage two, automated API testing, runs MSTest over the test library artifact produced by the compile-build stage. This stage is also configured with a job running a Custom Command that calls a batch file, which contains:
del /S testresults.trx
mstest /testcontainer:website.tests\build\tests\website.tests.dll /resultsfile:website.tests\build\tests\testresults.trx
tools\msxsl website.tests\build\tests\testresults.trx tools\MSBuild-to-NUnit.xslt -o website.tests\build/tests/testresults.trx.xml
The final stage, publish, uses TFS’s command line tool, tf.exe, to label the source tree using the value of GO_PIPELINE_LABEL. The value of the environment variable is passed in as a parameter.
tf.exe label %1 $/vsconnector /comment:"applied label" /collection:http://42.42.42.42:8080/tfs/solutions
I hope this helps show a bit of what can now be done using Team Foundation Server with Go. It only scratches the surface.







