Categories
Read Other People’s Stuff

Read Other People’s Stuff: 2

This is the most compelling software-related post I have read in a while:

Web 3.0 harkens back to the days when engineers thought Object Linking and Embedding and Open Doc were the future. The reason those things failed is because it’s more difficult for average people to think (or care) about information that is distributed than information that is centralized. Think about this: What percentage of Word documents sitting on computers around the world today have a live reference to a chunk of cells in someone else’s Excel spreadsheet?

Something that I tend to think of as a rule for ascertaining the long-term success of a technology is: does the technology make sense for people, or does it make sense for engineers?

If you are interested, here are some things I have already written that complement this topic:

Discuss this specific post on Twitter or LinkedIn.

🎹 Music for this post: https://www.youtube.com/watch?v=CLlfK_GQwko.

[Logo]
Categories
Agility Scrum

If a Tree Falls: The Sprint Review Is the Most Essential Ceremony of Scrum

Prologue

I don’t think I’m alone in feeling that the pandemic has made professionally-oriented content feel overtly trite. Families and personal lives are eminently more important than they have been in our lifetimes. Out of respect for my readers, I’ve deliberately reduced my blogging for several months, writing occasionally rather than prolifically. My sense here in February 2022, though, is that people are slowly resuming their interest in new things about our work lives, as long as these things are simple and refreshing. This is the first in a series of columns written in that mold.


Many years ago, when I was in the habit of interviewing software engineers on a regular basis, I would often ask:

Apart from the Sprint itself, what do you feel is the most essential ‘ceremony’ in the Scrum framework?

I never kept count of the answers I got over the years, but there is no doubt that the most frequent answer — by a long shot — was the Daily Scrum. In many cases, this was the only ceremony the candidate was familiar with, which was a handy sign that he or she really didn’t have a full understanding of Scrum.

I recently shared a poll on LinkedIn posing this question, and received the following results:

  • Sprint Planning: 18%
  • Daily Scrum: 32%
  • Sprint Review/Demo: 32%
  • Sprint Retrospective: 18%

Is there a correct answer? Strictly speaking, of course not. But as a leader whose organizational responsibilities have included “agile transformation” for as many years as I can remember, I’ve developed an opinion that there is, in fact, one ceremony that is particularly essential in delivering on Scrum’s “inspect and adapt” principles. That ceremony is the Sprint Review.

The Sprint Review is where all of Scrum’s magic happens. Scrum without a Review is a tree falling in the forest with nobody to listen. The Review is the home of “inspection” and the springboard for “adaptation.”

The poll tells me that the majority of my readers’ brains are perturbed right now. Please allow me to elaborate.

First off: The Sprint Retrospective. Sprint Retrospectives are immensely powerful tools, and a place where inspection and adaptation — of process rather than product — takes place. Many Scrum practitioners are dogmatic about Retrospectives — but I like to say that the only place where dogma is acceptable is in religion. Woe be unto you if you treat Scrum as religion. As Scrum teams mature, with healthy self-empowerment and active daily conversations, Sprint Retrospectives are likely to decrease in relevance. It’s perfectly OK — arguably, healthy — to skip a Sprint Retrospective or two in a Scrum team that has been performing consistently well for weeks or months on end. A high-performing team will always ask itself, and answer honestly: do we need a Retrospective? If not, it’s OK to move on.

Secondly: The Daily Scrum. Here’s something controversial for you: Arguably, the Daily Scrum is the least important ceremony of Scrum. Why? Because high-performing and tightly-communicating Scrum team members are more likely to understand each other’s progress, work to come, and barriers as artifacts of their interactions throughout the day. Daily Scrums are absolutely essential for new teams and teams that are not good at identifying and articulating barriers (which is, admittedly, a whole lot of teams.) The most mature Scrum teams I have worked with have incredibly short Scrums, and even occasionally skip them to no ill effect.

Thirdly: Sprint Planning. I know what you are thinking: How can you have a Sprint, let alone a Review, without Sprint Planning? Isn’t Sprint Planning equally as important as the Review, if not more important? (More important? Let’s not get carried away! A planned and executed Sprint with no Review is a waste of time.) Here’s the rub: It is entirely possible to start an agile initiative with a Review of work that was not borne of a Sprint Planning session: A Review that consists of a display of skunk-worked/hobby-level/unplanned work that a team believes has merit. I call this sort of Review a “Big Bang Demo”; an “origin of the universe” kind of event. Once it happens, one of two things follow: a fizzle, or a proper Release/Sprint Planning session.

