Stand up: Why you should talk about your next actionable?
 

Lots of teams that I work with generally follow the best practices of a Scrum stand up meeting. However, as time goes by team tend to fall into the slippery slope of just reporting what they have accomplished the previous or the current day and completely ignore the next actionable & impediments. This happens more when the team/scrum master is not very strict about the process. In this article, we will see the reasons why this is important and the benefits of the same.

Life without goals

Before we delve deep into practices of Scrum method, we will talk about few general principles how our subconscious works. As per the basic behavioral psychology, there are three parts of the self-concept.

a) Self-Ideal – Goals, aspirations, dreams etc.

b) Self Image – impression about self-based on previous experiences.

c) Self Esteem – Emotional component of how much we like ourselves.

When someone sets goals and achieves them, the self-image corrects and the self-esteem improves. And they start setting bigger goals and continues to go on an upward spiral.

How Psychology relates to Scrum

Whenever a team member talks about “What they will do ” before the next meeting, they are indirectly setting a time-bound goal for themselves. When they come and report the achievement of the same the next day, the self-image and the self-esteem goes up. This will bring more success as the time goes by.

The Sprint is systematically designed methodology using the basic psychology of commit and achieve cycle.

Let’s do an experiment. If you are part of an Agile team, state your goal for the day loudly to your team during the stand-up meeting. You would have that in your back of your mind entire day. At the end the of day, if you accomplish what you stated, you will have an amazing sense of accomplishment.  Otherwise, you feel that you have not done enough. This comes to most members as long as they care about the company and their career. All you have to do is take that seriously and you would find yourself growing much faster than your peers.

I have personally asked this to many people and every time I had the same result. Isn’t it amazing? How simple it is to grow in an Agile team. Isn’t it?

So Next time you are in a stand-up meeting, would you talk about “what you are going to do “?

 

If you like this article, please share and provide comments.

 

 

Top 100 Agile Blogging Websites in the world
 

Top 100 Agile Blogs websites

Below is the top 100 Agile websites list published by AgileChamps team. The process followed to identify top 100 sites is:-

  1. Identified few core keywords used for Agile.
  2. These keywords are used against the majority of top search engines.
  3. The websites coming on first few pages are identified.  Approx. 1200 plus websites are shortlisted.
  4. Identified Alexa Rank for all of them.
  5. All the websites under 15 million ranks are reviewed individually.
  6. The websites which are heavy centric on Agile are marked and rest are removed.
  7. At this point, top 200 websites are shortlisted for final review and research. The top 100 are picked after spending a good time with each and every website.

The list may not be 100% perfect but it should be close as there are chances that some of the good websites on Agile are missed. If you think, you have an Agile Blogging site which is not listed here, please do mention in the comment section with Alexa rank and we would include that in below list.

