Read: War and Peace and IT

I got this book, War and Peace and IT by Mark Schwartz for $0 at Amazon.com. I think IT Revolution was holding some promotions which is how I got it for free back then so I was spared from shelling out $12.99. I bought it last May, but didn’t come around to actually opening it until this June.

We had a rocky start. The author pretending to be Napoleon Bonaparte in the Foreword section was something I found a bit too corny for my taste. So that made me put off reading it for a few more days or so. When I eventually reopened the book, I reached the section in the introduction sharing who the book is for.

Not me:

  • CEO
  • CFO
  • non-IT CXO
  • CIO or IT leader
  • Any category of business leader

And finally me: “For others in the business and IT community”

So mmmkay, I’m definitely not the main audience for this. I read it anyways. And it actually wasn’t so bad after I got over those hurdles. What I particularly like is that there’s a chapter summarizing suggested actions. So if you’re looking for one chapter to read in the whole book, go for Chapter 10: “Action Plan”.


I’ve listed out some bullet points from Chapter 10 below. For the full context though, you’ll still need to read the book. But at least this can give a starting point on whether you find the suggestions interesting enough to push through with checking out the $12.99 book.

Tie IT initiatives to business outcomes.

  • Choose a few objectives for trial.
  • Assign each to a cross-functional business/IT team that is fully empowered to execute.
  • Use impact mapping to brainstorm with the team.
  • Remove impediments.
  • Review progress often and make adjustments.
  • Celebrate success.

Shorten lead times.

  • Emphasize urgency and fast delivery.
  • Your goal is not to make people work faster or harder, but to improve workflow. Make that clear.
  • Take advantage of the cloud.
  • Ask IT to speed up the portion of delivery that is technical. This will probably involve implementing DevOps, creating reusable components, and designing secure “landing zones” in which new work can safely be done.
  • Find bureaucracy that isn’t adding value or that could be made leaner with Occam’s turkey carver. Often this includes sign-offs required from people who have no good basis for making the sign-off decision, forms that ask for unnecessary information, or controls that could be automated.
  • Becoming lean means reducing calendar time. Wait time, for example, should be eliminated, even though no effort is being spent.
  • Task switching is a source of waste and defects. Organize work so that everyone can focus. You can make this easier by keeping tasks small so they can be finished quickly.

Emphasize delivery and results.

  • Ensure that work is organized into very small units, work toward minimum viable products, and experiment to learn and test ideas.
  • Monitor results starting immediately.
  • Remove organizational impediments that resist quick shipping.
  • It may be easier to begin “working small” by modifying an existing system.
  • “Shipping” means that people start using the product. Prototypes and demos aren’t shipping (although they might be valuable steps on the way).
  • Don’t be afraid of disruption from shipping quickly. The idea is that by shipping quickly and frequently, each shipment is very small, and is consequently low-risk.

Treat requirements as hypotheses.

  • Read the Side Glance on humility! [this is another chapter in the book]
  • Question assumptions by asking how they can be tested.
  • It’s better to put effort into testing an idea than to risk not testing it.
  • A/B testing (where some users are shown version A, some version B, then the results are compared) is very effective and might be easy to set up.
  • Be sure that the test subjects are the same people who will be using the product—not, for example, managers or people within the product team.

A culture can’t turn ideas into innovations

I was skimming through some of my old notes when I came across this line:

Without reciprocity, in both deeds and resourcing, a culture can’t turn ideas into innovations.

And I thought of how there’s always a call to innovate at work. There’s always an invitation for new ideas. There’s always a call for change.

But it’s one thing to ask, and another to deliver. I’m a firm believer that you can’t just say something and that alone will will it to happen. There’s got to be some intentionality. If you want something done, you have to create space for it, you have to make time for it, you have to allow for it to happen. Because, physics, I guess. I don’t know how else to explain that going from A to B requires actually going from A to B. Hmmm… maybe logic.

Anyways, I’m putting in here some of my other notes relating to that quote and to creating the space for work or change to happen.


From “Innovation for the Fatigued (2019)”

The core tenet is if you want more innovation, give people what they need in order to innovate.

  • Make responses mandatory
  • Promote givers — In order to build a culture of reciprocity, leaders need to look for the givers of the organization, the people who are always ready to help with comments or support for ideas, and look to promote for generosity. The more givers you have in top management, the easier it will be to build respect and reflection.
  • Twin demands with support — You cannot develop innovation in an organization by simply demanding more and more of it. … make sure that demands are always reciprocated with support – be this allotted time, material resources and/or encouragement.
  • Punish indifference

