There is something about Scrum - 3

...that makes me often think if there is no way that you can avoid corruption in the professional world because so bound is everything together that the more you try to resolve dependencies, the more they crop up in another form, in another aspect or place.

Productivity

Velocity, that you often hear trumpeted in Scrum, can be quite misleading.

Velocity, in common terms, means distance traveled over time. But the distance needs point A from where the calculation of speed begins, and point B,

where the calculation ends.

Velocity, in Scrum, is calculated by the number of features/tasks/stories/bugs completed/delivered/fixed by a Sprint member over a given period of time.

More specifically, in the Scrum context, the points associated with a Story - in Agile parlance, a User Story can have some points associated with it as an estimate of effort - are added up for each successfully delivered story and the sum is the velocity achieved for a sprint or a timebox. Velocity is a paraphrase, or an euphemism, for Productivity.

Productivity needs two parameters, too - one, time (usually called planned or scheduled) and two, money (usually called budgeted or allocated) - and as in matters of relativity (!), needs a surface ie., resources (usually called resources allocated).

The below image depicts all the data that is needed to measure productivity.

But, the picture although tells a lot still does not bring to light the need to measure productivity ie., a platform from which future planning, additional productivity improvements steps can be taken.

And, we also have the assignment of the resource - two resources are assigned to a task at 60 and 50% respectively and the formula (G12+G13) that has calculated shows (in the top left of the below image) that both the values have been taken into account to calculate the planned date.

Productivity is a dangerous metric to use or measure unless it is done in a mature environment and around maturer sets of people. Discussed or analyzed, especially on the internet where the amalgamation is made of disparities and varied cultures, the metric will fail to convince due also to relative application of local work culture and employee engagement parameters.

In conclusion, productivity in Scrum can be measured if the following is true:

1. All Scrum members do not take any leave during sprint (s)
2. All Sprint members are equally skilled and experienced (difficult to achieve)
3. All Sprint members are co-located.

There is something about Scrum - 2

...that makes me often think if there is no way that you can avoid corruption in the professional world because so bound is everything together that the more you try to resolve dependencies, the more they crop up in another form, in another aspect or place.

But there is a way to ensure that you do not allow for crafty resource developers or managers or any smart alec from messing with your Sprint plan.

Like so.

Once you set the week of Sprint (2nd column from the left, highlighted with values 1,2,3,4 signifying the week), a Sprint team member will work on on a particular task, you can restrict any work done outside of the planned weeks for the task, as shown above.

Although the Work done will show 8 hours of work done but the effort remaining part will still show the remaining 2 hours because the work was done outside of week 1 - 4 !

And if you draw a productivity chart, per team member, as per their allocated hours on a project / product team then you can track the difference of 1 or 2 hour(s) that was done outside the plan!

But, of course, as long as it is done within the Sprint, it does not make much difference but it does help you put the 'corrupt' manipulators in place ! :)

#ScrumPlanner

There is something about Scrum...

...that makes me often think if there is no way that you can avoid corruption in the professional world because so bound is everything together that the more you try to resolve dependencies, the more they crop up in another form, in another aspect or place.

Ignoring Mr. Lingo-Nathan (a hideous rule-obsessed maniac), if a resource goes absent on the first day of a Sprint to the 7th day after the Sprint Backlog is planned (Mr. Lingo-Nathan would insist that the resource should not have gone on leave!), and a replacement resource is allocated the same work and the hours are billed as planned, how does it affect productivity, when we measure the effort of both Resource X and Y?

It is not a question that I pose but a preamble to manage Scrummers and Sprinters separately when doing Scrum.

BDD + TDD +UADD - Part I

It is rare that different frameworks can be wired together without facing some glitch in the implementation path. Sometimes, the technologies pose problems, some other times, the tools are not available.

For instance, on a previous occasion, I tried the three with the combination of Slim, C#, NUnit and it developed hiccups because, being a web application, the Javascript/jQuery code could not be as fluently unit tested even though I tried Jasmine and Slim posed yet another problem in that it required separate DLLs to be created for the functional tests to happen, which was far too cumbersome because it meant that components were getting created just so that some tests [to make a framework work] could be performed.