Rank Agile Blogging Site Alexa Rank Comments
1 http://softwaredevelopmenttoday.com/ 1030 Improving the world with software
2 http://agilescout.wpengine.com/ 3078 Agile Software Development News
3 http://agile.dzone.com/ 4167 Agile and Technology
4 http://www.infoworld.com/ 11991
5 http://blogs.msdn.com/b/jmeier/ 12181
6 http://martinfowler.com/ 29470
7 http://scrumalliance.org/ 36377
8 http://geekswithblogs.net/Default.aspx 36908 Agile and Technology
9 http://blog.scrum.org 62603
10 http://www.mountaingoatsoftware.com/ 65325
11 http://www.versionone.com 106619
12 http://www.lean.org/ 143610
13 http://blog.xebia.com 157824
14 http://www.romanpichler.com/ 180494
15 http://www.allaboutagile.com/ 181443
16 http://agilewarrior.wordpress.com/ 257143
17 http://scrummethodology.com/ 269615
18 http://blog.crisp.se/henrikkniberg 279696
19 http://www.torbenrick.eu/blog/ 286285
20 http://www.scruminc.com/ 327659
21 http://www.shmula.com/ 345374
22 http://www.solutionsiq.com/ 359293
23 http://tynerblain.com/blog/ 392184
24 http://www.leadingagile.com/ 396993
25 http://management.curiouscatblog.net/ 420641
26 http://www.agileforall.com/ 451259
27 http://www.marcusoft.net/ 473266
28 http://alistair.cockburn.us/Agile+development 505811
29 http://www.agile42.com 529073
30 http://services.leankanban.com 540509
31 http://www.agileweboperations.com/ 563971
32 http://agilescout.com/ 574286
33 https://age-of-product.com 600556
34 http://www.jrothman.com/blogs/ 608049 Management and Agile
35 http://blog.retrium.com 681480
36 http://tastycupcakes.org/ 736304
37 http://www.netobjectives.com 767821
38 http://jamesshore.com/ 768661
39 http://ronjeffries.com/ 791006
40 http://www.klocwork.com 799097
41 http://www.personalkanban.com/ 806918
42 http://www.agileadvice.com/ 881368
43 http://benlinders.com 908226
44 http://www.scrumexpert.com/ 941122
45 http://brodzinski.com/ 950714
46 http://blogs.agilefaqs.com 979367
47 http://herdingcats.typepad.com 995606
48 http://scrumology.com/ 1105693
49 http://agilepainrelief.com/ 1210659
50 http://blog.3back.com/ 1300016
51 http://leadinganswers.typepad.com 1309169
52 http://www.implementingscrum.com/ 1340427
53 http://kenschwaber.wordpress.com/ 1454803
54 http://testobsessed.com/ 1567560
55 http://www.agilitrix.com/ 1590376
56 http://lithespeed.com/ 1674920
57 http://lisacrispin.com/ 1705271
58 http://guntherverheyen.com 1879037
59 http://www.betterprojects.net/ 1917210
60 http://agilesoftwaredevelopment.com/ 1917606
61 http://www.agile-ux.com/ 1948198
62 http://leansoftwareengineering.com/ 2054154
63 http://agilecoach.typepad.com 2064719
64 http://www.agilistapm.com/ 2302141
65 http://borisgloger.com/ 2332692
66 http://www.estherderby.com/ 2377232
67 http://www.makinggoodsoftware.com/ 2522442
68 http://www.growingagile.co.za 2552857
69 http://www.ontheagilepath.net 2578280
70 http://www.cindyalvarez.com/ 2585993
71 http://www.jbrains.ca 2606431
72 http://www.scrum-breakfast.com/ 2632324
73 http://www.dkrimmer.de 2667951
74 http://leanandkanban.wordpress.com/ 2726139
75 http://blog.agilegamedevelopment.com/ 2726568
76 http://www.gettingagile.com/ 2729011
77 http://brainslink.com/ 2808821
78 http://blog.oikosofy.com 2893584
79 http://availagility.co.uk/ 3117999
80 http://www.leanessays.com/ 3134021
81 http://kellycrew.wordpress.com/ 3194994
82 http://scrumcoaching.wordpress.com/ 3397983
83 http://www.agilechamps.com 3420233 Based on real time experiences. Agile becomes simple.
84 http://www.coachingagileteams.com/ 3493804
85 http://www.derekhuether.com 3499622
86 http://www.axisagile.com.au 3630517
87 http://www.softwareresults.us/ 3658561
88 http://indigoblue.co.uk 3671917
89 http://www.agiletrainings.eu 3740017
90 http://hanoulle.be/ 3782502
91 http://lmsgoncalves.com 4120325
92 http://fragile.org.uk/ 4235666
93 http://theagileexecutive.com/ 4479652
94 http://scalingsoftwareagility.wordpress.com/ 4543469
95 https://scrumfamily.wordpress.com/ 4603896
96 http://www.tinypm.com/blog/ 4815953
97 http://catenary.wordpress.com/ 5292497
98 http://www.agilecoach.ca/ 5352264
99 http://www.thoughtclusters.com/ 5547969
100 http://agilemindstorm.com/ 6605622

I would really appreciate if you can provide a link to this blog to your website if your website is listed above.

BDD (Behavior Driven Development)
 

In the previous article we looked at how to do Test Driven Development (TDD) while doing the XP (Extreme Programming). In XP, the implementation of the tasks are done in the steering phase of the iteration planning. One of the tenets of the steering phase is “functional tests are run”. In this article we will see how to create functional tests using Behavior driven development (BDD) and its benefits.

Following are the some of the benefits of automated functional tests.

  • Functionality experienced by the User is tested
  • Saves testing time for the developers
  • Test in every environment (Dev, QA, Stage) without much effort
  • Generates confidence in every stake holder

Tools required for doing BDD in .Net

There are various tools available to do BDD in .Net. I have listed few of them below

