Agile process as a product

I am a huge believer of Design Thinking and it is gaining some traction outside of the UI world. But it’s still pretty unknown by the programmer bunch. Often when thinking about UX ( User Experience ), people think about Graphical User Interface (GUI). It’s almost taken as synonymous. But an UX designer would certainly disagree with that.

An UX professional can be from an artist, a programmer or an analyst background. But one thing they need essentially is the understanding of users. Because the users are most often human, an UX professional needs to understand human behaviours. It’s probably a stretch to call them an expert in Behavioural Science, but I think they’d think so.

This got me thinking about the time I was studying User Experience Design and Human Computer Interaction (HCI). More specifically the Shneiderman’s “Eight Golden Rules of Interface Design”. The golden rules are designed around the limitation of human’s limitation to process information. And that makes me wonder if Agile frameworks are built on those rules. Let’s use Kanban as an example and see we can map them to the rules.

The golden rules in practice

Strive for consistency

Consistent sequences of actions should be required in similar situations; identical terminology should be used in prompts, menus, and help screens; and consistent commands should be employed throughout.

Kanban has the “pull” system in conjunction with the “Limit WIP” principle. Both elements has the consistency built in it. Pull system dictates that you can only pull from left column to right column. this is consistent throughout the board. While the limit is defined to WIP, it’s applied to all columns including todo column. But I guess Icebox and Done columns ( when used ) are the exceptions.

Enable frequent users to use shortcuts

As the frequency of use increases, so do the user’s desires to reduce the number of interactions and to increase the pace of interaction. Abbreviations, function keys, hidden commands, and macro facilities are very helpful to an expert user.

I guess this can be a more philosophical than actual application of tools. What I can think of is the use of continuous improvements to improve efficiency of process. The process should become easier to follow and more efficient as the team members build more trust and better relationship. If it doesn’t, a tool such as retrospective can be employed to facilitate improvements.

Offer informative feedback

For every operator action, there should be some system feedback. For frequent and minor actions, the response can be modest, while for infrequent and major actions, the response should be more substantial.

Visualisation is a big part of Kanban. The board is meant to give feedback on progress. How busy are we?. What happen if we pull this here?. We have too many tickets in QA column. When we do something about it we can see the board changes. When we are closer to the end of an iteration we can see the todo column drying up.

Design dialog to yield closure

Sequences of actions should be organized into groups with a beginning, middle, and end. The informative feedback at the completion of a group of actions gives the operators the satisfaction of accomplishment, a sense of relief, the signal to drop contingency plans and options from their minds, and an indication that the way is clear to prepare for the next group of actions.

Tied together with visualisation, you can start to see the importance of closure. A closure is achieved when a card reaches the end of the board. When the todo column finishes. When a card is pulled out of a column. Scrum do Sprints and pretty much reset every iteration to yield closure as well, indicating an end of something.

Offer simple error handling

As much as possible, design the system so the user cannot make a serious error. If an error is made, the system should be able to detect the error and offer simple, comprehensible mechanisms for handling the error.

Before error handling is the error detection. JIRA has this cool feature that will highlight columns that broke the limit. The growing number of tickets left in the todo column at the end of an iteration will indicate problems to the flow. When a ticket stays in a column for too long.

Process design to handle these problems should be simple. When a limit is broken, you shouldn’t pull more items into it. When there’s many leftover, take less tickets during the next sprint planning.

Permit easy reversal of actions

This feature relieves anxiety, since the user knows that errors can be undone; it thus encourages exploration of unfamiliar options. The units of reversibility may be a single action, a data entry, or a complete group of actions.

I can’t think of any Kanban specific tools for this, but Continuous Integration is pretty much what this is trying to cover. Having a good test coverage and an easy and continuous build and test setup such as Bamboo or Buildkite will help to improve confidence. And the ability to rollback is a pretty much the Undo button in every good UI design.

i like this rule very much because it doesn’t trust human being to do the right thing all the time. It acknowledge that shit happens and it shouldn’t be human’s job to constantly looking over their shoulder. It should encourage creativity instead.

Support internal locus of control

Experienced operators strongly desire the sense that they are in charge of the system and that the system responds to their actions. Design the system to make users the initiators of actions rather than the responders.

When I read this rule I think about micromanagements. The pull system enforces autonomy of picking up a task rather than being assigned to a task. You can still be told to pull a ticket, which is bad. But when someone is ready for a next task, without the intervention of the managers, they should be able to confidently know what needs to be done next.

To achieve that, a few things needs to be done first. Number one is to set priority as a team, and with that the prerequisite of everyone’s understanding of what the stories are through sprint planning. Next is the explicit rules such as “left to right, top to bottom”, and “Pull” system to act as the GPS, And there also need to be enough trust in the team so anyone is comfortable at making that decision for themselves.

Reduce short-term memory load.