Of course, most Scrum initiatives start with some form of Release Planning, following up with Sprint Planning, so I can appreciate those of you who argue for Sprint Planning as the most essential answer in my little poll. But: apart from the very first Sprint Planning session, all subsequent Sprint Planning is informed by the outcome of a Sprint Review! Without those Reviews, there is nothing to adapt for subsequent Sprint Planning. If your Sprint Planning sessions don’t incorporate adaptation from your Sprint Reviews, I would argue that you have enough certainty in your project to merit a waterfall approach, and that you’ve chosen the wrong tool for the job!

This is why, to me, there is no doubt that Sprint Planning is a close second to the Sprint Review in terms of its essence. Scrum is a project management tool for uncertain initiatives.

The Sprint Review is where we learn. It is the fulcrum for all decision-making. If there is no Review, there is no learning, there is nothing for the Product Owner to approve, there is nothing to adapt from, and there is nothing that has been thoughtfully approved for release to the customer.


But all of this is more than a mere thought exercise. If your organization is on an agile transformation journey, you will do well to prioritize the quality of your Sprint Review culture over everything else in your Scrum process.

  • Make sure that your Product Owner attends and participates in every Review.
  • Do whatever you can to ensure that the Review grabs attention. Don’t ramble; stay focused.
  • Condition your Product Owners to be honest — yet respectful —about their feelings. Accepting work that the Product Owner is too uncomfortable to reject is a recipe for disaster — and arguably one of Scrum’s most frequent failure points.
  • Condition your implementation teams to avoid defensiveness. They should be ready to set aside all or part of a Sprint’s work if that is what the Product Owner decides.
  • Script and rehearse the Review so that there are no surprises. Don’t review work that hasn’t been reviewed and tested.
  • The team should strive to ensure that the Review is a learning experience, each and every time. If there is no learning, there is no point in employing Scrum.
  • Try to have as much fun as you can! Make the event something everyone looks forward to. Bring donuts. Or ice cream. At the very least, bring a few good jokes and a roomful of smiles.

The Review should feel like the point of Scrum. It should feel like Christmas morning, or the first day of Hanukkah, or any other day that you used to look forward to each year as a child. Done well, it is the “push” for the snowball that is your project, and each and every Review will see your snowball moving with greater momentum. If you get your Reviews right, your team will bring a positive and focused spirit to all of the other ceremonies of Scrum, from Sprint Planning through Daily Scrums and, yes, even to Sprint Retrospectives.

Discuss this specific post on Twitter or LinkedIn.

🎹 Music for this post: https://www.youtube.com/watch?v=JSCVOQv4j6E.

[Logo]
Categories
Commitment Compassion Empathy Humility Invisibleism Patience Vulnerability Willingness

Look Up

When you get to know someone, do you focus more on what’s wrong with them, or what’s right with them?

Is there a benefit to focusing on one or the other?

How do you feel about your own flaws? Do you admit them, or do you try to hide them or compensate for them?

Why do you think that’s the case?

When I was a young executive, my boss once shared the following pearl of wisdom with me…it’s explicit, but this is the way I learned it:

If you look up someone’s ass, you’re always going to find shit.

—H. Eliot Subin

Every one of us has something that, once discovered, will be off-putting to others. If we look hard for these things, we are certain to eventually find them.

When we find someone else’s poop — knowing that we each have our own — why does that so often surprise us, and make us think differently about them? Perhaps because most people like to like people. When we get to know a person and we like that person, it brings us joy; it makes us feel like the world is a better place. We like the honeymoon period, before we find the poop. We like the Hallmark Channel.

When we discover flaws in people, it’s all too easy to feel let down. But it’s a terrible mistake to dismiss someone else when we discover their poop. How would you feel if the shoe were on the other foot?


If you’ve been in business long enough, you’ve undoubtedly been asked about the leaders who have inspired you on your journey. For me, the most immediate answer has long been George Martin. He’s an admittedly unusual choice. I’m a lifelong Beatles fan, and while I love the Beatles’ music, I find their group dynamic even more intriguing.

The Beatles were four young men who loved music, and who had a deep appreciation for one another. But despite a few friendly and intense years in the early half of their career, they were decidedly not in love with one another. In fact, their creative peak paralleled their social nadir. They had different values in life and in their music. They worked hard to keep themselves together in the way the world expected, and George Martin’s greatest contributions were in providing musical balance to complement their competing ideas. Watching his deft, delicate, minimalist hand at work in Peter Jackson’s recent Get Back documentary series is a powerful illustration of this. As their closest colleague in the studio, he routinely mediated compromise, helping four very different people become something much greater than they were individually.

At this point, it feels appropriate to revisit the quote from Victor Hugo on The Progressive CIO’s home page, which presaged this very post two years ago:

