ThoughtWorks Studios > ThoughtWorks Studios Blog

Stop Searching. Start Finding.

Wed, 23 May 2012 18:00:44 +0000

Finding stories in your backlog, locating a bug that was logged last week and rediscovering the acceptance criteria on an older story all require a good search capability. The need to find specific cards more easily and consistently in a Mingle project, especially with a large number of cards, has been widely requested. And we’ve heard you.

Mingle 12.1 has an all new sparkly search engine that is not only faster and more fully functional, but also helps you find what you are looking for more easily.

What changes did we make?

First of all we improved the relevance of our search results by building our search for a common but specific use case: finding cards! We improved the weighting (or boosting) of the results to ensure that relevant cards are more easily found. We do this in a number of ways. Results are indexed by key fields such as title and description, cards are consistently returned at the top of the search results and only cards (not their children) which match the search criteria are returned.

For those of you who are not looking for cards and want to search for other items, our new search is now faceted, which allows you to explore search results using built-in filters. Each result set is now neatly organized in various buckets - Cards, Wiki pages and Murmurs - meaning that you can get to the type of results you’re looking for, faster.

Finally, since the new search is built on top of Apache Lucene, you can use familiar query syntax to fine tune your search results:

Search by card type: Precede the card type name with "type:" e.g. type:story, type:bug

Boolean operators: AND, OR, NOT, -, +
Nested searches: (authenticate OR login) AND "cms"

By using these syntaxes, in addition to other advanced syntax queries, you can improve the precision of your search and, depending on your task, improve the relevance of the search results.

Try out our new search now and let us know whether your ability to find that elusive card is improved.

Cheers,
The Mingle Team

---

Mingle 12.1 also comes with improved charts for project forecasting, collaboration improvements and TFS source repository integration.

Start a conversation: When will we be done? What can we do without?

Fri, 18 May 2012 16:34:35 +0000

Blog Entry by Morag Keirns

On the Mingle team, we’re constantly thinking about how to advance our thinking on software delivery. That’s one of the reasons why we’re excited about aligning ourselves more closely with ThoughtWorks’ views on software excellence.

Part of this process involves thinking about how our products reflect our values. We value, among other things, collaboration and transparency, so we try to build products that promote conversations and improve visibility.

Two of the more common conversations we hear practitioners having center around the questions:

When will we be done?
What can we get done by date x?

The Mingle team has recently developed the forecasting and fixed-date charts to help foster productive discussions around answering these questions. We’d like to share some insight into their development below and welcome you to try them out in Mingle 12.1.

The Forecasting Chart: When will we be done?

To help answer questions related to forecasting, we took some cues from the work of James Shore and others on schedule projections. Mingle’s new forecast chart addresses how delivery dates may be affected by one of the more common forms of schedule risk: increases in remaining scope. “How?” you ask. Well, here you go:

The forecast chart shows when your team may deliver--based on your definition of “done”--in relation to changes (0%, 50% or 150%) in remaining scope[1].

In developing this macro, we made some simplifying assumptions, especially concerning velocity. We do not consider variability in velocity and sources of that variability (e.g. technical debt, customer availability, sick days). Instead, we use a constant average actual velocity to date.

The resultant chart is intended to prompt a conversation. Decisions around how much we think scope will increase, and therefore projections about when we may be done, are still left up to the those best equipped to make them: the delivery team.

The Fixed-Date Chart: What can we get done by date x?

So far, we’ve looked at how changes in remaining work impact our schedule. But what about when our delivery date is fixed and we have to communicate that some features won’t make the cut?

The fixed date chart is intended to signal when we may not deliver everything we planned by a given date. When the actual velocity (again, average velocity to date) is estimated to create a burn-up that falls short of total scope, team members can have a conversation about which features are ready to be delivered and which may have to be left undelivered.

How we use forecasting and fixed-date charts

We’re already using both the forecasting and fixed-date charts on the Mingle team. The charts were easy to generate since they use data already being captured.