The limitation of human information processing in short-term memory requires that displays be kept simple, multiple page displays be consolidated, window-motion frequency be reduced, and sufficient training time be allotted for codes, mnemonics, and sequences of actions.

The core of this rule in the context of process design is the effort to reduce multitasking and context switching. Not sure if it’s exactly Kanban’s principle but the general rule that my team ran on is a person only can be assigned to one ticket at a time. Kanban helps to visualise that by putting faces on cards. In a physical board, we can limit the number of face stickers in the reserve. But this constraint can be easily spotted during standup.

In the GUI sense, the board is encouraged to be simple. Reduce the number of columns. Smaller team size.

Process Improvement Plan

Process design is important. But every team is composed of different unique individuals. That makes it impossible to create a silver bullet framework. It can be difficult to start from scratch. Scrum is a good place to start if your team is new to Agile. Kanban’s first principle is to start with what you do. The next and most important step is continuous improvements. This IMHO is the core of the Agile movement. It is a never ending process of improving the process. So instead of designing a silver bullet process, we should design a process improvement plan.

But we often see the opposite in the real world. In Agile methodology, we often look at processes and tools as something to avoid. It’s understandable because the Agile Manifesto defines that we should value Individuals and interactions over processes and tools”. This value is often used as an argument against spending time talking about tools and processes. On one hand, this is a good interpretation of that value. It’s important to acknowledge it’s more important to spend time on improving interaction and individuals rather than following a set of rules. On the other hand, neglecting process could sometimes harm the interaction and individuals aspect of a team. In some of the well established frameworks like Scrum and Kanban, rituals and guidelines are often designed around people. They could help drive the interaction and individuals. But it is understandable that it can become a process pain.

Let’s take estimation for example. Scrum uses Poker Card estimation. Planning staffs often think that it’s a time consuming process with no much benefit. One of the Agile misconception is that it needs to be fast. And when it comes to estimation, people only think about that final number they need to tell their customer. When can we deliver this? Give me a ballpark! So some teams take the shortcut and get them from the team leader.

Let’s explore a little bit of a Scrum estimation ritual. Each member get a set of cards with fibonacci numbers on them. They represent “complexity” of a task. Someone, usually the Product Owner, would describe the task/project/feature/user story. Team members would then ask questions and discuss about the card. And everyone would secretly pick a number from the poker cards and reveal them at the same time. If the votes varies greatly, the outliers would need justify their votes. Revoting will happen until everyone’s happy with the estimate.

There are so much more details that goes into a simple process of estimation. There’s one about picking the baseline size, breaking down big cards, complexity vs time, equal opportunity. But most importantly for me as a developer, it forces every member to contribute and understand the story we’re playing to be able to vote confidently. It forces people to interact so they can have a confident vote.

Understanding reasons and benefit of each rituals is crucial in process improvements. Every conversation should start why do we do it and why doesn’t it work. With the help of the golden rules we can drive the discussion toward a process that is easy to use and one that people want to use.



Debugging PHP the hard way

Having to maintain a massive Object Oriented web application written in PHP, it’s amazing how many times I’ll have to use the same functions over and over again in multiple different places. I’m listing them down here before I forget.


The most used one, and the only way I can print anything right now in the application I’m working on without screwing up everything. It prints out the message into the application error log, which I then tail -f and keep it running in one monitor. Way to go multiple monitors.


How do I live without this. Even with the power of IDE ( I’m using NetBeans ), it’s frustrating sometimes to find out what the class of the object actually is. Especially in “well designed” object oriented application full of decorator and factories, it’s easy to get lost. get_class() produce the exact class of the object. Can’t live without this function.

var_export($object, $return=false)

var_dump() used to be my ultimate savior, but with the limitation on the printing into the web without breaking anything, I’ll have to print everything to the log file. var_export() does exactly that when the “return” flag is set to true. Although most of the times it ended up with recursion error, it’s still pretty useful.


Got to find the way to trace where something started. Pretty straight forward when combined with var_export() and error_log() as mentioned in one of the brilliant StackOverflow answer.

$e = new Exception;

error_log(var_export($e->getTraceAsString(), true));

What are your favorite debugging snippets in PHP?


Sharing objects between Modules in AngularJs

It turns out that sharing objects between angular modules is as simple as injecting a module into another module. Say myApp has some controllers and providers or other objects and myApp2 want to use some of those controllers. When creating myApp2, inject myApp into it and myApp2 now has access to all the objects in myApp to the extend that the HTML can use the controller from myApp without any extra codes.

// Common library of some sort
app = angular.module("myApp", []);

app.value('someVal', 'This is a val');