Without reciprocity, in both deeds and resourcing, a culture can’t turn ideas into innovations.

From “It Doesn’t Have to Be Crazy at Work (2018)”

Reasonable expectations are out the window with whatever it takes. So you know you’re going to grossly underestimate the difficulty and complexity required to make it happen.

…Rather than demand whatever it takes, we ask, What will it take? That’s an invitation to a conversation. One where we can discuss strategy, make tradeoffs, make cuts, come up with a simpler approach all together, or even decide it’s not worth it after all.

From “Fast Times (2020)”

Having bold aspirations matters, but only when also matched by corresponding commitment. Without allocating funds and resources at sufficient scale over enough time, the value of digital will remain a mirage—promising but forever out of reach.

From “Brave New Work (2019)”

Creating space also means making time for change. Because most teams simply don’t have it.

One of the most self-destructive tendencies within teams is to get so busy that we believe there’s no time to get better at how we work

Continuous improvement is not magic; it is a discipline. It is a thing we do. And like all valuable things, it takes time. The average team doesn’t spend even thirty minutes a week reflecting on how they work together. They are going to need your help to stop this pattern and clear a path. Because we can’t learn if there’s no time to think. Teams need time for retrospection. They need time for personal reflection. They need time for deep work. They need time to run experiments and find a better way.

From “Full Metal Alchemist” (Anime)

Humankind cannot gain anything without first giving something in return. To obtain, something of equal value must be lost. That is Alchemy’s first law of Equivalent Exchange. In those days, we really believed that to be the world’s one and only truth.


There’s not going to be a shortage of material that supports the idea that it takes action to make change happen. Magic would be cool but most of us are muggles.

Unexpected section on testing

I was just at Chapter 7 of Think Like a Rocket Scientist, and that section was literally about testing. And of course, I couldn’t help but draw parallels or find links of what he said to software testing.

“The test must run forward to shed light on uncertainty, rather than run backward to confirm preconceptions.”
>>> Tests are for finding information, not just to confirm positive test cases, but also to see what happens with negative test cases.

“Experiments on Earth must mimic, to the greatest extent possible, the same conditions in flight.”
>>> This hinted at the importance of having our test environments closely resembling our prod environments.

“The best way to determine an object’s breaking point is to break it… This objective requires exposing every component, down to the screws, to the same type of shocks, vibrations, and extreme temperatures awaiting them in space.”
>>> It initially sounded like stress testing to me. And with the mention of components, down to the screws, made me think of unit tests and integration tests.

“It’s not enough to test the reliability of individual components. Without systems-level testing, you can unwittingly unleash Frankenstein’s monster.”
>>> What he said.

“When you make a last-minute change to a product and ship it out the door without retesting the whole thing, you’re risking disaster.”
>>> This just shouted impact analysis and regression testing to me.

“Instead of creating artificial testing environments disconnected from reality, we’re better off observing customer behavior in real life.”
>>> This, and one of the other anecdotes, reminded me of User Testing and A/B Testing.

“Treat your testing instruments like your investments and diversify them. If you’re building a website, test it using different browsers and different computers.”
>>> Again, what he said, nothing to add there.

Lines that resonate to me as a tester

I’ve started reading this recently published book by Ozan Varol called Think Like a Rocket Scientist. I’m only at the first chapter which is about uncertainty, and I came across these few lines which I found interesting. As a tester or reviewer, you come across bugs. While it can mean a little more work for the team, sometimes you can’t help admit that some of the bugs–or whatever little things that trigger them–are cool or fascinating. Maybe it’s just me. But say hi in the comments if you appreciate cool bugs once in a while.

Anyways, here are those quotes. Those three blocks below are from the book:


“Discovery comes not when something goes right,” physicist and philosopher Thomas Kuhn explains, “but when something is awry, a novelty that runs counter to what was expected.”


Asimov famously disputed that “Eureka!” is the most exciting phrase in science. Rather, he observed, scientific development often begins by someone noticing an anomaly and saying, “That’s funny…”


Einstein’s younger son, Eduard, once asked him why he was famous. In his reply, Einstein cited his ability to spot anomalies that others miss: “When a blind beetle crawls over the surface of a curved branch, it doesn’t notice that the track it has covered is indeed curved,” he explained, implicitly referring to his theory of relativity. “I was lucky enough to notice what the beetle didn’t notice.”

