Major change from Scrum to Kanban

Simplified regular meetings

Kanban only have daily stand up, the stand up focus on block discussion. Planning, demo and retrospective are held as needed. Those meetings are not regular mandatory any more.

‘One person’ planning, estimating and reporting

As Kanban doesn’t have Sprint and employ a principle that release should happen as soon as feature ready, planning only means changing priority of stories for Kanban. Team just focus on in-process stories and blocks, should avoid any overhead on answering ETA questions. The request of ETA or release date become a overhead of Agile Coach, he or she could use any methodology to bridge the needs from stakeholders. A good technique could be velocity by stories, by managing all stories to similar small sizes, Agile Coach could work with team to track completed story count per week. Regard a question like ‘how long can we deliver the new story?’, change that to ‘how many small stories can we break down?’

In another word, for question like ‘when the team could deliver the feature?’, the answer from Kanban team is ‘team will deliver it as fast as possible’. For any other question, Agile Coach should work with PO to facilitate the answer.

Team might be in a organization where regular reporting is needed. Agile Coach should be responsible for that and bring as little as possible overhead to team.

‘On demand’ demo and retrospective

Demo is a communication tool to use in anytime feedback needed from team or stakeholders. It will not happen in regular base, just when needed.

Any one in team could request retrospective on specific topic. Any team aligned action become a story on board at once as highest priority. For any action team think should be taken in the future, that become useless and team don’t need any story follow up. If an action is a behavior principle for team, team agreement should be a document tracking the new principle.

WIP limit is very important

Work In Process (WIP) limit is the most important tool to help team realize the block and test how good they are on collaboration. The limit should be defined smaller than team size and calibrate with time. Basically the more effective the team is, the smaller of limit is. When never limit is reached, pair programming or collaboration should happen to resolve limit issue as soon as possible.

Column/Phase DOD is introduced

Kanban doesn’t breakdown story into tasks, it use Column/Phase like ‘Breaking Down’, ‘In Process’, ‘Test’ to track story status. Team should agree on DOD when story could exit the current phase and move to next. A good technique is using partial release DOD in phase DOD to make sure release DOD spread to all phases.

Release and celebration

Depending on CI/CD capacity of team, team should release Done story as early as possible. Without a regular demo like Scrum, Agile Coach and manager should consider a more prompt way to celebrate team achievement with release.






Kanban takeaway (vs Scrum)


  1. No big difference between two methodology. Kanban is simpler and flexible. For team already has an good Agile practice, Kanban could be more suitable as it just keep the essential core of Agile so team could act more prompt on changes.
  2. Kanban doesn’t have a strong dependency on team commitment, it might reflect the nature of the human. Just keep Agile, don’t bug yourself on unite team commitment.
  3. No regular Planning, Retrospective and Demo, just focus on working. Those activities comes on demand. So team is able to accommodate stakeholders’ schedule on communication. Team need to Agile Coach to realize the proper schedule and topic for communication.
  4. Stories can be breakdown to similar small size stories. Instead of estimating by points, release planning can be estimated by the count of small stories. And the team velocity comes a way like done stories count per week.
  5. Release planning will become harder in Kanban. Organization should be ready on be more open on ‘Deadline’ stuff. IMHO,  the openness is happening anyway. As long as team is Agile enough, stakeholder will not focus too much on the ‘plan’ or ‘release date’. Everything become priority issue.
  6. DOD is same as Scrum. It is the heart of Agile collaboration.
  7. Without regular demo, a more easy/random celebration would be necessary for Kanban. Demo will only happen when requested or Agile Coach recognize the necessary for requirement feedback.
  8. WIP limit is a major tool for team tuning. The more effective team is, the smaller WIP limit is. With a team everyone is developer, WIP limit is quite easy to review and change.

With an Agile heart, Kanban might be a better approach to adapt team reality and focus on efficiency.

Personal Scrum Reading Takeaways

Agile could be used to help personal project or life chores. There are several persons already get it practiced.

To reduce stress of parenting, Kanban board could be used to manage house chores so kids enjoy cleaning table after breakfast by moving task Done.
Several major takeaways from personal practice:
1. Start from small backlog like reading a short book.
2. Make backlogs hours for recursive activity like ‘5 hours walking’ or ‘4 hours magazine reading’.
3. Avoid boring chores becoming backlogs, like ‘brush your teeth’, consider those are overheads of Sprint.
4. A week Sprint is a good fit to life. Keep retrospective/planning/daily startup on schedule and run it fast.

Migrate VMs between Azure subscriptions

Azure provide a very poor mechanism to share VM images between subscriptions, while Amazon could easily share images between account.

The following page provide enough PowerShell to automate the whole process, but it can’t work if we have VNet configuration for source VM.

I revise and add support on VNet configuration, and package scripts to a file.