app.controller("controller1", ['$scope','someVal', function($scope, someVal){
$scope.someVal = someVal;

// My actual module
app2 = angular.module("myApp2", ["myApp"]);

app2.controller("searchController", ['$scope', function($scope){
// ... some controller's codes
<body ng-app='myApp2'>
<div ng-controller='controller1'>

Note that the HTML is using ‘controller1’ which is from ‘myApp’. I’ve built an app in AngularJs and going to create another one using the similar format. It also means that most of the codes are going to be shared. I’m glad that I don’t have to do much refactoring.


Slicker way to export crosstab in Tableau

Tableau has an awesome feature to allow users to export the processed data into crosstab, or I would say Comma Separated Value format.

We use Tableau to help us visualize data into graphs and charts. And our raw data is often messy and huge and doesn’t really make sense in that granular state. So the charts and graphs are really much better to look at. And even though some users are happy enough by looking at charts, some others find it important that we can get the post-calculated raw date, i.e. the numeric equivalent of the given chart.


But when it comes to a grander scale of a few thousands rows of records, The Export Crosstab to Excel just doesn’t work well. It took a very long time to work, and that if it works at all.

So, instead of exporting it to Excel, use Copy -> Crosstab function. This function is surprisingly much faster than exporting to Excel.


As a comparison, exporting 50,000 rows to Excel will take forever, and never but copying the same 50,000 rows to clipboard only takes 5 seconds.


The Magical Tableau Filtering and how to get the Tableau result limiting right

NOTE: this tutorial is based on the coffee shop sample data came with tableau desktop.

The other days long time ago, we all thought that there is a simple way to limit the results of a tableau report. Even though it’s a bit of an unwritten magic, but the legend stays true that it’s quite simple indeed.


Say that you have a coffee shop chain that is doing so well it has branches in all 4 corners of the imaginary planet of Zox. Now you have no other thing to do, you decided to look at the ups and downs of your profit throughout the year. So you decided to make a chart that looks something like this



Now you can see how much sales your coffee shop is making along the year in a very nice chart. But it’s too much information on the chart, so you decided to just show the top 3 products based on its sales.

To do that, you pulled the product field from the Dimensions field box into the Filters box on the top left corner. A dialog window will pop up and navigate to the “Top” tab. You set it to only show the top 3 products based on the total sales of that product.




All looks good so far. After looking at the chart for like 10 seconds, you got bored again. So you decided to add more fun to the chart. “How about getting the top 3 products of each product type you have, Coffee, Espresso, Herbal Tea and Tea” you thought, then you proceed to pull the Product Type field into the Filters box and make the selection box appear on the right side of the chart.


(Right click on the Product Type filter and click “Show Quick Filter”)

and tada… everything looks wrong now. It only shows 1 product, instead of Top 3 products as you’ve commanded it to show.




So you play around with the filter on the right and figured that it might be the culprit. You looked back at the pictures that you’ve screenshotted and noticed something that might be useful, the “Add to Context” option on the right click menu.


You do that to the Product Type filter and voila!! it works!!



Tableau filter by default doesn’t apply to the “Top x” filter. By adding a filter to context, it’s specifically telling tableau that the filter is to be taken contextually. Without the “add to context” option, the “Top x” will get the top x across the product type, as if the filter is not there at all.

This problem had costed me a million seconds to fix, but I hope that this short article will save some of your time.


Alteryx encoding

Have you ever get so fed up because there is no such thing as “Encoding” tool in the vast collection of Alteryx tools and you are getting a non “CSV” export file filled with unreadable characters in it? Well, You’ve came to the right place.

Alteryx uses the term “code pages” to describe encoding, or UTF-8 or Character Sets setting. What the hack is code page anyway? can’t you just say “Encoding” or “Character Set” so it’s more commonly used nowadays?

Anyway, here is the solution. First, search the Alteryx help index for “code page” and it will list you a list of encoding standards with its respective code.


Now, comes the biggest spoiler, the encoding tool is hidden inside the Formula tool as a “function” and named ConvertToCodePage and ConvertFromCodePage.






Back to PHPUnit

I have couples of the same PHPUnit Manual tabs on my browser, not because I’m referring to different parts of the lengthy documentation, but because I keep getting the same result from Google search + suggestion from those in PHP chat rooms.

I don’t know what makes it so hard to learn how to use PHPUnit. I can’t even remember what did I do the last time (which is few months ago) I try it out. First is probably the outdated PEAR project that doesn’t seems to be updated any more. Then, the tutorials that I can’t even get to work on my machine. Googling around doesn’t seems to find me what had I done wrong. And probably the installation guide I posted few months ago has already outdated.

Now, I’m stuck with the fact that my PHPUnit folder under the PEAR folder is not the same structure as what other people on the internet has. Got to continue googling for me. Wish me luck!


Sitting is Killing You

Why do you want to stand if you can just sit down. Standing is a punishment back in school. As a programmer, I might be sitting whole day. Probably the whole 24 – 8 hours of sleep – 1 hours of small walking. But people are claiming that it’s dangerous to be seated. Below is the nice illustration of the story.

Sitting is Killing You
Via: Medical Billing And Coding