SpecFlow is one of the most popular tools used in the .Net/C# community. And in this blog lets use the same. The tool comes as a Visual Studio Extension and can be downloaded directly from VS.

Creating a SpecFlow Project

Once SpecFlow extension is installed, the template required for doing BDD will be installed.

  • Create a simple “Class Library” Project in Visual studio
  • In the project, create a SpecFlow Feature file

Selecting the test framework

Before we Create/execute the scenario, we need to wire the SpecFlow with a compatible test framework. To do that we need to make changes to the app.Config file of the project.

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <configSections>
    <section name="specFlow" type="TechTalk.SpecFlow.Configuration.ConfigurationSectionHandler, TechTalk.SpecFlow" />
  </configSections>
  <specFlow>
    <!-- For additional details on SpecFlow configuration options see http://go.specflow.org/doc-config -->
  <!-- For additional details on SpecFlow configuration options see http://go.specflow.org/doc-config -->
    <unitTestProvider name="xUnit" />
  </specFlow>
</configuration>

In this example we are using XUnit as the testing framework. SpecFlow supports a series of testing frameworks and more details can be found here.

Creating the Behavior

Now, let us look at how to create a functional test using behavior driven approach. Let’s consider the following story while creating a POS (point of sale) application for a super market.

“As a Supermarket POS app developer,  i would like the API to Give the total amount while billing so that I can wire up API against the UI.

Let’s write the Behavior required in order to implement the above API requirement .

Feature: SuperMarketProductsAPI
	As a Supermarket Biller 
	i would like the API to
	Give the total amount while billing
@SmokeTest
Scenario: Find the total amount while billing
	Given Shopping cart is filled with all the items required by consumer
	And Campaign information for the month is available in the system
	When I pass the cart to create bill API
	Then the total bill amount should be calculated

The above specification is written using the custom language (testing DSL) create by the specflow.org. (Please read about what is DSL here.)

There are 2 parts to the above Specflow specification

  • Feature – Denotes bigger context (description/story) of the application
  • Scenario – Specific workflow or behavior of the system under the feature. Each scenario has the following sub-parts
    • Given, And – describes what we already assumed available
    • When – The specific action which will trigger the workflow/behavior
    • Then  – expected behavior

 

Creating step definitions

When we run the unit test corresponding to the above test we it will fail as there are no definitions corresponding to the above scenarios.

Now Right Click on the feature file and select “Generate step Definitions”

You will see the pop-up like below, select “Generate” and then “Save” the file.

The file will have the details about “what SpecFlow should do when test is executed”.

using System;
using TechTalk.SpecFlow;

namespace SuperMarketFunctionalTests
{
    [Binding]
    public class SuperMarketProductsAPISteps
    {
        [Given(@"Shopping cart is filled with all the items required by consumer")]
        public void GivenShoppingCartIsFilledWithAllTheItemsRequiredByConsumer()
        {
            ScenarioContext.Current.Pending();
        }
        
        [Given(@"Campaign information for the month is available in the system")]
        public void GivenCampaignInformationForTheMonthIsAvailableInTheSystem()
        {
            ScenarioContext.Current.Pending();
        }
        
        [When(@"I pass the cart to create bill API")]
        public void WhenIPassTheCartToCreateBillAPI()
        {
            ScenarioContext.Current.Pending();
        }
        
        [Then(@"the total bill amount should be calculated")]
        public void ThenTheTotalBillAmountShouldBeCalculated()
        {
            ScenarioContext.Current.Pending();
        }
    }
}

When you build the project and execute the test corresponding to this, it will fail. This is because none of the parts of the test (given, when, then) are having implementation.

Writing code to make it work

Now that the behavior has been created, we are good to validate that with the team and implement the code/functionality corresponding to the requirement. Of course using best coding practices like TDD 🙂

Making the behavior test pass

In order to make the behavior test pass we need to write the implementation in the “Step Definition” file.

namespace SuperMarketFunctionalTests
{
    using Newtonsoft.Json;
    using System.Collections.Generic;
    using System.Net.Http;
    using TechTalk.SpecFlow;
    using Xunit;

    [Binding]
    public class SuperMarketProductsAPISteps
    {
        Product P1 = new Product { Name = "test1", Cost = 5 };
        Product P2 = new Product { Name = "test2", Cost = 10 };
        ShoppingCart cart;
        List<Campaign> campaign;
        Bill bill;
        [Given(@"Shopping cart is filled with all the items required by consumer")]
        public void GivenShoppingCartIsFilledWithAllTheItemsRequiredByConsumer()
        {
            cart = new ShoppingCart { Products = new List<Product> { P1, P2 } };
        }
        
