Activity Modeling and the Bag

This is the third and final part in this series. You can read the first two posts here:

• The Bag and the Kanban, part 1
• The Bag and the Kanban, part 2

On our last day at Kaizenconf, I participated in an action type of session where our aim was to figure out what we could do about Activity Modeling, a design method. After reviewing it extensively, we decided that we would all try to fit it into a kanban pull system and blog about it.

Activity Modeling

In essence, Activity Modeling is a technique that allows a designer to create a set of actions and operations that different users, or personas, can do using a certain software application. It involves creating files on different personas to keep track of their goals, motivations and values using, among other methods, non-directed interviews where the main question is never asked directly.

Then, using a very specific activity statement, actions are defined. From the example that was given to us at Kaizenconf, the activity statement could be: "Providing patients acute pain management services." Now an action could be: "Admit patients into the acute pain management system." Finally, operations are determined for each action: "Specify patient demographics," for example.

Our group decided that our action plan would be to incorporate Activity Modeling to Jef Newsom's Kanban technique, which I depicted in the first post of this series.

In retrospect, this seems easy enough, at least on paper! The first thing to do would be to make sure we have enough information about our main users, or our personas. This is a very important step, as it has a direct link to the "People" column in our Kanban board.

Filling up the BAG

So we have our Goal, and our personas, which we can translate to our Kanban board. Using what we know about them, we can write down their personal goals. A doctor wants to be able to edit information and wants to know what is going on at all times. A nurse might just need the history of the patient, or just what the current health care procedures that need to be performed are. Activity modeling helps us know all of this.

Our bag used to be full at this point, but let's go ahead and add a new column at the end: the Actions column. This is a further refinement on each personal goal, normally a step we were reserving for the S.A.F.E. column in the Kanban. However, since we are still in the bag, actions remain at fairly a high level of abstraction, which is good since we might have the user helping us defining them.

S.A.F.E. scenarios benefit from Activity Modeling

Now that we have refined the bag, the designer and developers can work together to fill up the S.A.F.E. column at the beginning of an iteration. In Activity Modeling, operations are defined for each action and it just seems to me that this is exactly what we are doing by creating our S.A.F.E. scenarios. Our success, advance, fail and error scenarios are operations that have been classified!

This is what really struck me in our session. Activity Modeling benefits from the S.A.F.E. scenarios idea by having its operations classified and our Kanban benefits from Activity Modeling for filling up the Bag. There is an almost perfect synergy between the two methods and it has enormous usefulness potential for developers and designers alike.

From there, developers can simply pull operations into their iteration and can keep going with the rest of the Kanban.