Weekend Reading – 2/25/2018

Weekend Reading is way for me to share what’s influencing my thinking.

The John Cutler Section

John had a number of pieces out this week, but I only want to focus on one: Scaling Traps - Where Intuition Leads us Astray. This is another article he’s done for the GitPrime Blog, and if you aren’t following this, please do. Right out of the gate it hits very close to home, discussing “an organization that is struggling with limiting work in progress.” I have a feeling that this is the majority of organizations. If you’re in a position to hire people for your team(s), you really need to read this. As usual, John isn’t prescriptive with a solution, but there are a lot of good questions to ask yourself, and hopefully by finding those answers you’ll also help find a solution to your scaling problem.


Teaching Your Team How to Troubleshoot Tension, also from the GitPrime Blog, is a fantastic little piece reminding us that team tension is not always healthy, nor does it magically produce better results. It gives us a nice reminder that decisions have to be made, but they don’t have to be made in a destructive way, even when people disagree. Speaking of Disagree and commit, there’s a Wikipedia page for that.

I know I said I only wanted to focus on one Cutler article, but that’s for that that section. John wrote two articles that tie into this problem of tension. The first, and shorter of the two, is Yes, But… , which is really about trying to remind you to put yourself on the other side of the equation to see if you can envision how things got to where they are without ascribing malice or incompetence. The longer article, Look Before Leaping, is a example-laden message to know what the situation/culture is that you’re trying to change before you try and change it. Pretty standard advice in any org takeover, but it’s always nice to have case studies and not just a bullet point on a list.


What if you created cross functional teams around user experiences instead of “products” or layers of the technology stack? In Calibrating Technical Teams with a Simple Shift, we find out what that looks like. Oddly enough, what drives success? “A shared purpose, and facilitating communication.” Shocker, right?

Since I’ve already blown the “just one Cutler piece” idea, check out both WIP It Real Good and So That Prioritization Spreadsheet…. You can never gaze into the void long enough to solve Work In Progress/Promise and the infinite priority problem. But at least in these you’ll get good questions to ask yourself.

Thanks for reading! See you next week.

Weekend Reading 2/16/2018

Weekend Reading is way for me to share what’s influencing my thinking.

The John Cutler Section

Pretending you’re in control even when you aren’t is a recipe not only for mistakes, but for not learning from mistakes. What’s appropriate when you’re learning is small steps, constant monitoring, and a willingness to change course as you find out more about where it’s leading.

This is a bit from a linked shared by John Cutler on Twitter. It’s a prevalent and recurring theme. It’s also one I think is easy to misinterpret. One could counter that the idea that we don’t really know what we’re doing is too scary to contemplate, so we should reject the idea entirely. How can you be responsible for an outcome if you don’t know what you’re doing, if you don’t know the exact moves to make to generate a specific outcome?

And yet we have a system like the stock market, where people don’t know the future, they don’t know with the utmost of certainly what bets to make and that’s okay. Somehow the idea that learning and improvement are critical to generating outcomes gets lost on people.

Which brings us to a new article from John over at the Git Prime blog, What ‘Fast’ Actually Looks Like. It’s another piece in his long running attempt to convince us all that being busy isn’t the same as being fast, because what you really want to happen at a fast pace is valuable, smart work, not just work for the sake of work. At the end of the article, sorry…spoiler alert, John asks us a simple question: Would you be willing to go slower and build less, if it led to superior business results?

Well…would you? Luckily, he also posted on Hackernoon this week, WIP It Real Good, on ways to help teams make the right ‘fast’ happen, or at least less bad ‘fast’. WIP is for Work In Progress, and when you keep indiscriminately adding work to a back log, this is the psychological cement shoes dragging a team down.


I worked in higher education IT for quite a while and one of the most surprising moments in my ten years was hearing from a director in my organization that our teams had high trust levels. I knew this to be completely false because I often acted as a pass-through between departments because of the extreme mistrust. But just like the first step to getting out of a hole is to stop digging, the first step in breaking the Cycles of Mistrust is to admit you have a problem.

One piece I’ve had trouble linking to, for lack of a good way to write about it, is In praise of SWARMing. What’s SWARM? Scaling Without A Religious Methodology. Agile, which started as a bold and open manifesto has been turned in a giant revenue generating dogmatic complex that gives you processes and check boxes and if you’d only just generate the right artifacts it will start working for you and by the way here’s our invoice for this month. So, if you can’t just Easy Button™ a framework, what are you supposed to do?

There are a handful of ingredients without which you are unlikely to achieve lasting change. They are by no means a formula for success. Rather, you should consider the absence of one or more of these a danger sign, a significant risk to be managed and mitigated.

It’s really just like the Dread Pirate Roberts said, “Life is pain, Highness! Anybody who says differently is selling something.” In other words, it’s hard work, it’s worth it, keep doing the right things.


Value-Driven Digital Business, over at the ThoughtWorks blog reminds us that customers have to be the focus. It’s not a new article, it’s from almost a year ago, but it takes a very thoughtful approach to counter many of the knee-jerk reactions you can get when trying to move an organization to thinking of the customer before the business. I will have to give them two demerits for using the phrase “Wikipedia defines…”, which is a silly pet peeve of mine.

