After watching (http://www.ted.com/talks/daniel_kahneman_the_riddle_of_experience_vs_memory.html) Daniel Kahneman, I couldn’t help and wonder about how experience and memory impacts my world of Project Management and Business.
To summarize the talk (which I highly recommend you watch), we have two independent perspectives, the now (experience) and the past (memory), which we use as a measure for a series of feelings. In other words, we feel stuff as a result of both: what is happening now and what happened in the past. What complicates things is that we quickly forget what happened a few minutes ago and are left with the memory which is a subset of the actual event.
It may seem at first like this is splitting hairs, but when I started to think about this from the perspective of teams working together I saw a conflict that arises in business and projects. Goals in projects are often written in the form of “when we’re done with this project we have (insert result here).” These types of goals are written from the ‘memory’ perspective and are results or event oriented. For example, the goal ‘Acquire 3 new customers this month’ says nothing about day 14 of the month and what needs to be done that day to succeed per the defined goal. As Mike Cohn writes (http://blog.mountaingoatsoftware.com/advantages-of-the-as-a-user-i-want-user-story-template) a user story in Agile Software Development is often in the form of “As a <type of user>, I want to <some goal> so that <some reason>”. Both these models are great, they just don’t consider the experience perspective of getting to the result.
On the other hand, the experience perspective is very relevant to the person accomplishing the goal. It’s what makes every day ‘fun’ and has a huge impact on how we spend our time. I’m a huge believer that if something isn’t fun (or at least worth the effort), it’s probably not sustainable.
Kahneman doesn’t make any assertions as to the right amount of experience or memory. He merely states that we should consider both. In software projects, if we omit either of these perspectives we’re doomed. If we’re not satisfying the business objectives or memory perspective, we lose the funding and the reason to solve interesting problems. If we’re not satisfying the experience perspective, we lose the great people that are working on the project who care about interesting problems.
Agile solves this challenge by, on the memory side, defining user stories, and on the experience side, providing the time in a sprint/iteration to implement the functionality to enable a set of user stories. This provides an operating model for the team to implement the user stories. The solution architecture provides the operating environment for the user stories. Both the operating model and the operating environment provide infrastructure for a better experience for the team now.
After watching (http://www.ted.com/talks/daniel_kahneman_the_riddle_of_experience_vs_memory.html) Daniel Kahneman, I couldn’t help and wonder about how experience and memory impacts my world of Project Management and Business.
To summarize the talk (which I highly recommend you watch), we have two independent perspectives, the now (experience) and the past (memory), which we use as a measure for a series of feelings. In other words, we feel stuff as a result of both: what is happening now and what happened in the past. What complicates things is that we quickly forget what happened a few minutes ago and are left with the memory which is a subset of the actual event.
It may seem at first like this is splitting hairs, but when I started to think about this from the perspective of teams working together I saw a conflict that arises in business and projects. Goals in projects are often written in the form of “when we’re done with this project we have (insert result here).” These types of goals are written from the ‘memory’ perspective and are results or event oriented. For example, the goal ‘Acquire 3 new customers this month’ says nothing about day 14 of the month and what needs to be done that day to succeed per the defined goal. As Mike Cohn writes (http://blog.mountaingoatsoftware.com/advantages-of-the-as-a-user-i-want-user-story-template) a user story in Agile Software Development is often in the form of “As a <type of user>, I want to <some goal> so that <some reason>”. Both these models are great, they just don’t consider the experience perspective of getting to the result.
On the other hand, the experience perspective is very relevant to the person accomplishing the goal. It’s what makes every day ‘fun’ and has a huge impact on how we spend our time. I’m a huge believer that if something isn’t fun (or at least worth the effort), it’s probably not sustainable.
Kahneman doesn’t make any assertions as to the right amount of experience or memory. He merely states that we should consider both. In software projects, if we omit either of these perspectives we’re doomed. If we’re not satisfying the business objectives or memory perspective, we lose the funding and the reason to solve interesting problems. If we’re not satisfying the experience perspective, we lose the great people that are working on the project who care about interesting problems.
Agile solves this challenge by, on the memory side, defining user stories, and on the experience side, providing the time in a sprint/iteration to implement the functionality to enable a set of user stories. This provides an operating model for the team to implement the user stories. The solution architecture provides the operating environment for the user stories. Both the operating model and the operating environment provide infrastructure for a better experience for the team which increases the probability of a successful project.