        [Given(@"Campaign information for the month is available in the system")]
        public void GivenCampaignInformationForTheMonthIsAvailableInTheSystem()
        {
            campaign = new List<Campaign> { new Campaign { product = P1, discount = 1 } };
        }
        
        [When(@"I pass the cart to create bill API")]
        public void WhenIPassTheCartToCreateBillAPI()
        {
            var client = new HttpClient();
            var response = client.PostAsync("http://myapi.supermarket.com", new StringContent(JsonConvert.SerializeObject(cart))).Result;
            var output = response.Content.ReadAsStringAsync().Result;
            bill = JsonConvert.DeserializeObject<Bill>(output);
        }
        
        [Then(@"the total bill amount should be calculated")]
        public void ThenTheTotalBillAmountShouldBeCalculated()
        {
            Assert.True(bill.totalAmount == 14);
        }
    }
}

Once the code is there we can see the behavior test pass.

Conclusion

BDD is very powerful way of ensuring high code quality in conjunction with business requirement. In Extreme programming (XP) , BDD is considered to be a very important practice where functional tests are mandated to run at least once during the iteration.  Is BDD/Functional tests helping your team/business in achieving success or not ? Do let us know your thoughts.

Perspective Designing
 

Recently, I was working with a colleague in refactoring one of our projects. As we added tests, we found few code issues and continued refactoring. Was feeling happy as our unit tests were rearing benefits. However, we know TDD or unit testing does not guarantee clean code. As we progressed, the naming conventions consumed a lot of our time. And eventually, it brought us to a discussion about why specific naming conventions can create a better design. Thought I will share our discussions and practices here.

While we design classes for application, we often think of it as a different subject than ourselves (programmer). When I say different subject, we think of it as a different object and not as a person. When a programmer considers classes/interfaces as personalities and thinks from the perspective of the class, design can change drastically. This is what we call “Perspective designing”. Let’s take an Example:

    public interface ITotalTaxCalculator
    {
        decimal Calculate(IEnumerable products);
    }

    public class TotalTaxCalculator : ITotalTaxCalculator
    {
        public decimal Calculate(IEnumerable products)
        {
            decimal total = 0.0;
            //add total of products etc....
            foreach (var product in products)
        	{
                using(var dbContext = new ProductContext())
                {
                    var productInDb = dbContext.FistOrDefault(prod => prod.Id == product.Id)
                    total += (total * productInDb.taxRate);
                }
        	}
            return total;
        }
    }

In the above example, the name of the class and interface are perfectly fine. But they are impersonal and it’s very hard to think of it as a person and bring in perspective thinking with these names. So we refactored them to ‘ICanCalculateTotalTax’ and  ‘TotalTaxMan’.

public interface ICanCalculateTotalTax
{
    decimal Calculate(IEnumerable products);
}

public class TotalTaxMan : ICanCalculatorTotalTax
{
    public decimal Calculate(IEnumerable products)
    {
        decimal total = 0.0;
        //add total of products etc....
        //blah blah blah..
        total += (total * taxRate);
        return total;
    }
}

These naming conversions have lots of inspiration from in NServiceBus for their class/Interface names. With the new class and interface names, it’s easy to think of them as personalities. However, this does not guarantee good design. So we needed refactoring. Perspective thinking comes in handy especially while we do refactoring When my colleague and I started putting ourselves in the place of each of the classes. We had very reasonable questions which triggered our object-oriented thinking.

Example1:  As ‘ICanCalculateTotalTax’ , why I am having database related behavior?

Example2: As ‘ICanCalculateTax’, why I am having logic to find which language it needs to be presented?

These questions helped us to refactor the code to follow good design principles. When we implement these interfaces/abstract classes, we have clarity on what the class is capable of doing. So we generalized these naming conventions & questioning attitude and derived below two rules to do Perspective designing (think like a class).

  • Give personality to the names of  classes/interfaces (example: ICanCalculateTax)
  • Use the Agile User Stories way of articulating what the class should and should not do. (example: As ‘ICanCalculateTax’, I should be able to provide behavior to calculate tax)

I think, “Perspective designing” can make classes more object-oriented and best practice like SOLID principles automatically fall in line. Let me know your thoughts.