Not what a good design is - you do not create components to make tests succeed, you create components to make the system function properly!

The key to creating a great design, the Agile way, is to let the tests drive the design, not just the development. This can be possible only by getting the requirements right, right upfront. To achieve this, BDD (Behavior Driven Development) framework comes handy.

In this context, naming this framework as a Testing Behavior [Business Driven Behavior] for better User Acceptance (TBUA) would be the closest acronym to describe it.

BDD 

There are many tools and definitions that go around for BDD.

The most famous ones are

1. promise,
2. given, when, then...,
3. should and expect

style of unit testing and,

what I consider to be true behavior driven development -

4. scenario testing based unit tests.

The flavors are different with the intent same - that of providing for as many tests as possible for any given requirement [line of code].

For instance, a Business requirement is to open a XML file, read the contents and get a string as result.

The test scenarios for this business requirement are as follows:

1. Check if file exists
2. Check if file is an XML [filename contains .xml extension]
3. Check if valid XML
4. Check if string generated from XML

The difference between the BDD [without scenario testing] and the BDD [with scenario testing] is highlighted in the above screenshot.

The scenario as described by the Business Rule is to check if the file exists.

But since there is only the business requirement available at this stage, and no coding done yet, the method "openFile" does not exist. What this means is that BDD helps track the business requirements correctly. With scenario tests, it becomes easier to keep the development strictly within the business context.

The scenario has been documented in fitnesse's slimjs tool. Expand the scenario name

This part of the BDD is so essential because it helps trace the entire lifecycle of development from the time the Business Analyst comes up with the business rules based on the requirements and elaborates the scenarios for user acceptance to the time when UACs are contested over.

The rest of the scenarios are

The scenario, check if file extension is xml, does not call a method because it is well possible that it would be handled by the openFile method.

This choice is what makes the Agile way of development so different because deferring the decision till later when coding actually will reveal the possibilities through design evolved from unit tests, allows for a higher code quality.

At this point of the lifecycle, the BDD has just started. Some scenarios have been obtained from user stories and scenario tests have been written for it.

The main reason for writing scenario tests is so as to be able to wire up the scenarios with functional tests, after the unit tests [part of TDD] have completed.

Please note it is not necessary to do scenario testing to do BDD; it just enhances the Agile experience more.

Next part: Deriving unit tests from scenario tests

OMG, my Blog is a genius ! ;)

On 27th February, my blog had 203 visitors.

I frequently look at the stats of my blog and this stat seemed singular to me. So I decided to apply my mind a little to see what was it that could have generated so much interest on a particular day. I dwelt on my blogging style, the content and external factors like a new domain name, a new product etc. Here is what I discovered.

My blogging style

Somehow, I had adopted a practice not to ever blog on my personal life or write in a certain style that I use while writing an article or in a casual form.

I had maintained this blogging practice for over 7 years of blogging but since last year, I have noticed, on hindsight, that I have used that 'funny', descriptive tone in a few posts and not the bland, descriptive style that I use for technical/technological posts. I attribute this 'change' to either my recovering my health for over two years and due to which I have more myself as company or to working on my own and by myself.

The reason I mention this is so that I could share another fact that could not have been shared without this preamble.

The content

The reason I also want to mention this in such a tone is not to brag about it but because during this period, I had added a widget for my Calendar Pane app for Excel 365 without checking its size !

And I had 203 visitors to the blog to see such a great event, when without the over-sized (full size) image, the number would be in mid-20s !

It is remarkable that so many become so interested to make note of a 'deviation' than if the blog were in a perfect condition. It is quite likely that the 'sick' state of the blog was 'symbolically' represented to such visitors as a human being with an ailment, who people visited out of care and concern !