Just use a command as below, you may migrate VM to another subscription.

.\CopyVmBetweenSubscriptions.ps1 -SourceVmName SrcDevBox -SourceServiceName SrcDevBox -SourceSubscriptionName “Sub1” -TargetServiceName DevBox2 -TargetSubscriptionName “Sub2”

Enjoy it!

Migrate Windows Server from AWS EC2 to Azure

I need to migrate several Windows VMs from AWS EC2 to Windows Azure.

The general practice AWS provide is using EC2 Exporting service to export VHD for EC2 instance.

After I set up many environment variables,S3 bucket and permission for VM export account, I am able to run export command on EC2 CLI. But it is disappointing that the error message “Only imported instances can be exported.” showed.

Then I head to another solution to make VHD inside the Windows server by using a tool Disk2vhd.

It is pretty easy to export VHD by the tool.

With VHD ready, now I could use Azure Powershell to upload VHD file (Add-AzureVHD command will convert VHD to fix type automatically), create OS disk from VHD and create VM instance from the disk.

So far I suspect that it is most fast way to move VM from EC2 to Azure if you could log in the Windows Server.

Build complex cross Azure subscription Windows lab by using Azure Site to Site VPN

Azure Site to Site VPN (S2S VPN) started as a method to connect Azure VNet and on premise network. Now it appears as a good solution to connect Azure VNets as well.

Equipped with Azure S2S VPN, we are able to build more complex Windows lab across Azure subscriptions. The diagram below show the idea. Compare to P2S VPN, S2S VPN is a much stable solution and could reserve static IP Address for DNS and Domain Controller.

Azure Site to Site VPN

The steps to make that happen are:

1. Create VNet per subscription.

2. Create gateway for each VNet. You may need to export VNetConfig, manually add local network and import config at first before that.

3. Create local network and build connection for each VNet. You must use VNetConfig file to do that. And gateway should be provisioned already as local network will need that.

4. Make all the VPN connection share the same gateway sharedkey.

Step 3 and step 4 will be very time-consuming as you need to create N*(N-1) local network if you have N VNet to connect together. I wrote a script to make step 2-4 automated.

All you need to do are step 1 + a .csv file to describe VNets + SharedKey.

The csv file looks like


AddressPrefix should not overlap with each other and GatewaySubnet not overlap the existed Subnet in the specific Vnet. You can find correct GatewaySubnet by adding a new subnet in Vnet config (don’t save).

Attach the code URL:

Build cross-subscription Windows lab by using Azure Point to Site VPN

We have several Azure subscriptions each of them has fixed budget, and we would like to build an united development lab base on those subscriptions. Unfortunately the Virtual Machine or Virtual Network in different subscription can’t communicate with each other under Azure policy.

To resolve the barrier, I explored and developed the following methodology which leverage Azure Point to Site VPN to connect Virtual Machines under multiple Azure subscriptions into a single Virtual Network. The diagram below show the idea by an Exchange lab.

P2S across subscription

The first step is setup Virtual Network and Point to Site VPN, you may follow the instruction from Azure:

Next you can setup DNS server and Domain Controller in virtual network, those servers need static IP which it is hard to guarantee if you use P2S VPN to join virtual network.

After you create new VMs in other subscription and install VPN to connect to virtual network, you will need a method to connect P2S VPN automatically during start up before user log on. Here you may use the following script run when start up to make that happen.

The major idea of the script is monitor whether the DNS server can be contacted and then try to resume VPN connection if failed. Also it will refresh route table and register DNS record via VPN connection.

Enjoy it and leverage multiple subscriptions to create an united lab.

The following link help me during the scripting.

Practice of migrate local Exchange testing labs to Azure

We need to migrate 5 local Exchange testing labs (15 VMs, 6 Domain Controllers) to Azure VM, and run Automation testing against those labs after migration complete. This blog elaborate the steps which I tried during the practice.

1. Prepare VM images and upload to Azure.

The local labs host on Hyper-V server. So we just use VHD file as our base images. Azure team provide a guideline to upload VHD and create VM:

In the guideline the VM should be sysprepped before upload, but the VHDs we got are non-sysprepped because they are exported and uploaded to AWS S3 in advance.

For non-sysprepped VHDs, a necessary step for Azure is turning off Windows firewall on PowerShell and remote desktop port. Azure might failed to modify the firewall setting if your VHD is non-sysprepped, then you have no way to connect into your VM.

The VHDs need to be uploaded by Powershell Add-AzureVHD because Azure only support fixed disk type and the command will convert dynamic VHD in upload process.

2. Setup Virtual Network and create VM

The virtual network need to be setup at first, because we can’t modify VNet setting after VM is created.