Read: Agile Conversations

I’ve previously told myself that I’d ease up on somewhat work-related reading, and shift to something lighter instead. Well, that was a quick break. I came across this newly released book and I ended up checking it out, and finishing both books today. The book is Agile Conversations: Transform Your Conversations, Transform Your Culture by Douglas Squirrel and Jeffrey Fredrick. I feel like I expected too much from the book; maybe it was just too soon for me to read stuff like this again since what I picked up from it are like echoes of recent readings.

It’s not altogether for naught. On the upside, I did pick up the origin story (one sentence, people might expect an elaborate story) of that familiar “Trust but verify” statement.

Anyways, sharing below my summarized bullet points which aren’t really as informative as the actual book or my actual notes, but hopefully, they’d give me a hint on where to find what in case I want to read back on it.

  • Change your conversations, change your culture. It’s like their “Save the cheerleader, save the world” statement.
  • In adopting something codified, there’s the tendency to take in the superficial process changes (e.g., having daily scrum, WIP limits, tool selection, etc). But more than just the processes, it’s the shift in mindset and view towards people as drivers of the success (over processes) that are needed. That Taylorist factory mindset needs to be dropped.
  • There are two theories of action. And we’re unfortunately we’re naturally more inclined towards the counterproductive, defensive behaviors of Model I. But the good news they say is, through regular effort and practice, Model II (behaviors of transparency and curiosity) can be learned.
  • Conversational Analysis can be used to heighten your awareness for where you lack genuine questions (you ask, but not really), when you have unexpressed thoughts/feelings, or when you encounter certain triggers or exhibit tells and twitches.
  • Trust Conversation – Be vulnerable. Be predictable. Use the Ladder of inference in discussions where there’s misalignment (i.e., step back, find safe common ground, before you move deeper into the discussion).
  • Fear Conversation – Watch out for Normalization of Deviance (that process wherein we become somewhat immune to the red flags and fail to raise them). Use coherence busting to step back and refrain from jumping to conclusions or assuming the worst.
  • Why Conversation – Why you don’t start with why is because you need to address Trust and Fear issues first. Distinguish between interests and positions; step back to understand the reasoning and the interests that lead to the possibly conflicting positions. Advocate your position, but be inquisitive on what the other side has to say. Work with a joint design for increased stake of people in the Why.
  • Commitment Conversation – This brings up the “It’s done, but…” example. Agree on meaning. Walking skeleton i.e., strip down to the bare essentials and progressively add in (as the bandwidth would also allow).
  • Accountability Conversation – Adopt Theory Y (or People Positive as mentioned in Brave New Work) mindset. Use Directed Opportunism for communicating plans and intentions up and down the chain of command. Radiate intent and information (e.g., current state, plans and intended outcomes, alert to obstacles) using Agile Radiators (e.g., ceremonies like Planning, retrospectives, demonstrations; and tools like information radiators).

I also had a bunch of knee-jerk reactions to some stuff.

What I’ve been reading, and what to read next

Yesterday, I was shopping in Amazon for the next book to read. I was having a bit of a hard time since I couldn’t really pinpoint what I was looking for. Maybe it’s a mix of quarantine blues, and this feeling that the books I’ve been reading have quite recurrent themes just differently stated.

This 2020, so far, I’ve gone through a few titles. There were topics I read in line with product management:

There were books about leadership, evolutionary organizations, and maybe somewhat about driving change:

  • Brave New Work (2019) by Aaron Dignan – At USD5.99, this feels quite sulit!
  • Reinventing Organizations (Illustrated, 2016) by Frederic Laloux, illustrated by Etienne Appert – This one is available in an option the author calls “pay-what-feels-right.”
  • Going Horizontal (2018) by Samantha Slade – Among the three, I think this is the only one aimed with individuals more than the leaders in mind.

Still on leadership:

  • Essentialism (2014) by Greg McKeown
  • The Culture Code (2018) by Daniel Coyle
  • Fast Times (2020), a perspective from leaders at McKinsey & Company – This one was available at Kindle Unlimited which I had a discounted subscription of $0.99/month but only for a limited period back then.
  • Art of Action (2011) by Stephen Bungay – Not available in Kindle

Then on leadership with focus on communication:

Then there’s this one that’s a bit out of place, but quite relevant in these quarantine times:

  • Remote (2013) by Jason Fried and David Heinemeier Hansson – (but I like their newer book more)

The leadership books and organizational change books especially are really more intended towards leaders (as it should be, I suppose) than individual contributors like me. But that’s not to say I don’t get anything out of them. The insights are very interesting, the anecdotes mostly enjoyable, and the examples give you an idea on how to possibly be better. It just takes a little extra layer of processing of how can this apply to me, or how can I apply this in my own capacity, or how do I get THEM to apply this. So back to my shopping… I guess one other reason why I was stuck was because I felt like reading similar books will only be like the author preaching to the choir, and I’m not really the one who needs convincing.

So I’ve decided on a much lighter reading on a topic that I also enjoy (because of course). Next read is: Dreyer’s English: An Utterly Correct Guide to Clarity and Style.

Read: Leadership is Language

I stumbled upon this book, Leadership is Language: The Hidden Power of What You Say–and What You Don’t in Amazon while I was looking for a book by the same author, L. David Marquet. I was initially curious about Turn the Ship Around!, but then I saw this more recently published title (just this Feb 2020) and it had a 5.0 out of a 5.0 star rating out of only 26 reviews (but still!). The title also got to me because I like language. When I read and the author chips in some tidbit on certain word usage or history, I’m more than likely to be appreciative of that info.

After having read it, what I like the most is how it brings to light some of my usual tendencies and offers better alternatives. Say, for instance, I like showing appreciation towards my colleagues, and I might say something like “Cool! Good job!” A better approach would have been to say something more specific and descriptive, Another example is how we’re inclined to give instructions over providing info e.g., “Be back by 10AM” vs “We’ll start at 10AM.” The difference feels so subtle but it’s there.

Now, I doubt my language patterns would change overnight. But awareness is a start.

Sharing here the rest of my notes…

We’re continuously OSCILLATING between thinking and doing

  • Like in PDCA (plan-do-check-act), we shift between action and reflection, doing and deciding.
  • Before action – what are we going to do? what are we going to learn?
  • After action – what have we learned?

DIFFERENTIATING between embracing variability and reducing variability

  • Thinking benefits from embracing variability
  • Doing benefits from reducing variability
  • Big mistake example: “Often, leaders driving toward consensus are reducing variability when they should be embracing variability and driving away from consensus. Then they wonder why they’re not hearing new ideas from their team. The problem is they’re calling the wrong play. They’ve brought a reduce-variability playbook to an embrace-variability game.”

6 NEW PLAYS

  • Starting in redwork… Transition from redwork to bluework with:
    • CONTROL THE CLOCK, not obey the clock
    • COMPLETE, not continue
  • While in bluework
    • COLLABORATE, not coerce, with the goal to:
    • IMPROVE, not prove
  • Transition from bluework back to redwork with:
    • COMMIT, not comply
  • And use the enabling play:
    • CONNECT, not conform

CONTROL THE CLOCK, not obey the clock. This highlights importance of introducing and allowing for PAUSES to address something wrong or to get into some collaborative work; and that this is responsibility of leadership (to create space for it, or to initiate this himself as folks might not feel empowered to do so).

COLLABORATE, not coerce. This highlights a funny point: ‘Often “collaborating” is really coercion in disguise.’ So we need to be mindful that we really are collaborating, rather than just subtly getting people to agree or validate our own ideas.

  • Vote first, then discuss – If the boss goes first, others might not be inclined to share own ideas.
  • Interesting language shift: Avoid binary yes/no question. Shift towards asking how, tell me more.
  • 7 sins of questioning and their corresponding alternative
    • instead of question stacking, try one and done.
    • instead of an attempt at a teaching moment with a leading question, try a learning moment (asking how would that work, tell me about that)
    • instead of a “why” question, try “tell me more.”
    • instead of dirty question (subtly holds biases and anticipates a particular answer), try a clean question (asking what do you mean by… or what do you want to have happen?)
    • instead of a binary question, start the question with “what” or “how”
    • instead of self-affirming questions, try self-educating questions (like what am I missing, what could we do better?)
    • instead of aggressive questioning jumping to the future, reset, start from a place where they feel secure (known, present, past), and move gradually toward areas of uncertainty and vulnerability (unknown, future)
  • Interesting language shift: Give information, not instructions. Instead of saying “Be back at 10AM,” say “We’ll start at 10AM.”

