Saying no, at least where appropriate, is an important tool to ensure good morale, high productivity and delivering more value.  Just saying “no” is easy, having the statement be safe and make sense requires several prerequisite conditions.   (more…)

Book Cover

The availability heuristic, introduced in Chapter 12,  states that we make judgments about an attribute based on how easy or hard it is to retrieve information about the attribute. In Chapter 13, Kahneman dives deeper into how the availability heuristic functions and provides some hints on how it can be used. (more…)

Direct Playback

Subscribe: Apple Podcast
Check out the podcast on Google Play Music
Listen on Spotify!

SPaMCAST 555 features our essay applying a simple filter to determine whether an interaction or event is collaborative. In this essay we put the simple four attribute model we introduced in SPaMCAST 554 to use.  Collaboration is an important tool, so let’s recognize what is or isn’t collaboration and stop calling everything collaboration.

We will also have a visit from the Software Sensei, Kim Pries. In this installment, Kim returns to the topic of lean software development.  In 2019, the concepts of lean and agile have become intertwined. Understanding concepts like waste is important for everyone involved in delivering value.   (more…)

Collaboration is no soft toss!

Many people have the idea of the lone innovator or the lone programmer developing solutions based on the wits to the adulation of the business deeply embedded in their subconscious.  These lone wolves don’t collaborate. The picture is wrong. Today’s business environment is fundamentally different. Teams and teams of teams are the problem-solving technique de jour.  Collaboration is an important part of solving business problems in teams. Because collaboration is so important, it is important to consider whether planned meetings, events, and interactions are set up to be collaborative before they occur.  Jonas Bull suggested a modification to the collaboration filter we have been using to evaluate whether an event is collaborative posthumously. Jonas’s suggestions (melded with Stephen Adam’s suggestions) follow below: (more…)

A Panel Discussion - Collaboration?

We recently developed a structure for evaluating whether an activity was collaborative or not.  The four-step evaluation process is important because the same activity is collaborative in one context and overhead in another.  There are four areas of activities in all software development and maintenance organizations (and I do mean ALL) that are sometimes collaboration and sometimes not, but almost always sold as collaboration.  Today we tackle the first two areas. (more…)

A Framework For Collaboration

Collaboration is one of those words that is used way too often and is conflated to cover everything from transactional to shared relationships. In agile, the term collaboration is meant more specifically to mean the scenarios where teams create shared relationships so that they can achieve a common goal that individually would beyond their capabilities. In order not to dilute the power at the core of collaboration it is important to clearly understand behaviors that it are easy to conflate with collaboration.  A high-level filter to determine whether the behavior is collaborative includes the following criteria:   (more…)

Think About It!

 

I am celebrating my birthday this weekend instead of working on the re-read of  Thinking, Fast and Slow.  We will be back next week, so in the interim, I decided to reprise and revise an entry from 2014.  I hope you will enjoy and reflect on the piece!

Teams are an important concept in most IT organizations, regardless of their development philosophy. Philosophies like Agile may put more emphasis on teams, but even in organizations that do not embrace Agile philosophies, teams are important. Dan Ariely in his Ted Talk, “What Makes Us Feel Good About Our Work” suggests that overly self-interested, cynical behavior can negatively impact organizations by reducing their ability to communicate and innovate. The same problem can occur, albeit on a small scale, at the team level. In a recent presentation, a fellow Agile coach described a team engaged in overly self-interested behavior. He described a scenario in an organization that cuts the bottom 10% of all groups annually and stated vision that IT should maximize the value it deliverers to its customers. After losing a popular team member the previous year, the team had decided to make sure that his replacement was given the worst assignments in order to ensure he stayed on the low end of the performance scale in the coming year. Their goal was to ensure that the core team stayed intact during the next review cycle. In their mind, keeping the core team together ensured that they would deliver more value to their internal customers. The behavior of the team attempted to circumvent the idea that adding new and more highly qualified personnel would lead to improved performance. Viewed from the point of view of organizational policy, the whole team was acting in an overly self-interested behavior manner, but from the point of view of core team they are acting rationally and within their interpretation of the rules as seen through IT’s vision of value delivery. The team did not believe that their behavior was at odds with the behavior the organization wanted to incent. (more…)