“But who among us is perfect? Even the greatest strategists have their eclipses, and the greatest blunders, like the thickest ropes, are often compounded of a multitude of strands. Take the rope apart, separate it into the small threads that compose it, and you can break them one by one. You think, ‘That is all there was!’ But twist them all together and you have something tremendous.”

—Victor Hugo, Les Misérables

If you lead teams of talented and smart people, they will have differences with one another — sometimes significant ones. They will find things to dislike in each other’s philosophies, politics, lifestyles, or approaches. It is your ability to embrace, cultivate, coach through, and complement these differences that paves the road from disaster to brilliance. What does it take for you to develop a deft and delicate hand to manage this?

First: Never forget your own flaws. This requires humility.

Second: Get comfortable talking about those flaws, which will be reassuring to those who you serve and who you lead. This requires vulnerability.

Third: Develop an ability to not be surprised or disappointed when you find flaws in others. In conjunction, develop the ability to lock, arm-in-arm, in your shared humanity, This requires compassion.

Fourth: Understand that what you perceive as a flaw might not be perceived that way by others. Try to look at this perceived flaw from different perspectives, and consider invisibleism along the way. This requires empathy.

Fifth: Learn to take a breath and stay calm when others find flaws and react in unbecoming ways. This requires patience.

Sixth: When walking through these concepts with someone who is struggling with what they have found: stop, smile, and share Eliot’s quote.

Then, explore the dialogue that opens this post. This requires willingness.

Finally: Teach these lessons forward.

Of course, there are limits that, from time to time, you will confront in managing this dynamic. The Tyranny of Competence comes to mind. The best way to address this, should you need to, is through compassion, and not through anger, remembering that we all have our flaws. This will give you the best shot at addressing difficult interpersonal situations before someone simply has to go.

I think many workplaces understand the need to manage differences; what differentiates the best ones is the way they manage the flaws we discover in one another. There will be failures. There will be break-ups. Even George Martin’s work couldn’t keep the Beatles together. But a great team’s finest work comes only with significant attention to managing their reactions to one another’s flaws, however ugly they may be.

Discuss this specific post on Twitter or LinkedIn.

🎹 Music for this post: https://www.youtube.com/watch?v=H5ArpRWcGe0.

[Logo]
Categories
Current Events: 2022

Crypto + Time < Crypto

It seems that every day, we are getting better reporting and research to illustrate the fragile houses of cards we know as blockchain and Bitcoin. I’ve enjoyed tracking and sharing some of the choicest tidbits as postscripts to my first article on the subject.

I am troubled by the confidence that many people have in these technologies. Here’s what I tell those people:

Cryptocurrency is everything money professionals don’t understand about money combined with everything computer professionals don’t understand about computers.

This week’s most revealing academic work, which was nicely summarized in the The New York Times, highlighted the ‘decentralization theater’ that underpins Bitcoin. It is a must-read if you wish to stay on top of the latest in the ongoing dialog. What it also highlights, in its final paragraph, is something that we mustn’t lose sight of, and which I have attempted to summarize in my pithy headline for this post: what is encrypted today is not likely to stay encrypted tomorrow. Have a taste for what the authors were able to achieve from their research, and then understand that we are not too far away from quantum cryptography that brings us even closer to all of the details of the Bitcoin blockchain, and you begin to see how much “bunk” we are all being served.

You might like to take comfort in the fact that NIST is working on Post-Quantum Cryptography, but what does that portend for the contents of today’s blockchains? Some people project that we will move our crypto assets to newer technologies, but the remnants of today’s transactions will remain ripe tomorrow’s analysis. Even technology providers like IronCore Labs, who offer solutions in “crypto agility” (which, on the surface, sounds like a very good thing) will tell you that “That data is public and copies of it exist around the world. There’s no way to protect that data if an algorithm is broken or weakened, and that data will still be there twenty years from now. The future of blockchain in a post-quantum world is concerning.”

All of which is to say that, as a career CTO & CIO, I find that so much of our time is spent in the role of goalie to help deter the pucks being thrown at our organizations and their employees. It’s a tiring role because the situations we are protecting our organizations from are so much more complex than they used to be. Anecdotally, it is the minority of software and IT professionals who truly understand the holes in what’s going on right now; many are just as susceptible to the rhetoric behind the technologies as the neophyte on the street. All of this is ultimately demoralizing, because our time would be vastly better-spent — in almost all cases I can think of — on strategic things.

Goalies unite! The best tool in our arsenal is a public discourse to support one another as we fend off the bad information on a journey toward the good. Share these articles we find (as this site does so well), and continue to be critical of the bunk being hurled at us every single day.

James Reimer

Discuss this specific post on Twitter or LinkedIn.

🎹 Music for this post: https://www.youtube.com/watch?v=KnbQFVxiSmk.

[Logo]