For example, as we were dog-fooding these new charts for our 12.1 release, the forecasting chart was projecting a release date range between the end of April for no scope change and the end of May for a 50% increase in remaining scope. Given our preference to release in early May, we used the fixed date chart to gauge how many stories may not have been done by our preferred target date. The chart helped focus our conversations around prioritizing remaining stories and removing non-essential work while still leaving us with what we felt was a cohesive product.

We’re always interested in learning more about different ways we can use tools to inform our decisions and affect the way we collaborate with others. What do you use to start conversations about constraints on your project?

Thanks, and more soon from the Mingle team.

[1] We’ll talk more about the rational behind these numbers in a follow-up post.

Agile Development With Visual Studio (1 Comment)

Wed, 29 Feb 2012 21:35:17 +0000

Blog Entry by Mark Richter

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 Ultimate (IDE)
Github for source control using the Git Extensions/Mysysgit for Visual Studio
Mingle from ThoughtWorks Studios (task tracking and team collaboration)
Mingle Extension for Visual Studio
ReSharper
Go from ThoughtWorks Studios for continuous integration/delivery
IronRuby for some of my automated testing
Productivity Power Tools for Visual Studio
PowerCommands for Visual Studio

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:

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:

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.

Go and Team Foundation Server

Wed, 29 Feb 2012 22:01:29 +0000

Blog Entry by Mark Richter

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.

.NET Extensibility and Mingle

Mon, 09 Jan 2012 21:51:20 +0000

Blog Entry by Mark Richter

Body

Over the past year ThoughtWorks has introduced several technologies and extensions that allow Mingle to more seamlessly integration into the Microsoft Office and development ecosystem. We have started three open-source projects supporting this effort:

Mingle.NET – A library wrapping Mingle’s REST API that is easily consumed by clients written in C#, Visual Basic or C++.

Visual Studio Extension – An extension for Visual Studio 2010 that delivers Mingle interoperability inside the Visual Studio IDE working environment for software developers. In its current form the Visual Studio extension supports Mingle. Soon it will also integrate GO with build management and control for continuous integration and delivery. You can watch a five-minute demonstration video here. Mingle Extension is available for download from the Visual Studio Extension Gallery.

Excel Add-In – An add-in for Microsoft Excel 2010 that compliments Mingle’s export feature providing general-purpose data extraction from Mingle into Excel from Excel. Another add-in is planned for Outlook. All this is crafted using the architecture shown below (see diagram).

Mingle can run anywhere on your network or on the Internet. Mingle.NET is an open source library written in C# that provides convenient programmatic APIs for client application software. We’re doing clients ourselves for Visual Studio and Microsoft Office. Your application could be a desktop program or a web app.

My Visual Studio desktop is Southern California using a Mingle system in the San Francisco Bay Area working with team mates in the United Kingdom. The interoperability and productivity are amazing.

Image

The need for an Agile project management tool (1 Comment)

Tue, 06 Mar 2007 05:36:00 +0000

Blog Entry by Dave Whalley

With the coming of age of agile software development, project managers have been left behind in the rush to develop tools to support the processes. As a result, they have had to use unsuitable tools such as Microsoft Project or more likely have been forced into building planning and tracking processes using Microsoft Excel. Excel is a wonderfully flexible piece of software, but there are some clear and present dangers with managing your project in this way:

It is error prone. Ever tried to debug a complex spreadsheet?
It is not transferable. Ever tried to take over someone else's complex and un-commented spreadsheet?
It does not encourage consistency of approach or terminology. Project managers, irrespective of their experience, invariably have to build the concepts and processes from scratch.
It is difficult to share information with team members.
There is lots of information that doesn't fit easily into Excel, so you end up with multiple data stores with all the problems that brings.

Whilst there has been an improvement in tools on the market which purport to manage projects in an agile way, they are currently immature, have restrictions and are largely not scalable above the very small project.

Project managers are crying out for a tool which allows them to plan and track in an agile way which speaks in terms of Lean concepts and allows them to collect information from their agile teams but still has the flexibility to be customized to the unique attributes of any particular engagement. ThoughtWorks, with its world leading approach to agile development and project management, is perfectly placed to solve this problem, and Mingle is the solution.

New Customer Support Phone Service!

