ThoughtWorks Studios Blog

Industry-leading thoughts on Agile, Software, Technology

This is a public Blog  publicRSS

Recent Entries

  • Elena Yatzeck
    How Do You Vote Someone Off of Your Agile Team?
    Blog Entry posted April 9, 2012 by Elena Yatzeck , tagged Agile Transitions in Agile Transitions > Agile Transitions Blog public
    How Do You Vote Someone Off of Your Agile Team?

    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>

  • Elena Yatzeck
    WAIT: Crucial Consulting Advice
    Blog Entry posted April 1, 2012 by Elena Yatzeck , tagged Agile Transitions in Agile Transitions > Agile Transitions Blog public
    WAIT: Crucial Consulting Advice

    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>

  • Elena Yatzeck
    Lead and Lag Measures for Agile Transformation
    Blog Entry posted March 16, 2012 by Elena Yatzeck , tagged Agile Transitions in Agile Transitions > Agile Transitions Blog public
    Lead and Lag Measures for Agile Transformation

    "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>

  • Mark Richter
    Agile Development With Visual Studio1
    Blog Entry last edited March 8, 2012 by Mark Richter , tagged Agile, Go, Mingle in ThoughtWorks Studios > ThoughtWorks Studios Blog public
    Agile Development With Visual Studio

    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:

    image

     

    My Visual Studio solution has five projects. You’ll find the source for this solution here on Github.

    SolutionNavigator

    This is the project for our .NET client API for Mingle. The highlights are:

    • Class libraries that wrap the the Mingle (and soon Go) REST APIs with XElement wrappers that expose .NET CLR classes for consumption.
    • Automated tests primarily written in Ruby using RSpec. Why Ruby, you ask? There’s a nice gem called Sinatra that features a light weight web framework useful for mocking. This makes it easy to take Mingle out of the room when unit testing.
    • A setup project to create an installer the binaries.stand-up

     

    Task Management and Collaboration

    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”.

    Work Flow

    Our work flow goes like this:

    Workflow

    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.

    Big Picture

    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.

  • Mark Richter
    Go and Team Foundation Server1
    Blog Entry last edited March 8, 2012 by Mark Chang , tagged Agile, automated testing, CruiseControl, Go, testing in ThoughtWorks Studios > ThoughtWorks Studios Blog public
    Go and Team Foundation Server

    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.

    clip_image001

    clip_image002

    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:

    clip_image003

    The compile-build stage runs a job that executes MSBuild from a batch file.

    clip_image005

    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

    clip_image006

    I hope this helps show a bit of what can now be done using Team Foundation Server with Go. It only scratches the surface.

Welcome Guest

Log in if you have an account.

Otherwise, register for an account.

Search this Space

Keyword Search

Select Tags to Filter Blog Posts

Recent Contributers to this Space

  • Suzie Prince
    31 Posts, 598 Comments, last active Yesterday
    Mingle Product Manager
  • Adam Monago
    112 Posts, 290 Comments, last active Yesterday
  • Mark Richter
    15 Posts, 31 Comments, last active May 11, 2012
  • Mark Chang
    3 Posts, 16 Comments, last active May 8, 2012
  • Greg Jesensky
    1 Posts, 1 Comments, last active March 28, 2012
  • Risha Mathias
    18 Posts, 2 Comments, last active March 19, 2012
  • Cyndi Mitchell
    3 Posts, 2 Comments, last active March 8, 2012
  • Adrian
    0 Posts, 1 Comments, last active January 19, 2012
  • Chad Wathington
    10 Posts, 5 Comments, last active November 8, 2011
  • David Rice
    12 Posts, 171 Comments, last active October 6, 2011

Recent Comments