COMMIT, not comply. This highlights that commitment is more than a decision, it entails action that is attached to the decision.

  • Interesting language shift: From using “don’t” rather than “can’t” to express commitments e.g., “I don’t miss deadlines,” rather than “I can’t miss deadlines.”
  • Apart from committing to ACT on a decision, also commit to LEARN.
  • Escalation of commitment “means that once we select a course of action, we stubbornly stick to it, even in the face of evidence that the course of action is failing.” It’s like sunk cost fallacy, and is something to watch out for.

COMPLETE, not continue. This highlights the need to make completion a part of the process of doing work. Upon completion, apart from the mental reset (and possible celebration), you put in some reflection to see what you’ve learned and to see whether it makes sense to still follow through the actions for a decision, or if the decision itself still makes sense.

  • Provides the critical pause for self-reflection and improvement, and celebration
  • “To celebrate with, not for: appreciate, don’t evaluate; observe, don’t judge; and prize, don’t praise.”
  • Interesting language shift: From something that gives judgment (e.g., Good job!) to something specific and descriptive (e.g., Thanks! I noticed that you structured the document really well, making the points really come through.”)
  • Interesting language shift: From recognizing characteristics to the specific behavior. Instead of saying “You guys are a great team,” say “It looks like it took difficult cross-department coordination to deliver this product.”

IMPROVE, not prove. This highlights the need to drop the ego and be open to think about what or how we could be better, or how we can make the work go better.

  • Resist the temptation to be good idea fairies. Use the team backlog and process the ideas in the next scheduled bluework pause. But this requires the right support framework to be in place. No backlog, no process, no scheduled time to process mean the good idea fairies will continue to be at it.
  • People’s own egos are the blockers of the improve play. Solution is not to blame; but to acknowledge that people can get defensive, and so the right mindset and language needs to be used when initiating this play.
  • Focus forward – don’t dwell on the mistakes, emphasize the potential
  • Focus on others or on the process – don’t play the blame game. Shift focus on how to help the team, how to help customers, how to improve workflow.
  • Focus on achieving excellence, not avoiding errors.

CONNECT, not conform. This part is about caring and trust — that you can’t connect without these two.

  • A flatter power gradient allows for more open communication that feels safe to say truth, tell it like it is, admit mistakes, and deliver bad news. But to achieve this rests on the hands of those who are in power.
  • Interesting language shift: From judging to observing e.g., instead of saying “You wrote that ugly report poorly,” say “I noticed a couple of typos, and paragraph 3 missed a few points that we covered in the review.”
  • Be open, trust first, assume positive intent
  • Don’t shut people down from participation or voicing out ideas by thinking you are/know better.

Reads on Evolutionary Organizations

I read Aaron Dignan’s Brave New Work: Are You Ready to Reinvent Your Organization? last January, and in the past week I read the illustrated version of Frederic Laloux’s Reinventing Organizations. As I read the latter, a lot of the stuff mentioned — terms, concepts, examples — felt so similar and consistent with BNW which made me think if Dignan just made a spin-off of Laloux’s work. Maybe he did, maybe he didn’t. Either way, I found both books interesting and they were both easy reads.

As for differences, I think RO elaborated more on the evolution of organizations throughout our history. It also promotes the metaphor of organizations as living systems. There were some enumerations on management structures and practices that need upgrading, but not all items were discussed in the book (but maybe they’re covered more in the non-illustrated version). The book does have companion resources including a crowd-sourced wiki that has elaborations on the stuff not elaborated in the book.

BNW focuses more on the organization’s Operating System — elaborating on the different domains or parts that make us the OS canvas. Examples of the domains (there are 12) include purpose, strategy, meetings, membership, etc. Each domain gets covered with examples and you get ideas or suggestions of what you can consider applying to your own organizations. I think BNW also offers more guidance or aides e.g., sensing tensions (78 tensions that can be used as conversation fodder), proposing practices (deck of practice cards), conducting experiments (experiment worksheet).

I made a lot of highlights in both books, and I saw several instances of me saying “interesting…” in my notes. I guess one of my favorite ones (might be trivial) is on the use of the word “fractal” in BNW.

“Like organizational purpose, strategy is multidimensional and fractal—it’s happening on many fronts at many levels. Which means coherence matters.

