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.