Why Enterprise Agile Teams Fail is another list, with a business pitch at the end, but is still full of nuggets that reinforce the kind of thinking that has been shown to have superior results. You need to communicate the vision, constantly. You need to acknowledge unplanned work every week. You need to give the team time to focus and get important things done by limiting WIP (remember Work in Progress from up above…yeah, this again.) It’s a nice reminder to re-read John Cutler’s Why Isn’t Agile Working? post.

Weekend Reading is also available via a newsletter subscription.

Weekend Reading – 2/11/2018

The John Cutler Section

In a shocking turn of events, John had no written articles this week. He did post a video, Tetris, Queues, Dependencies, and Flow of Value on Vimeo. It’s not a “you have this problem and here’s the solution” kind of thing, it’s more of a “I’m going to make you think about what’s going on and only warn you of some potential pitfalls” thing. John wrote about Tetris style planning in Stop Playing Tetris (With Teams, Sprints, Projects, and Individuals). He also make a case for regular refactoring / debt workdown. with a nice graphic posted to Twitter.


I’m not sure if Frank Chimero’s Everything Easy is Hard Again essay is lighting the internet on fire, but it really did resonate with me as a former web developer. Sure, it can read like an Old Man Yells at Cloud rant, but we continually see this pattern in (and outside of) technology. We are still in an era where web development technologies is rapidly innovating. Everything is changing faster than any one person could possibly keep up with. To do anything meaningful you need a team of people that have specialized in a number of areas…that is if you want to roll your own. The number of services that can provide you with really fantastic web sites is mind boggling. But I feel you, Frank, it’s crazy out there but the only constant is change.


Full utilization and whitespace by Manuel Gomes builds on the ask to stop playing Tetris with your planning. Why is planning Tetris an anti-pattern for software? “Software is an uncertain medium.” You don’t remove waste from software development in exactly the same ways when you’re producing physical widgets. We have to keep repeating this to ourselves.

So, if Tetris is an anti-pattern, what’s a good pattern? Everybody reporting success is talking about “small” teams with as few dependencies as possible. Joshua Kerievsky, a leader in the Modern Agile community, wrote on LinkedIn about this in the article Size Teams for Few To No Handoffs. I really like this article because it reminds you not to just copy something from Amazon (the infamous two pizza team thing), but to look at what you have to work with and make the best decisions for your teams. Guidelines, not rules.

Do you want to keep digging into the how and why of these kinds of teams? Great! Your Team is Smarter Than You Are: Why Autonomous Product Teams Work Better from Martin Eriksson is a great read.

Now a lot of people hear autonomy and think of chaos or anarchy. They think that it means everyone can do whatever they want, build whatever they want, and come and go as they please.

But the key to successful autonomous product teams is to do it with accountability.

How do you do accountability? You can use Objectives and Key Results (OKRs), but it turns out that’s hard as well, as Jeff Gothelf writes about in You suck at OKRs.. The good news is that Jeff and friends have some advice for not sucking at OKRs.


Sign up at Tinyletter to get these words delivered to your email address of choice!

Weekend Reading – 2/4/2018

Please hang in there with me as I experiment on the format of Weekend Reading. A little quip after a link in a bulleted list just isn’t enough, so I’ll try and actually say something of value to go along with the source material that’s clearly influencing my thinking.

The John Cutler Section

There probably won’t be a week that goes by that I won’t link to at least one piece of work from John. So, get used to it. I know I have.

We start with a piece at Hackernoon, Start Together. Finish Together, and it’s a quick take down of what I like to think of as the infinite backlog. With few exceptions, you’ll always work in a place where the ideas will always outpace the ability to execute on these ideas. This leads right us smack dab into prioritization strategies (which we’ll get to in a bit) and generally making a few people happy and a lot of people grumpy since their ideas didn’t get “done”.

It’s bad to overload your backlog with this kind of work (In the Getting Things Done framework, this would be the “someday maybe” items) because while it sits in the backlog your business will change, your customers will change, and how you think about the idea/problem will change. If somebody picks up a piece of work six months later, how likely is it that it’s still relevant (hint: not very likely).

Instead, as John suggests, we need to make sure we all understand what we’re working, why we’re working on it, what will the outcomes be, and how will we measure them.

John also posted another piece with a headline that is dangerously close to click bait, We Need Fewer Product Managers. The real message that I took away, and it’s something I’ve been trying to make clear in my own organization, is that your org chart box title doesn’t map 1:1 to a role you play on a cross-functional product team. He has some good words of warning about making your product organization structure too rigid. We would all be wise to heed these words.

Finally, over at Git Prime we have We Are What We Celebrate. There are five great points about what and how we celebrate, but I want to make sure I put emphasis on celebrating leaning. Agile is all about continuous improvement and acting on your learnings is how you do that. So let’s celebrate it.

Oh, one last thing, he did episode 1 of the new Product Warrior podcast.

Sense & Respond: The Farm Awakens

I was fortunate enough to attend a workshop that Jeff and Josh helped lead and I can’t recommend them highly enough. You get this one for free as they did a keynote talk at mind the Product conference.

  1. You are in the software business
  2. Software unlocks new business models
  3. Software enforces policy
  4. Culture trumps (little ’t’) policy
  5. Feedback loops reveal culture
  6. Frame success in user-centric terms

The Other Links

Recent Books