Say fractal and images of geometric figures with repeating patterns come into mind. A definition of fractal is “a curve or geometric figure, each part of which has the same statistical character as the whole.” To describe something consistently happening at all levels at all fronts as fractal is such a cool word choice.

Do we size bugs with story points?

I found a question posted in one of the social channels at work: How should one give out story points to bugs/defects that one does not yet know how to fix yet and requires investigation? The original question asks how but I think even before we go there it would be nice to know whether we need to in the first place. I plan to write about this in 2-parts: (1) how I might go about with it — no explanations, but based on past experiences as a member of Agile Scrum teams and what I’ve read on the topic, and (2) links and quotes galore.

How I might go about with it

  • If it’s a bug found during testing of a user story we’re working on in the sprint AND it’s small enough (implicitly sized) to be fixed within the same sprint: It goes into the sprint backlog. No need to size it. Just prioritize it accordingly.
  • If it’s a bug unrelated to user stories that we’re testing this sprint (say, from an older feature) OR it’s too big a bug or complex (again implicitly sized) to be fixed within the sprint: It goes to the product backlog. It’ll be groomed as you would with other user stories to give it enough details for the team to work with. And if it makes it way into the Sprint Planning, then size the bug.
  • Now what if the bug that goes into the product backlog requires more investigation than usual (all bugs require investigation, but in some cases I suppose devs already have an idea of how to fix it, in some, totally no idea hence more investigation is needed): Tag it as a spike (not a term in the Scrum Guide, FYI). If it goes into the Sprint Backlog, meaning the team agrees to invest time on investigating that bug within the Sprint, no need to size it.
    • For that spike in the Sprint, it’ll just mean there’ll be a time-box (1-3 days of effort) for investigating that bug. At the end of the time-box, whoever works on it reports their findings and the team can discuss the next steps.
    • Assuming the team agrees on a resolution, duplicate the bug with the spike tag. Close the original one. In the duplicate, remove the Spike label. If it’s to remain in the Sprint Backlog meaning the team will fix it within the Sprint, then size the bug. Otherwise, the new bug (the duplicate) goes to the Product Backlog and no need to size it yet.
    • But what if there’s still no resolution or identified workaround. The team can opt to extend the time-box. But at some point, you can’t just extend and extend it forever. Once a threshold is met (is 3 months too long/short?): Tag it with a label your team agrees to use on such items, and then archive it.
  • At the end of the Sprint, the Scrum Master will be able to gather the following data in case they want to use it for some forecasting:
    • User Stories – total story points, bugs per user story
    • Bugs – total story points, total number of bugs
    • Spikes – total number of Spikes worked on, total number of Spikes closed, total points from Spikes that were converted to new bugs

That turned out longer than I expected. The next part are for some links on the topic and could give you the opposing views to help you come up with your own answer.

Links and quotes galore

