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.
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 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.