To elaborate on this rampant human trait nowadays, due to the 'comparison techniques of communication' - the 'like a' (just like 'is a' in Object-oriented terminology) style - that many adopt in their zest to be cleverer than others, a mouse enters a home and a nutcase landlord that believes he/she has a 'right' to disturb tenants living below randomly because they live in the building that they own (even if the other is a rightful owner or pays rent to some other landlord!) because they have heard that a mouse also lives in that house for which rent has not been paid because they have created some rent agreement with such a clause that no other living being must live in the house other than the registered names, the deviation is represented for certain crass people as a breach in agreement (unreasonable people is not the word to describe them, they are ridiculously insane people, who live because they have the money to indulge in whatever they want) but without making any charges.

To elaborate more in the same 'like a' way, the mouse is a deviation from what was agreed (not agreed is not what you can argue is their belief - such insanely unreasonable mindsets) in the tenancy so, in return, they believe that they can indulge in their psychotic pleasures.

It is no co-incidence but a serious fact that if addressed correctly can solve a lot of 'humane' problems that face us all in our daily lives.

Of course there is another reason why I found it necessary to share this fact, aside from the preamble that it afforded me, it also helped me draw a parallel to how my products have fared.

I have had more than one career (much like how many mention that they have had more than three wives and are in the process for more !) - one, as a software programmer, two, as a technical trainer, three, as a mentor/coach/evangelist in Agile and of late, as a consequence of my stint at recovering from the injury to my shoulder and arm, as a freelance software consultant and as a product specialist.

It is as the product developer that I am more concerned with, which because of not making me money, puts me in a different light, probably a spot (pun unintended)!

The fact is, I started developing products way back in 1994 under the label of GREYcells and although it found mention in PCQuest and in the form of a press release, it never made any money. The possible reasons were not sufficient financial backing nor the required marketing thrust or help.

Then recently, I developed a few Android apps and put it on the Google Play Store.

Again, I was under duress, but this time, due to the injury. Again, as previously, I turned to jobs (!) as a means to earn money and now, for the third time, as I hit the market, with a product for the Microsoft Online Store, I find that I have not got the response that I was looking for although, a lot better than what the predecessors got, I find a rather simple phenomenon (of course, there are humans involved, too.

External factors

For instance, if a certain practice (angry retaliation or spite would be a more appropriate description) is adopted in a city or town or village, where every mistake committed by a government or an official or a superior, is replicated as another mistake of the same kind, elsewhere, to not only serve as a reminder but as also a form of revenge in a fit of jealousy then people in the 'replicated' city or village would not know it is a vengeful act but only as it was in the other context, a mistake or incompetence) that explains why many problems, social and political, seem the same within the same country or region.

The problems are not because of laws or regulations but because of people and their attitude.

And it is here that the parallel that I wished to draw with the 203 visitors visiting my blog to see a ill-placed image, when the blog had been doing well for more than 7 years !

Some people associate themselves in a certain way to life and so expose themselves to be manipulated in a certain way (like Greenpeace in India) that they become a 'representation' of a certain stereotype, of a 'curse' even, and who, due to years of doing the same things, and without having the 'varied' windows of different careers or different talent as a 'contrast', don't even get to know how they have become a 'curse' !

In India, many would know it from historical reference, where caste-ism used to expose such people; it is known as discrimination in today's world.

Incidentally, it was around the same dates that I suffered the brain hemorrhage that caused injury to my right shoulder and arm and around the same date/month, that another member of my family had a similar but more fatal injury. 

I must be more careful around the month of February because it seems during this month, as astrologers put it in India, 'Shani' hovers over me, in the form of  some factors that make people confused between 'something wrong' with a thing (a blog) - it was the Television that blew up smoke ('phook gaya' is also used in the context of the brain and the car), when I got injured - and 'something wrong' with a person ! :D 

Does it mean that around this month 

(and why only February? Maybe the person visits India or near my house or known to me? Or some psycho who knows me more than I do), 

somebody takes special interest in me and says, "Ok so tell me what is he doing nowadays?" or "how is he?"

Be what may, many 'prejudices', 'religious misgivings' (for example, "Lord Siva is calling you" !)) is likely to get solved by simply co-relating Google Search (SEO) or web marketing/network and human networks and word-of-mouth gossip or vendetta mercenaries. ;)