12 common mistakes made when using Story Points – This has a lot of other interesting points not just about on whether you size bugs or not.

  • “Story Points represent the effort required to put a PBI (Product Backlog Item) live.” So story points are not limited to user stories.
  • “Story Points are about effort. Complexity, uncertainty and risk factors that influence effort but each alone is not enough to determine effort.
  • [Common mistake #5: Never Story Pointing Bugs] “A bug which is unrelated to the current sprint should just be story pointed. The bug represents work the team needs to complete. This does not apply if the team reserves a fixed percentage of time for working on bugs during the sprint. A bug related to an issue in the sprint should not be story pointed as this is part of the original estimation.”

Should Story Points Be Assigned to a Bug Fixing Story?

  • [I think this is with respect to legacy bugs or when the team is dealing with a large database of agile defects] “My usual recommendation is to assign points to bug fixing the agile defects. This really achieves the best of both worlds. We are able to see how much work the team is really able to accomplish, but also able to look at the historical data and see how much went into the bug-fixing story each sprint.”

Should you ‘Story Point’ everything? – This is a thread in the Scrum.org forum.

  • (No points for bugs) ‘They are called story points for a reason. They are not call[ed] “Item Points”. Ideally you should only have stories in your backlog and the technical tasks should be inside…’
  • (Yes or no points for bugs) “It is critical as a Scrum Master to ensure that story points are being used properly within an organization. They serve two purposes only: to help the Development Team and Product Owner plan future sprints, and to be accumulated for done items at the end of a sprint for velocity calculation purposes. They are not a proxy for value delivery. … That said, it seems there are a number of different items (bugs, technical tasks, spikes) that have a capacity impact on the Development Team each sprint. For planning purposes, if the team prefers to not point these items, a mechanism to determine the capacity impact is still desired….”
  • (No points altogether) ‘I have found, and this may depend on your team, that removing story points entirely helps the team and stakeholders focus on the sprint goal instead of “How many points”….’

What’s a spike, who should enter it, and how to word it? Since I mentioned “spikes”, I’ve put in this other link about it.

  • “A spike is an investment to make the story estimable or schedule-able.”
  • “Teams should agree that every spike is, say, never more than 1 day of research. (For some teams this might be, say, 3 days, if that’s the common situation.) At the end of the time-box, you have to report out your findings. That might result in another spike, but time-box the experiments. If you weren’t able to answer the question before time runs out, you must still report the results to the team and decide what to do next. What to do next might be to define another spike.”
  • “It’s also best if a spike has one very clear question to answer. Not a bunch of questions or an ambiguous statement of stuff you need to look into. Therefore, split your spikes just as you would large user stories.”

Let me know if you find anything more conclusive or helpful.

Read: The Culture Code

Just finished reading The Culture Code: The Secrets of Highly Successful Groups by Dan Boyle. I read it even though I pretty much think the key to highly successful groups is having great individuals rallied together by a clear purpose and a selfless leader. That’s no secret — it’s just that getting that right mix is what’s elusive. Anyways, the book was a quick and easy read peppered with Ideas for Action (that’s literally the title of 3 chapters) on how you (but ideally your leader) can help in 3 things: (1) building safety, (2) sharing vulnerability, and (3) establishing purpose.

Actionable ideas

Be mindful of 3 basic qualities of belonging cues — Energy, Individualization, Future Orientation. So in your interactions with your team mates, invest energy by giving attention and being present in the interaction. Acknowledge the individual, don’t make him or her feel like he’s just another random person. Hint at a future, don’t make it feel like it’s just a hello and goodbye interaction.

Build Safety — We are safe and connected.

  1. Overcommunicate your listening – Start off with actually trying to listen, and hopefully your posture, expression, and whether you give a steady stream of affirmations (yes, uh-huh, gotcha) or encouragement to the speaker to keep going would shine through. If not, watch out for whether your posture, expression, reactions are conducive towards the speaker continuing to speak up.
  2. Spotlight your fallibility early on–especially if you’re a leader – Radiate humility and actively invite input with simple phrases like “This is just my two cents,” “I could be wrong here,” “What am I missing?”, “What do you think?”
  3. Embrace the messenger – When someone shares a truth especially bad news or tough feedback, don’t chew off their head. You have to make it feel safe for people to speak the truth.
  4. Preview future connection – Hmm… similar to above on future orientation. Maybe share some vision of the future that you have for the person (like if you see him or her as possibly the next great thing) or with the person.
  5. Overdo Thank-yous
  6. Be painstaking in the hiring process
  7. Eliminate bad apples – Bad apples like jerks, slackers, and downers just aren’t good for the psychological safety of the team.
  8. Create safe, collision-rich spaces – By “collision” he means serendipitous personal encounters. I guess this is about trying to increase the chances of interactions among the team. Could be as elaborate as setting up an extremely nice team area to something as simple as the team having coffee.
  9. Make sure everyone has a voice – Not just the loudest person gets heard. Everyone gets heard, and I guess what follows through is more important i.e., when it actually converts to change or action.
  10. Pick up trash – “Muscular humility”–a mindset of seeking simple ways to serve the group. Other examples could be allocating parking places, picking up checks at meals. “These actions are powerful not just because they are moral or generous but also because they send a larger signal: We are all in this together.”
  11. Capitalize on threshold moments – It’s not just in day one. In successful groups the author visited, they also paid attention to moments of arrival. “They would pause, take time, and acknowledge the presence of the new person, marking the moment as special: We are together now.” Think about it: A warm greeting to a team mate when he arrives versus not even batting an eyelash.
  12. Avoid giving sandwich feedback – Separate handling of negative and positive feedback — negative through dialogue, positive through “ultraclear bursts of recognition and praise.”
  13. Embrace fun

Share Vulnerability — We share risk here.

  1. Make sure the leader is vulnerable first and often – Recommended 3 questions for leaders to ask their people:
    • What is one thing that I currently do that you’d like me to continue to do?
    • What is one thing that I don’t currently do frequently enough that you think I should do more often?
    • What can I do to make you more effective?
  2. Overcommunicate expectations – People aren’t psychic and things don’t just magically fall in to place. “[Be] explicit and persistent about sending big, clear signals…”
  3. Deliver the negative stuff in person
  4. When forming new groups, focus on two critical moments – “At those moments, people either dig in and become defensive and start justifying, and a lot of tension gets created. Or they say something like, ‘Hey, that’s interesting. Why don’t you agree? I might be wrong, but I’m curious and want to talk about it some more.’ What happens in that moment helps set the pattern for everything that follows.”
    • The first vulnerability
    • The first disagreement
  5. Listen like a trampoline – Not just about nodding attentively, you add insight. “The most effective listeners do four things:…”
    • They interact in ways that make the other person feel safe and supported
    • They take a helping, cooperative stance
    • They occasionally ask questions that gently and constructively challenge old assumptions
    • They make occasional suggestions to open up alternative paths
  6. In conversation, resist the temptation to reflexively add value – Don’t try to end the conversation with your own solution. Let the discussion flow (except maybe if time-boxed or if the folks are going in circles).
  7. Use candor-generating practices like AARs, BrainTrusts, and Read Teaming – AARs are After-Action Review done by Navy Seals — It’s like our Retrospectives. BrainTrusts are by Pixar. Red Teaming is a way for exposing risks by creating a team to purposely think of ways to make you fail. One good AAR structure is to use five questions:
    • What were our intended results?
    • What were our actual results?
    • What caused our results?
    • What will we do the same next time?
    • What will we do differently?
  8. Aim for candor; Avoid brutal honesty
  9. Embrace the discomfort – “One of the most difficult things about creating habits of vulnerability is that it requires a group to endure two discomforts: emotional pain and a sense of inefficiency. But as with any workout, the key is to understand that the pain is not a problem but the path to building a stronger group.
  10. Align language with action
  11. Build a wall between Performance Review and Professional Development
    • Performance evaluation tends to be a high-risk, inevitably judgmental interaction, often with salary-related consequences.
    • Development is about identifying strengths and providing support and opportunities for growth.
  12. Use Flash Mentoring – Hours, instead of months or years
  13. Make the leader occasionally disappear – Not to be confused with toxic absenteeism. Given the right foundations and having set them up to know what to do, the team should still be able to perform.

Establish Purpose — This is what matters.

  1. Name and rank your priorities
  2. Be ten times as clear about your priorities as you think you should be – “Leaders are inherently biased to presume that everyone in the group sees things as they do, when in fact they don’t.” It doesn’t help when all the leader sees are nodding heads. Overcommunicate priorities.
  3. Figure out where your group aims for proficiency and where it aims for creativity – “Building purpose [for proficiency, machine-like reliability, usually for service] is like building a vivid map: You want to spotlight the goal and provide crystal-clear directions to the checkpoints along the way…. Generating purpose [for creativity, for empowering groups to build something that has never existed before] is like supplying an expedition: You need to provide support, fuel, and tools to serve as a protective presence that empowers the team doing the work…. Most groups, of course, consist of a combination… The key is to clearly identify these areas and tailor leadership accordingly.
  4. Embrace the use of catchphrases – No way, Jose. Corny. “They aren’t gentle suggestions so much as clear reminders, crisp nudges in the direction the group wants to go.
  5. Measure what really matters
  6. Use artifacts – “Their environments are richly embedded with artifacts that embody their purpose and identity … they all reinforce the same signal: This is what matters.
  7. Focus on bar-setting behaviors – Example given what about a hockey team that rallied their culture around a specific behavior they called “Forty for Forty” — it’s something that they do as part of their play and I guess it captures who they are in some way. I guess the closest analogy I can think of is for testers, we often said “Trust and verify.” Because that was really what was happening and what needed to continue happening. You have to take care of the relationship between you and the devs where you show them you trust them and you can be trusted; and that it’s not about distrust towards them when you do your checks or tests on their work; it’s because you have to do what you have to do i.e., to test.

That’s it. Summarized the 3 chapters (and I guess pretty much the whole book). Of course, the book can provide better context. Go buy it if you want, or buy me a hardcopy which I’ll gladly leave lying around in the office for sharing. Thanks for reading this far (or skimming this far, it’s ok), now maybe you can go over the list of actionable ideas again and this time look for what you can apply or explore further.