I've been reading Scarcity, a book by Mullainathan and Shafir. Their thesis is that our reaction to scarcity contains a hidden logic that is equally applied to those without enough time and those without enough money.

The effect scarcity has on people is that it tends to increase focus and create tunnelling. The increase in focus brings whatever is perceived as scarce to the forefront of peoples's thinking but the effect of tunnelling over emphasizes this scarcity to the point where it effects other aspects of their life.

For example, a scarcity of time or money creates a focus on those things to the exclusion of other things, such as personal relationships. The exclusion of other things means that scarcity brings new perspective and that new perspective is often detrimental to resolving the issue. That is why busy people stay busy and poor people stay poor.

Scarcity: Why Having Too Little Means So Much by Sendhil Mullainathan
My rating: 4 of 5 stars



View all my reviews

Note:

The URL to Scarcity has been updated. The original URL is at Scarcity. It is a capture by the Internet Archive from when this article was published.

I'm reading The Anatomy of Story, by John Truby. I'm reading it because I like to write and have this vague ambition about writing something worth reading someday. Thus far, I'm published on Twitter and Blogger.

The Anatomy of Story provided a new appreciation on how stories are constructed. This appreciation can be applied to movies, books and people. I was struck by the similarity between the Artist and Clown archetype and what makes a good Scrum Master. I talk about the importance of the Scrum Master in Scrum Master Selection--Critical Success Factor?

Truby describes the strengths of the Artist and Clown:

• defines excellence for a people to positive effect
• defines what doesn't work to negative effect
• shows beauty and a vision for the future or shows what is beauty but is in reality ugly or foolish

And weaknesses:

• can be the ultimate fascist insisting upon perfection
• may create a special world where all can be controlled
• simply tears everything down so that nothing has value

The Scrum Guide discusses the Scrum Master role as embodying the following activities.

The Scrum Master is responsible for ensuring Scrum is understood and enacted. Scrum Masters do this by ensuring that the Scrum Team adheres to Scrum theory, practices, and rules. 

The Scrum Master is a servant-leader for the Scrum Team.

In "Agile Methods: The Good, the Hype and the Ugly" an ACM Webinar by Bertrand Meyers discusses as ugly, the Coach and Method Keeper (e.g., Scrum Master) as a separate role (around 44:50). He says this leads people becoming a political commissars and creates a class of people who wash there hands of the result.

I'll suggest that the Scrum Master Meyer's is thinking of embody the weaknesses of the artist and clown. Those in the Scrum Guide embody its strength. Of course, Truby describes these strengths and weaknesses in the context of a character that embodies this archetype.

I selected Artist and Clown as the archetype of a good Scrum Master primarily because a good Scrum Master should encourage learning -- show the way but provide room for learning and, importantly mistakes. I wrestled with the notion of a Scrum Master as Clown but ultimately concluded that Clowns can have positive effect as well.

If you are a Scrum Master and you have lost your Scrum Team I wonder if looking at the archetype you embody provides insight on where you might be going wrong.

I am a firm believer that a separate Scrum Master role, as required by Scrum, is good for a team. The rationale for separation is documented in the Scrum Guide. I agree with it's intent, but like most of Scrum it's hard to get right.

In "Agile Methods: The Good, the Hype and the Ugly" an ACM Webinar by Bertrand Meyers discusses as ugly, the Coach and Method Keeper (e.g., Scrum Master) as a separate role (around 44:50). He says this leads people becoming a political commissars and creates a class of people who wash there hands of the result.

The separation described by Meyers' is a Scrum smell whose origin lies in the natural tension arising from the Scrum Master's role to ensure that the Scrum Team adheres to Scrum theory, practices and rules and the Development Team's need to be self-organizing. The problem arises when this natural tension turns into conflict.

This conflict manifests itself whenever the Development Team runs into situations where the theory, practices or rules conflict with what they perceive as the correct way to organize themselves. If the Scrum Master views this as a lack of buy-in instead of part of the learning process there will be trouble.

A common refrain is that if you aren't following the theory, practices and rules of Scrum than you aren't doing Scrum. You need to worry when you hear this sort of thing. It's problematic on at least two fronts.

• It implies the process has over taken the deliverables in terms of importance. Carefully consider whether perfecting the process is beneficial to the customer deliverable before you place a great deal of importance on such statements.
• It implies the natural tension arising between the Scrum Master's role and the Development Team's role has turned a corner and may be heading towards the sort of conflict that hurts everyone. Conflict can be good, especially in an environment that promotes constructive criticism and learning but it can be unhealthy in an environment where positions and opinions have become inflexible.

In Relearning Design Patterns, Egon Elbre observes that a critical piece of information is missing from Design Patterns: Elements of Reusable Object-Oriented Software is a pragmatic outlook on how and when to apply design patterns. Egon points to Christopher Alexander and his idea of pattern languages as a solution.

Pattern languages have the benefit of describing a system of patterns that support each other. It's a nice approach that has the potential to clarify when, and perhaps more importantly, when not to use a design pattern.

For example, the code I work with has a high occurrence the Singleton pattern. No other patterns are made explicit, except possibly Model-View-Controller. My challenge is that our design uses the Singleton to present one of something because there currently is only one of those things. The use of a Singleton introduces constraints that shouldn't be in the design.

If our code base modelled an airplane, it would have a singleton for the engine on a single engine plane, completely ignoring the fact that many planes have more than one engine. The Singleton places an arbitrary constraint on the design where none should exist and this introduces needless complexity into our domain.

In my view, the designers didn't view the domain in terms of appropriate and inappropriate constraints. Our implementation is the poorer for it. If they viewed the domain in terms of a pattern language they may have realized that using a Singleton for a jet engine assumes there will only ever be one engine. They may have recognized that a jet plane has the potential to support multiple engines. Recognizing this would have identified the Singleton as a poor design choice.

A classic case of when all you have is an idiom everything looks like and instance of it. Or perhaps that was a hammer.

In another example, I've recently had the opportunity to build a client-side library for a web application. At one point, I played with the notion that that a Singleton would be appropriate for managing the client session with the server. My initial rationale for this was that I knew the client would be run as a standalone application by a person using it on the command-line.

I ultimately rejected the Singleton because it placed an arbitrary constraint on the client-side library. I recognized that it's presence in the implementation would guarantee I limited the use cases supported by this library.

Curiously, I'm writing on branching policies again. In Working Agreements for Agile Teams, I discussed the problem with ambiguity. In Working Agreements for Agile Teams (Part 2), I discussed how the best working agreements are principles.

The issue of our prescriptive and ambiguous branching policy was raised and we agreed to rewrite it. This time I proposed

We agree to use topic branches for development.

This led to a discussion on why it's reasonable to disagree with this working agreement. For example, is it necessary to use a topic branch for a one line change? To improve a comment? My answer to these question is that it depends upon the code review.

We have another working agreement in which we agreed to peer review all code prior to merging it to the main line of development.

This led to a discussion on the interaction between working agreements. This discussion reenforced my thinking that good working agreements are principles and that reasonable people can construct arguments on when and when not to apply them.

I place a great deal of emphasis on product quality and what is merged into the main line.  Topic branches are irrelevant to product quality, although they can have an important role in ensuring it. In effect, my reasoning reflects my values regarding product quality and this reasoning motivates my choices.

If working agreements are principles and principles reflect values then what do your working agreements say about your team?