KnockoutJS, Jasmine but why PhantomJS ? - II

However, since Jasmine is based on testing Behavior against expectations, it is necessary to mention Behavior Driven Development (BDD) and the artifacts that matter for BDD like user stories, scenarios and enhancing code quality through better testability provided by tools like Slim (which enable creation of Scenarios and testing them (thereby, increasing the quality of code because in Agile, the simple thumb of rule is, the more testable the code, the better the quality of code.)), this brings us to the most relevant point of them all (that which is directly related to Agile) - how to select the right tool for an Agile team, not in terms of technical correctness but in terms of fitting in with the underlying development model!).

The tool must be selected in accordance to the basic principles of the model. For instance, BDD stresses on testing behavior foremost so Jasmine, Slim. But what about KnockoutJS?

KnockoutJS is the most compatible tool for an Agile development model like BDD because it allows for testing the changes to the View through the ViewModel ! This does not mean that to be Agile-compatible, a language has to provide for measures to test its view through the viewmodel but that the abilty to abstract the viewmodel away from the view allows for testing 'model' code independently!

To make it more clear, in HTML, if you were to enable instant change reflection to the client page, you will have to wire the onchange or keyup event for the control but can you test if it is working correctly? No. Because the code is wired within the HTML DOM and although there may be ways to access the HTML DOM (so to say), it is cumbersome, not possible to test independently and not suited for Agile. It is more like how fitNesse was used in .Net - contrived and hard-wired.

In the previous part, the reference to PhantomJS's console runner was only to enable GUI reporting of the Jasmine tests.

But, having said, it is not just for a web UI based test report that you need to use another tool; you could as well use the Jasmine test runner and achieve the same results as below:

The script is the same (as in part I) except that the Jasmine Test runner's HTML will no longer refer to PhantomJS's ConsoleRunner but instead to Jasmine's HTMLReporter !

Below is the HTML for the Jasmine's Test Runner.

<!DOCTYPE HTML>

<html>

<head>

  <title>Jasmine Test Runner</title>

  <link rel="stylesheet" type="text/css" href="Jasmine\lib\jasmine-1.2.0\jasmine.css" />

    <script type="text/javascript" src="Jasmine\lib\jasmine-1.2.0\jasmine.js"></script>

    <script type="text/javascript" src="Jasmine\lib\jasmine-1.2.0\jasmine-html.js"></script>

     

  <script type="text/javascript" src="https://ajax.googleapis.com/ajax/libs/jquery/1.8.3/jquery.min.js"></script>

  <script type="text/javascript" src="knockoutjs.3.2.0\content\scripts\knockout-3.2.0.js"></script>

  <!-- SOURCE FILES -->

  <script type="text/javascript" src="helloko-script.js"></script>

  <!-- TEST FILES -->

  <script type="text/javascript" src="helloko-script-spec.js"></script>

</head>

<body>

<script type="text/javascript">

    (function() {      

        var jasmineEnv = jasmine.getEnv();      

        jasmineEnv.updateInterval = 1000;      

        var htmlReporter = new jasmine.HtmlReporter();      

        jasmineEnv.addReporter(htmlReporter);      

        jasmineEnv.specFilter = function(spec) {        

            return htmlReporter.specFilter(spec);      

        };

      

        var currentWindowOnload = window.onload;      

        window.onload = function() {        

            if (currentWindowOnload) {          

                currentWindowOnload();        

            }        

            execJasmine();      

        };      

        function execJasmine() {        

            jasmineEnv.execute();      

        }  

    })();

</script>

</body>

</html>

Alright, but what exactly am I driving at?

That, this much has only been unit testing of code.

If you want to use an Agile development method like BDD or TDD, the reporting plus the test tools themselves may have to be different due to many other artifacts of the Agile development life cycle like CI, E2E, Code Coverage etc.

And this is where tools like Slim come in. If you have already read my earlier post on using Jasmine and Slim, then the next part will have nothing new.

Next part - how to use Slim with KnockoutJS and Jasmine to enable BDD.