Measurement of success

Today I was pointed out to three different measurements of success, that I applied in my mind on the current status of our project to migrate legacy tests to FIT/FitNesse. My weekly plan for the last week forsaw to have some kind of “prove of concept” for a very first test. We started to work on migrating our legacy tests from some shell-script approach towards more business-facing tests using FitNesse two weeks ago. We planned for three weeks, therefore we are currently more or less half way through the iteration. With some hard work I managed to get my first “proof of concept” by yesterday and felt successful about this. Anyways today I was pointed out to three different types of success measurement while reading The Art of Agile Development from James Shore and Shane Warden. Their definition made me thoughtful on the things I was happy about yesterday.

Basically we started with five people working on this project. First of all we wanted to concentrate on two areas of our product under test. For these two areas we decided to note down particular tests in FIT-style. Beneath this test definition where most of my testers were planned for, we wanted to build up a small framework in order to integrate our application and having more simple Fixtures to be created.

Until last Friday I wanted to get a first “proof of concept” for this whole work – a single first test, which hopefully should pass. Since there was just one of our external staff members working on that framework, it was not very stable and usable. Personally I decided to work on that proof of concept which I had set as goal for the week. The remaining two available testers in my group decided to start to maintain our legacy test suite, since there was a new release of the system upcoming and the framework was not usable, so we could not really include them into our work, yet.

By Thursday evening I had included a very first draft, which had the setup mechanisms hard-coded. The code was already triggered properly. On Friday I started to do some circumvention work on the framework my external staff member was working on in order to get our first test running and doing everything as intended by the table. I managed to exchange the hard-coded setup mechanism and introduced the result checks as intended. In the end everything showed up green and I was happy.

In The Art of Agile Development I got to know, that there are three kinds of success to think on: Personal Success, Technical Success and Organizational Success. The personal success I felt by yesterday evening is obvious. I have met my weekly goal, a first “proof of concept” is working. Technically I produced some circumventing solution, which works, but will be hard to maintain. From my point of view I have not been successful in this area when looking at the Fixture code I produced during the last week. Organisational we reduced the scope of our iteration, since we could not make that good progress as it would like to have.

Therefore I have a 1:2 situation and I’m not that happy on the success I have met during the last week. I hope I can smooth out to meet at least the technical success needs, which I would like to have by the next Friday, but unfortunately I’m currently not that convinced about that. Maybe it could help to get to know, what we have been doing wrong and how to react on this in the next iteration planning.

  • Print
  • Digg
  • StumbleUpon
  • del.icio.us
  • Facebook
  • Twitter
  • LinkedIn
  • Google Bookmarks

Leave a Reply

Your email address will not be published. Required fields are marked *

* Copy This Password *

* Type Or Paste Password Here *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>