As the VHD is non-sysprepped and we don’t want Azure to modify our OS settings, we need to create OS disk from VHD, then create VM from OS disk. In this way, we tell Azure just use OS in the disk rather than modify OS as Azure template. It is different with creating VM from image which will copy your VHD to a new one. So it would be better to backup your VHDs before you make major change on OS if you create VM from disk.

After the VM is created, Azure will try to install VM agent in your VM. The operation always fail in my experience, and I believe it is because Azure can’t get administration access in your OS. So you need to install VM agent manually once you could RDP to the VM.

3. Resume Lab

DNS server should be the first VM resumed as other VMs depend on that. DNS server and Domain Controller will need static IP, a PowerShell command Set-AzureStaticVNetIP can be used.

Get-AzureVM ServiceName myvm -Name myvm | Set-AzureStaticVNetIP IPAddress ‘’ | Update-AzureVM

Then you can set DNS server IP address in VNet configure so other VMs could use that DNS server for internal lookup.

Domain controllers should be resumed before Exchange servers. Here we need to discuss more about DNS server setting. I found a robust DNS setting on Azure is setup AD integrated DNS server on domain controller, then setup stub lookup zone on DNS server and point to domain controller. In this way, you don’t need to worry about time synchronization between DNS server and domain controller even you need to frequently shutdown and start up those servers.

For those Exchange servers, an important thing is reconnecting to domain controllers because the DC don’t know who is who after Exchange servers are recreated on Azure. We can reset computer account of the Exchange server on Active Directory Users and Computers, then quit and rejoin domain. Don’t attempt to quit and rejoin domain before reset computer account! That will make your Exchange server a new SID in Domain, it might break a lot of permission or relationship in lab.

It would be worth to rebuild trust if labs have trusts before, because I found some weird issue go away after I rebuild the trusts between domains.

Exchange is designed to start all the time, and have a lot services need to be running to keep Exchange work. But we need to stop and start those labs everyday for Automation Testing. For those services failed to start automatically because dependent service have not been started, we can put them into Automatic Start (Delay) status. Then those services have more chance to start automatically.

4. Azure limitation

Resume labs on Azure have some limitation.

Azure only support Server OS Windows 2008 and Windows 2012 series. So if your lab heavily need client OS or Windows 2003, Azure might not be your choice.

Azure Virtual Network don’t support broadcast. So you had better use FQDN in all your automation testing.

Azure Virtual Network can’t assign IP address per request, can only assign 1 IP address for 1 VM. So those features depends on new IP assignment like Exchange DAG can’t be deployed on Azure.

Use powershell to integrate fitnesse suite testing on Azure VM

I need to trigger Fitnesse test suite and get result in Teamcity build. But the Fitnesse server is different with Teamcity server and I don’t want to install Teamcity Agent on Fitnesse server. And both servers are on Azure VM.

My plan is using Powershell to trigger Fitnesse test suite and retrieve result through HTTP request. The HTTP Uri I used is like: http://%FitnesseServer%/%TestSuite%?suite&format=xml

At the beginning, I use Invoke-WebRequest to send http request. That works well in the suite which execute less than 5 minutes. But once the suite going longer, WebException: “The operation has timed out” is thrown and my Powershell scripting failed to complete.

After further investigation, I found the problem is that Fitnesse will not response anything before the whole suite test is complete. That will hit a lot of timeout mechanism in System.Net.

Then I rewrite my script by using System.Net objects directly, and set all the Timeout properties of HttpWebRequest and related ServicePoint to a proper time. But the ‘timed out’ issue still occur. That move my eye on server side rather than client side.

At last I find that Azure Load Balance has an ‘idle timeout’ setting of 4 minutes. That means if your connection is idle for 4 minutes, Azure may not maintain the connection between service and your application. So the solution is using $request.ServicePoint.SetTcpKeepAlive() to send keep-alive packet during idle time.

Please find the PowerShell script as below, hope that help you to handle similar scenario.


[System.Net.ServicePointManager]::MaxServicePointIdleTime = 30*60*1000
$request = [System.Net.HttpWebRequest][System.Net.WebRequest]::Create($Uri)
$request.Method = “Get”
$request.KeepAlive = $true
$request.Timeout = 30*60*1000
$request.ReadWriteTimeout = 30*60*1000
$request.ProtocolVersion = [System.Net.HttpVersion]::Version11
$request.ServicePoint.ConnectionLeaseTimeout = 30*60*1000
$request.ServicePoint.MaxIdleTime = 30*60*1000
$rp = [System.Net.HttpWebResponse]$request.GetResponse()
$stream = $rp.GetResponseStream()
$reader = New-Object System.IO.StreamReader($stream)
$ret = $reader.ReadToEnd()
if ($null -ne $stream)
if ($null -ne $reader)
if ($null -ne $rp)

The link which help me: