How to make gulp-sass task working on Windows?

Step-by-step guide

  1. Go to:
  2. Click download and load Ruby 1.9.3.(
  3. By default it will install on your c:\… drive (don’t change any default location or whatsoever and please make sure that you don’t have any space in the path.)
  4. Set your PATH variable that includes your ruby installation location. Now you should be able to run gem evn in your command prompt ( you probably better run command prompt under administrator)


  5. From the command prompt run gem install sass


     If you find an error that complains about network drive not found or something like that. Then probably your home path is not set to your local drive. You need to set the HOME path so that it connect with your local drive. To check the value, run command SET HOME Now, if you find it is not correctly, or pointing to some network drive then set this as SET HOME = %UserProfile% 
    You can read more about this error at



  6. Now you need to install bundler run gem install bundler 
    If you find this error on gem installation: 
    ERROR: While executing gem ... (Gem::RemoteFetcher::FetchError)
    SocketError: getaddrinfo: No such host is known. (
    Then probably you need to look at your proxy setting. If you don't want to enforce any proxy then run this command, which will empty any proxy settings: gem install sass -p 
    If you want gem to use any specific proxy then run this: gem install sass -p
After following this steps, you should be able to run Gulp task for SaSS from windows machine.

Summarizing AgileEncore 2014

It is all started when Deniss Alimovs pushed me to attend Agile encore 2014 event. I definitely believed that the invite was for him but he is so generous to share such opportunities with his team mates (That I call a sign of being a great leader).amit@agileencore

I thoroughly enjoyed this session and I am glad to share the following notes in my blog post.

PLEASE NOTE: I have excluded common messages that I presumed we all know. However, what you will get below is something new that I found could be beneficial to remind you.

Also keep in mind that that these are my interpretation, my observation and it may not be 100% same as speakers' said. (I am still trying to learn - how to listen over hearing.)

agileencore2014 banner

James Brett, Founder, Curiously Lenka Bednarikova, Scrum Master, Commonwealth Bank Lachlan Heasman, Agile Coach Scott Kinder, CEO, The Kinder Group Sandy Mamoli, Founder, nomad8  Dipesh Pala, Agile Capability Lead, IBM John Sullivan, Product Delivery Manager, Business Division, MYOB
To read about specific speaker, please click on their photo.

Four things we need to know about teams – Lachlan Heasman, Agile Coach


Lachlan started with the statement that there is a difference between group and team. Team is something we should emphasis on building it. You can build a great team by knowing some of the commonly known models in the market such as Tuckman and Poole. Then he took me on motivating team. He also emphasized on Outcomes over Processes and ended his four points by stating that you don’t need a title to be leader.

Let see what these four points means to me.

1. Development Model

The following productive team build development Model was discussed – Tuckman and Poole. Here is my understanding with these two:

Tuckman Model

I already knew about Tuckman model and you can read it at my previous blog post –

However, the bottom line about tuckman model is about giving you a leadership tool so that you can build a well collaborative team (it is all about communication).

Poole Model

Poole’s model put forward several tracks for the group communication and also stated the tracks can repeat or can happen at any time of the communication process. This model consists of the various tracks used for interpreting the communication styles that a group follows.


Poole's Model

2. Motivational effects

Lachlan labelled some managers’ as “Free rides” i.e .those Take the benefit of someone else work.

Another tag he had referred is “Social Loafing“. Social loafing began with rope pulling experiments by Ringelmann, who found that members of a group tended to exert less effort in pulling a rope than did individuals alone. Thus he suggest that team work is important however, each of us should put their own efforts to reach the goal.

The major motivational efforts he talks about is Kohler Effect  i.e. leaders have to set examples for others so that others can try to achieve the same. At the end, no one wants to be left behind in the team.

3. Outcome vs. Process Focus

You can focus on any process (including Agile), however the main objective is the outcome. So the message came across is thus it is good to have a process, but the process should be introduced to produce required outcome. Thus, outcome should be our main focus, and process comes along with it.

4. Leadership

The main message came cross is – You don’t need a title to be a leader, which it remind me about this book.

Managers needs to provide required tool and environment to produce leaders; thus making outcome focused team.

Unleashing the full potential of your Agile team, Dipesh Pala, IBM.

Whatever makes you happy will make your team happy. So what you want to feel, you should reflect the same.

“Be the change that you wish to see in the world.” ― Mahatma Gandhi

He asked a question – What makes you happy in life?

Audience believed that the following will make them happy:

  • Achieving something,
  • Being recognised,
  • Having Hope,
  • Trust in people around us
  • Being rewarded,
  • Being loved and respected
  • Always learning
  • Making other people happy,
  • Being challenged, simulated
  • Sharing your fruits with others.

What he was emphasizing – “What will make you happy will also make your team happy”.

Understanding individuals what makes them happy will lead you to make a good agile team as well.

To make a better team it is important to understand that leaders should provide supporting environment that makes the best team, producing better outcome.

He asked a question again – what makes you think which item is the most important for them?

  • Providing Clear Goal
  • Providing Interpersonal support
  • Providing reward and incentive.
  • Providing support for making good team (it is the main)
  • Providing recognition for good work

Managers ignores “Providing Support” where as their thought is on “Recognition for Good work”. Get the small wins be celebrated within team, thus makes you a best team. This is what Managers must do i.e. Peace loving environment.

“If you cannot fly, run, if you cannot run, walk, if you can't walk, crawl, but by all means keep moving - Martin Luther King.

Leader should be inspiring small wins. Leaders must remove the control of information and let it flow within his team. Agile team works only with the trust. Project Managers should be promoting transparency thus there is a great visibility and trust is build.


To check the status of of your team, he recommended this check list for leaders.

Agile and Special Forces: Leadership that lives disruption, James Brett, Founder @ Curiously, Scott Kinder, CEO, the kind Group.

There was a great comparison of Agile Manifesto with the way Military operates. Scott comes from US Military background and with the help of James, he has did a great live comparison. Their presentation is good to see as well.

The important message was, instead of emphasizing on skill sets, like you find in any job advertisement, there should be more emphasis on finding people with the right attitude. And then train them by empowering them with the tool set.

Another key message throughout this presentation was “Disruption”, which should be seen as opportunity. So whenever, you see a change is happening consider it is for good. You will be injected with a new knowledge or an area that you might not have seen is better.

It is like you can replace “Excuse” word with “Opportunity”.


Let the right one in, Lenka Bednarikova @ Commonwealth Bank.

The cost of getting it wrong person is higher then expected. There is a financial cost however there are other costs that must be looked at.

Cultural cost – We should be finding people from company future projection of view so that the future can become reality.

Financial cost – Of course by hiring people with current culture point of view, you might end up spending lots of time on teaching them your future and there is a great possibility that they will leave your organisation.

Traditional Hiring Vs. Agile Hiring

The bottom line is instead of selecting people with Buzz words, let people comes in for face to face conversation and select those people that can bring right passion. Please don’t select people because they are awesome in .NET and passion means – people will do the right thing rather doing something.

Most importantly, your organisation should be prepared for the passionate conversations.

Another interesting thing that I found Lanka said is to hire freshers. The reason is because they are bringing a fresh air, with no assumptions and new views. They create an environment that people need. Potential over Experience is something has been emphasized.

Portfolio Kanban: Seeing the bigger Picture – Sandy mamoli, Founder, nomad8

Doing too many things at once can slow an entire organisation down. Every successful organisation will have more great ideas than they have capacity to build, and it is tempting to start too many of them at the same time.

The more we add the more we become unstable.

The moving parts for any organisation is:

  • Work
  • People

Thus, you must fix work by showing an entire Portfolio.


Guerilla Re-transformation John Sullivan, Product Delivery Manager, MYOB


  • Don’t focus on Agile Manifesto, instead focus on key principles.
  • He transformed MYOB team by bringing right people and change happens at managerial level.
  • He also suggest that to hire permanent employees over temporary employees.


Lastly, after knowing Lisa Frazier @ CBA, I am proud to feel that leaders @ CBA understand the value of human resource, and it makes me feel that I am as important as others.

This is my outcome of yesterday’s session, what is your?


Click on this link for original presentations

How to do team meeting in an agile way – Explaining Lean Coffee ™

If you have been implementing Agile in your organisation, you must have been involved in one (or many) of the following meetings:

  • Sprint Planning Meeting
  • Daily Scrum Meeting
  • Sprint Retrospection Meeting
  • Random meetings.
  • Technical Meetings and so on…

Majority of times I feel that meetings have one (or more) following flaws:

  • Missing Direction,
  • There is no outcome,
  • Unexpected Discussion,
  • Meetings are over-timed,
  • All (important) points are not discussed.

Meetings like, Sprint Retrospection, has been time boxed. However, it has never been concised.

Lately, I went to one of Scrummasters discussion forum at CBA (CommonWealth Bank of Australia). There, the lean coffee ™ meeting was introduced.

I found very fascinated with this concept. I discussed the same with my Manager and then to my entire team. I am glad to tell you that all of my colleague got very excited with this concept. I thank them to accept my suggestion and here are some outlines that I would like to share with all of you.

What is Lean Coffee ™?

Lean Coffee ™ is a structured, but agenda-less meeting. Participants gather, build an agenda, and begin talking. Conversations are directed and productive because the agenda for the meeting was democratically generated. Jim Benson and Jeremy Lightsmith founded the Lean Coffee ™ movement in Seattle in 2009.

The Lean Coffee ™format is essentially an approach to facilitate learning and collaboration through group discussions. The ‘Lean’ part of the name has its roots in Lean Thinking and the ‘Coffee’ part of the name obviously comes from thenice drink that we drink to live.

How it works

The protocol, borrowed and modified from the Sydney Lean Coffee group and Limited WIP Society, is as follows:

  1. Create a small Kanban board with four columns – To Discuss | Discussing | Discussed | Outcome.
  2. Brainstorm topics that everyone would like to discuss and note down each topic on Index card (or sticky note). Everyone presents his or her topic in a couple of sentences.
  3. Use dot voting (or initials) to vote on each of the topics.  Each person gets two-three votes. You can vote ones or more than ones per topic.
  4. Add all topics to the “To Discuss” columns on a Kanban wall, with those that received the highest votes at the top.
  5. Do a quick calculation on the  time in hand divided by how many topics you would like to cover. Decide the length of conversation per topic.
  6. Discuss each topic in turn. Move the index card for the topic into the “Discussing” column. Initially, ask the proposer to explain the topic, then go round the table to give an opportunity for everyone to provide an initial comment followed by open discussion.6.1 When the topic is done, move on to the next one.  The topic proposer decides when the topic is done, and moves the index card to the “Discussed” column.

    If someone disagrees, then a quick vote can justify to discuss it further Otherwise, if the majority disagree to discuss any further then mark the topic as “Discussed” on board. The outcome can be noted down on the wall for further actions.

  7. At the end of the overall Lean Coffee ™ session, run a quick retrospective.  What did you like? What  you did n’t like? What are ideas for improvement?



I am delighted to tell you that it has been a major success after implementing this process. Here is a small snippet of our meeting.

  • Because every step is time-boxed. There are very limited possibilities for time wastage,
  • Every topic was appreciated and important points were discussed first.
  • The attendees collectively  ensured that the session was a safe space where opinions were respected. There were no stupid questions and nobody lambasted anybody for what they had to say.
  • There were disagreements but those were discussed in a grown-up manner rather than becoming heated arguments.
  • There was no moderator to make this happen. The attendees moderated themselves.

So if you were waiting for the perfect time to seize the opportunity of building an effective meeting session, the time is now.

Get lean coffee process works for you.



Some sites for Lean Coffee ™ Meetups around the world:

Seattle Lean Coffee ™.

Lean Coffee(tm) San Francisco.

Lean Coffee(tm) Sydney.

Lean Coffee(tm)Toronto.

Custom Json Converter For Ember Data relation with WebApi2

Currently, I am writing WebAPI for Ember Front-end. There is a great requirement in Ember to send relationship of any object with their ID only.

class Address 
 public int id;
 public string location;
 public string postcode;
class Employee 
   public string Name {get;set;}
   public ICollection<Address> Addresses { get; set; }


The default behavior of Json.NET Serializer is it will send Employee record with collection of Address that has all fields i.e. location, postcode, id.

 "Name": "Amit"
 "Addresses" : 
 {"id" : 1, "location" : "XX", "postcode" : "XX" },
 {"id" : 2, "location" : "XX", "postcode" : "XX" }

I want to modify JSON.NET so that when I am serializing a Model from my API it sends only an array of IDs for a composite Collection object.

i.e. The above serialization should look like:

"Name": 'Amit',
"Addresss" : [1,2]

You can get the result you want using a custom JsonConverter such as this:

/// <summary>
 /// Defines the custom JSON Converter of collection type that serialize collection to an array of ID for Ember.
 /// </summary>
 public class IDWriteListConverter : JsonConverter
 /// <summary>
 /// Define the property name that is define in the collection type.
 /// </summary>
 private readonly string keyname = "ID";
/// <summary>
 /// It is write only convertor and it cannot be read back.
 /// </summary>
 public override bool CanRead
 get { return false; }
/// <summary>
 /// Validate that this conversion can be applied on IEnumerable type only.
 /// </summary>
 /// <param name="objectType">type of object</param>
 /// <returns>Validated value in boolean</returns>
 public override bool CanConvert(Type objectType)
 return typeof(IEnumerable).IsAssignableFrom(objectType)
 && objectType != typeof(string);
public override object ReadJson(JsonReader reader, Type objectType, object existingValue, JsonSerializer serializer)
 throw new NotImplementedException();
/// <summary>
 /// Write JSON data from IEnumerable to Array.
 /// </summary>
 /// <param name="writer">JSON Writer</param>
 /// <param name="value">Value of an object</param>
 /// <param name="serializer">JSON Serializer object</param>
 public override void WriteJson(JsonWriter writer, object value, JsonSerializer serializer)
 JArray array = new JArray();
 foreach (object item in (IEnumerable)value)
 PropertyInfo idProp = item.GetType().GetProperty(this.GetKeyName());
 if (idProp != null && idProp.CanRead)
 array.Add(JToken.FromObject(idProp.GetValue(item, null)));
public virtual string GetKeyName()
 return keyname;

In your model, wherever you have a collection of something where you only want the IDs, decorate the collection property with a [JsonConverter] attribute specifying the custom converter. For example:

class Employee
 public string Name { get; set; }
 public ICollection<Address> Addresses { get; set; }

When the collection gets serialized, the converter will be used, and only the ID values will be written out. Demo:

class Program
 static void Main(string[] args)
 Employee emp = new Employee
 name = "Joe",
 Addresses = new List<Address>
 new Address { id = 1, location = "foo", postcode = "bar" },
 new Address { id = 2, location = "baz", postcode = "quux" }
string json = JsonConvert.SerializeObject(emp);



“Scrum Shortcuts without Cutting Corners” – What’s new for me ?

I have been reading this book and I am fond of the way Ilan has managed to mix a right combination of his experience in Agile and his sense of humour. It feels like he is sitting in front of me and teaching the same.

This book is small and sweet.  If you have been an Agilian like me then I would prefer you to have this book on your shelf.

Although, I have learned many new thoughts in this book, and I would like to highlight the top 5 points that I felt is quite interesting.

1. Define Your Technical Tasks as User Stories

Whenever I have been assigned a user story, I tend to create tasks in the form that one technical person would like to hear. However, it is quite interesting to read in this book that there is an another better way to define your tasks, i.e. Define your technical tasks such that it make sense to the Business (Product Owner) as well.

Well technically it makes no sense that Business People would like to know about these tasks. However, I guess it will be good to speak their language so that they can understand that we are doing tasks to accomplish actual User Stories.

Let’s put it in a simple way that every task should aligned with Business Value. Otherwise, it should not exists.

An Example:

As a user I would like to create a shopping basket so that I can checkout more than one item.

Instead of defining your tasks as

  • Database Layer
  • Create Functional Test
  • Generate Test Data
  • Create HTML PAGE WITH CSS classes for Links and Button
  • Create Server Side Component for Card Management

You might want to reword your tasks as:

  • Develop a mechanism that persist the basket against loggedin user (including test design and automation)
  • Develop a Add Remove Functionality along with number of items, that will add remove items from current user basket (including design, test, sample data).
  • Develop Navigation Page Functionality.

The main benefit of this approach is, after a task is done you can actually show it to the Product Owner. It is because the user story has been divided into sub tasks that can work independently. 

2. Definition of Done (DoD)

So far all I knew that “User Stories” needs “Definition of Done”. However, as per IIan book there are two other places where definition of done can be beneficial:

Task Level

We should define DoD for Tasks as well. This way the performance against User stories can be measured. This can be used as a measurement tool within the team that specific tasks are done.

Release Level

Release should have Definition of Done as well. That includes:

  • All code related to the release has been successfully deployed to the production level.
  • The smoke testing has been executed.
  • End-users have been trained,
  • The release has been accepted by the Product Owner.
3. GIFTS – Daily Stand-up Meeting

IIan has referred few techniques to remember his messages. One of it is: GIFTS.

Good Start, Improvement, Focus, Team and Status.

Making SCRUM meeting (infect any meeting) productive is as important as delivering a right product.

GIFTS emphasises some qualities that can be implemented for Daily Standup meeting.

Good start: Daily Scrum meetings should be about giving energy to the team; so don’t take debates or make your stand-up meeting as a problem-solving session. Instead, the energy should come from each member through the sense of purpose that they are working on and the urgency of delivering the same.

Improvement: If I ask you to remember the last question that Daily Stand up ask is – “Do I have any impediments or blocks?” This question is commonly ignored when there is no blockers. It is advisable that Scrum Master keep a note on that this question has been answered by everyone; even if it is “NO Blocker”.

After all, we cannot fix problems that we don’t know about so a large part of stand-ups is about exposing problems to allow us to improve.

Focus: Please keep your meeting to the point. There is always going to be some points, suggestions, that needs to be discussed. However, the focus of this meeting should be on current tasks in hands i.e. Sprint.

I also liked his idea of using ball (play ball) between meeting so that everyone is active in the session. Another point he has emphasis on making sure that the speaker is addressing entire team rather speaking to scrum master only.

Team: My way is right way – well technically I heard this point many time and I hate that when one cannot adapt on situation. I guess IIan is mentioning the same about having a good team is all it matters to have a successful sprint. Hence he is emphasizing on communicating, working, and helping each other by sharing obstacles.

Status: Here is an interesting take from his book:

The status (What did you do yesterday?) should have two sub-questions:

  • How is the work progressing?
  • Is there anything else interesting that the team should know?


Read more about this idea on page 108. And you will find on Page 110 that he has shared some thoughts on giving an award to the person who broke the build  🙂

4. Risk Takers and Mistake Makers

Five years back when I first got to know about Agile Manifesto, I honestly felt that what is so new about in Agile?

I’ve been improving since Age 1.
I have been communicating when I need food; either crying (baby milk) or by earning a bread.

One way or another Agile Manifesto has been here. But what has made Agile so special? And most importantly why people are not adapting Agile?

IIan has answered very well.


He has further shared his knowledge about how Facebook devs’ face the fear. There is a fear of Change, Fear of cross-functional team. Even I would say that Fear of Failure has made us to write lengthy technical documents so that we don’t leave any corners’; and we all know about how effective waterfall is!

Another fear he has talked about the Fear Of Exposure ; Some developers just like to be left alone in a corner to focus on their work and can become quite defensive about perceived regular inspection of what they are working on.

Agile emphasis on – What you make should be aligning to the Business Values. Thus, Agile and TDD goes side by side. TDD is about Test Driven Development that always force you write what is required. Agile is also the same thing about getting Business Values. Thus you will write code but only if it is required.

Fear of Making mistakes – Let me be honest here that I have been told that there should not be any bug in my code, otherwise, there is a performance concerns.

Let me be honest here again that if you are going to give me such environment that produces fear then my whole energy will drain into saving myself. I will not be any creative at all.


5. Some meaningful Matrix

IIan mentioned about the importance of two more matrices. These are:

Sprint Interference: That assists teams with their sprint capacity planning:


Interference Matrix

Remedial Focus: That enables team to gauge how much of their collective effort is being spent on bug-fixing as opposed to working on new requirements.


In conclusion, This book  is simply a collection of breath taking truths that you have been facing in implementing Agile. There are many other good tips present in this book, such as – The Seven P’s – Proper, Prior, Planning, Prevents, Piss, Poor, Performance. However, I found that the above five points are quite interesting to read and I would like to implement this in my next Agile Journey. 

And remember, you are learning, you are planning, and it is an ongoing process…

… Be Agilian, Be Productive…


Combining Kanban with Scrum: A Practical Approach

In the past there have been many debates on whether or not Kanban or Scrum is more powerful. Although both make their own solid points; points so different that it would seem rather impossible for one to dovetail them, there is, in fact, a way to combine both Kanban and Scrum. Let us examine how these two methodologies can work together with a practical approach.

When it comes to both practices, you can sum it up as such: perceivability & restricting work in advancement. Kanban is light to the point that it doesn’t give sufficient direction to groups embracing something else such as fell improvement. There have been groups that have not been equipped to adapt to the entire procedure themselves. Because of this, groups need a method for social occasion necessities, as well as a way to solve issues with group development while conveying business esteem and handling money issues.

Scrum, on the other hand, works really well for software development. It is a great process for building fantastic groups, especially when it is accomplished in the correct manner. Unfortunately, it is not often done so. But, because of it its potential, it is worth trying to integrate it with something such as Kanban.

Finding a way to integrate the greater part of this would take immense measure of time andexertion, whichcould often be squandered under ill care. This is, naturally, not the desired effect of the combined Kanban and Scrum.

What would work, then? The answer now lies in the work of analysts.

In the first test, analysts took the basic theories behind each approach to test out a way to make both of them work together. In order to do this, Scrum and Kanban had to be consolidated. In the test, they took both a Windows sysadmins that upheld lab system and Linux sysadmins that backed working system, as well as associations between destinations. There were even 1700 clients that were taken into the study to figure out how the consolidation of each was to effect workers. This was necessary for this test, but made it exceptionally harder for the analysts to track specially appointed work, which was later assessed for half of the aggregate limit.

To do (Windows Team)(notes posted on wall) To Do (Linux Team)(notes posted on wall)
On Hold Person A Person D On Hold
Person E Person F Person B Person C
Done Rejected

(A representation of how work was divided on the board with the first test)

There was an organized board in the space where the combined theory was truly tested out. There were lines that separated the work that the Windows team was to do, and the work that the Linux team was to do. This was called the queue. People were to then place their note, or job, in their square while it was in the process. Essentially, this is the influence of Kanban.

In the test, the problem laid in the integration of Scrum. This is because Scrum handles maintenance in a poor way. Even when they try to provide a solution, it often results in unpredictability for the team. As such, analysts had to switch to a new method.

This new method dealt with three teams instead. This dynamic would include two teams that worked using Scrum, and one that worked with Kanban. Instead of what was done above, these members were rotated every sprint. The developer was a part of the Kanban team every third sprint, and the Scrum teams, instead of honing in on the support pot, put their attention on user stories. At the same time, Kanban handled support and maintenance, taking that job away from the Scrum team. As a result, the developers better understood the work they were putting out there, and why it is being created. It created a high responsiveness that yielded to happy users, which ended up with more profit in the end. By continuously working, the sprint backlog was improved. All in all, this method proved to be much more practical in the long run.

repeated sprint cycle

(Illustrates the sprint cycles of the second test)

Still, even the most practical methods have a downside.Unfortunately; this method disallows members of the Kanban team from being able to depend on the task being completed by the other team.


By having a two Scrum teams and one Kanban team, with developers overlooking Kanban progress in every third sprint, users eliminated such hindering processes such as failure demand and support pot found in Scrum. As a result, the teams were able to hold an objective outlook and were allowed to use which ever method they believed to be most effective at the time, whether it be whiteboard architecture, pair programming, or other methods, making the work group more agile than ever. Even with the downfall of both teams not being able to depend on the task of the other, this second test proves that there is, in fact, a practical approach to combining Kanban with Scrum for everyone to benefit from.