Wed, 27 Jul 2011 21:51:09 +0000

Blog Entry by Greg Jesensky

ThoughtWorks Studios Customer Support is pleased to announce the ability to contact us by phone. We understand that our products are critical to your day-to-day operations and there may come a time where you need to reach us quickly. Studios customers with a current support agreement can call one number for any product during your normal business hours.

Of course our knowledge base, community site, and online case submission will be available 24 hours a day, 7 days a week.

ThoughtWorks Studios Customer Support:

+1 415 570-8866

Community Round-up April 2011

Wed, 27 Apr 2011 00:42:11 +0000

Blog Entry by Adam Monago

Greetings Friends,

It's been an exciting month at ThoughtWorks Studios, so we wanted to keep you posted about some of the cool things that have been happening.

First, we released an awesome new version of our revolutionary testing product: Twist. Twist 2.2, released early this month, incorporates YOUR feedback to provide a richer usability experience for the testing professional, along with some killer new features, such as the Scenario Analyzer that provides intelligent analysis on how best to structure and optimally refactor your test suites. Attend a free learning session to learn more about the new features in Twist 2.2 or watch this webinar on where exploratory testing and automation meet with our Product Manager, Andy Kemp.

For the Minglers out there, we released a great new version of our connector supporting Mingle-Jira integration. You can find it, along with a number of other free plug-ins and extensions in our Mingle Add-Ons and Extras space. Both new and experienced users will also be interested in this month's installment of the Mingle User Group where we were joined by our friends from Rackspace and Sungard Global Services.

The Go team has been working hard on Go 2.2 which is just a few weeks away. Those of you participating in the Early Access program have provided feedback that will make the GA release sing, and for that we thank you. New Go users will also be thrilled to see the first installments of the new Go Instructional Videos while more seasoned users might be interested in checking out how Go Feeds for Android Mobile might support their DevOps team.

Interested in hearing what our technical leadership have been thinking about? Check out David Rice's post on Responsibly Open Data in our Agile Development Practices space. Remember that our team wants to hear from you as well; please share your thoughts on application integration with us here.

Finally, with May around the corner, the ThoughtWorks Learning team is getting ready to hit the road for ThoughtWorks Learning Live! If you are in the Dallas,Texas area, please join us in May, or keep an eye out for dates around the country as we come to a venue near you.

Thanks for staying in touch, and please remember to follow our feed or our tweets to hear the latest happenings.

ThoughtWorks Learning Live! coming to Dallas/Fort Worth

Mon, 11 Apr 2011 22:06:06 +0000

Blog Entry by Adam Monago

Body

ThoughtWorks Learning Live! Is a series of educational workshops for both beginning and advanced Agile practitioners.

These intensive workshops have been designed to provide individuals of all backgrounds with a solid footing as they begin their journey on the path of Agile Software Development. Whether you are a C-level executive or a tester on a development team, a line manager in IT or an analyst in Finance, we will explain in clear, simple terms what Agile is all about, and how it will benefit you and your organization.

As a member of the ThoughtWorks community, we're offering a 15% discount(code: DFW0511) applicable to any of these events, this offer expires April 18, 2011. We expect the spaces to fill up quickly, so please reserve your spot soon.

Who should attend?

We feature courses for all skill levels and disciplines, including: Executives, Project Managers, Iteration Managers, Product Managers, Business Analysts, Developers, Operations Managers and Testers.

View all upcoming ThoughtWorks Learning Live! events here:

We look forward to hearing from you!

Adam Monago, Vice-President Client Services
learning-admin@thoughtworks.com

Link

Upcoming Training Events

Recap of the Financial Implications of Technical Debt Seminar

Sat, 26 Feb 2011 00:31:25 +0000

Blog Entry by Adam Monago

Body

Last week at the Palace Hotel in San Francisco, Jim Highsmith, Executive Consultant for ThoughtWorks and Jitendra Subramanyam, Director of Strategy and Research for CAST, presented a two pronged approach to the issue of technical debt in the agile corporate environment.

You can read an excellent summary of the talk here: http://blog.castsoftware.com/the-financial-implications-of-technical-debt/