Sunday, 15 August 2010

Running all Tests in Solution

MsTest is a nice testing framework. However it can be annoying from time to time. a while ago in the past I’ve blogged about the inability of this testing framework to execute all tests in a given sln file.
Recently i had some time and I decided thats its about time that ill do something productive about this (instead of my usual complaining) and I’ve sat down to write a simple msbuild task that runs all tests in a solution.
here is an example of a build script that uses this task:
 AssemblyFile="RunAllTestsInSolution.dll" />

<PropertyGroup >
 <MSTestLocation>C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE</MSTestLocation>

<Target Name="UnitTestsWithCoverage">
   MSTest ="$(MSTestLocation)\mstest.exe"
   Parmaters ="/resultsfile:TestResults.trx" />
As you can see you just tells it which mstest version to use, the solution file containing the test you want to execute and any additional parameters if needed.

You can download the source code from here.

There is a CodePlex project containing an updated source code along with a couple of  other useful Msbuild tasks. Here's the link

Friday, 6 August 2010

ALT .NET – Take 4

Start of next month The ALT.Net group will be having another unconference. This will take place on the first weekend of September.

If you want to come, find out all the details and register using this link. (Exact place is yet to be decided)

Tracking Actual Hours On Tasks

Oren Ellenbogen has posted a couple of weeks ago “Why tracking actual hours is so imperative?”.

Earlier this week I had a discussion with a VP R&D on exactly the same issues..

For me tracking hours on task is well useless.

But here are some of the things they said on why it is important:

  • When people know they are being tracked they become more committed and dedicated to their tasks.
  • We need to report on people performance to higher management and this kind of information is crucial to understand how people perform.
  • We track times in order to verify how much is done on sprint related tasks and how much time is invested on other things.
  • We track time in order to make sure that people are working enough time.
  • its important to correlate story points/ideal days to calendar time
  • In order to improve our estimation we need to track how good they were.
  • We can use this data to approach the sprint planning in a more formal/mathematical way, resulting in better sprint planning.

All this are great reasons but here are some things to remember:

  • Tracking this information takes time and effort – in fact the discussion all started with the VP saying he want to tweak hi ALM system in order to support a specific related scenario. which to me served as a warning they might investing too much time in this.
  • Tracking this data sometime switch the discussion from what was finished, to discussing how much time it took to finish it. the difference between the two might seem minor, however for me become a more productive team is all about focusing on finishing more things.
  • Agile and Scrum is all about the Team , we would like to establish a performing team and in order to do that we must focus on the team as a whole. Breaking down the team and tracking on the individual level is counter productive to this. At the company it was becoming quite visible that it everyone were really careful that everyone they worked on was credited to them. while this is not wrong,its more important that the entire team finish more things then a specific person having a “higher score”
  • Estimation is not an exact science. To this date we have not managed to nail it. I’ve seen many teams become better at sprint planning when they opted to forsake the exact math and started planning in a more flexible. It still amazes me, but almost every time I see people get hung on the math, they just get it wrong. I believe that most people have a great grasp of what they can actually do once you take the numbers out of the equation.

but this in itself is not a reason not to track actual hours. still the benefits are really important. right?

well yes they are however in a Scrum process all the benefits are there. you just need to know where to look for them:

  • one of the things i here many times is when doing scrum people get the feeling they are micromanaged. The daily meeting in which you tell the entire team what you have done feels a little too much. I agree. daily meeting is all the supervision people needs you don’t need to count actual hours in order to let people know that everything they do is monitored. if you really want to motivate your team just hand the sprint burn down chart above their heads. That’s more then enough to most people.
  • Do we really needs to report on a personal level? do your CEO really cares who did what and how much time he invested in everything? in most cases the answer is no. You (as the team manager) might feel you need this information. Higher management just want to know you trust your team and that the team is doing well. Don’t let them meddle with your people nothing good will come out of it.
  • this one is a little tricky, you really wants to know how much effort is invested in not related things, right? again wrong. in most cases ( and in this specific one) you have nothing to do about those things. those things had to be done and you just needed to do them no matter what. what you do want to know is how much time and capacity you had for the related things. and that can usually be judged quite accurately by just looking at what the team did accomplish. in fact, the specific team did try to extrapolate from this data how much time to allocate to “none sprint’ related but found out they really just couldn’t do it.
  • making sure people worked enough? is that really an actual goal anymore? if that really important to you just use your place clock system and extract the exact time people were at work.
  • Relating estimation units to calendar units is quite important, however that is achieved by tracking the team velocity. no need to duplicate the effort.
  • Trying to improve the estimation is the only thing I think might be worth doing. However, i think that just tracking the tasks that significantly got a wrong estimation should be enough. and i expect a team to be able to do that in a sprint retrospect without the need to actually track this formally.
  • don’t use Math when you plan, as i said its just doesn’t work as well.


I see too much emphasis is put on post mortem in a process. It is important to inspect and adapt, but for most team especially for teams which are new to agile and Scrum, The things that you need to improve are much much bigger then this. this is just sticking to old habits and old process, in which since planning was done on a personally level this kind of information was really important. channel your energy on how to get more things done instead of why haven’t we done well last time. finding productive ways to improve is more important then understanding why we were wrong in the past

When you transition to agile, just take a leap of faith and see if you can do without this.

Trust me you can.

Design by Free WordPress Themes | Bloggerized by Lasantha - Premium Blogger Themes | Walgreens Printable Coupons