I subscribe to Mike Cohn’s newsletter and I received a post on January 20th, 2022 entitled—
7 Reasons Teams Underestimate Work.
It was quite short but sweet and valuable. I’m sharing his list of seven factors below.
Overconfidence
Lack of clarity about the feature
Estimating a best-case scenario
Multi-tasking is not considered
They aren’t including time to iterate
Not all work is included
Assuming they’ll be more productive than is realistic
And it inspired me to think of other reasons, not directly related to the team, that might cause the team to underestimate.
Not that long ago I encountered a company that was fully invested in Empowered Product Teams (EPT’s). You know, the work that Marty Cagan and SVPG have been evangelizing, training, and consulting on. It’s essentially the culmination of the work that Marty shared in his Empowered book.
Full disclosure, I’ve not studied Marty’s work in excruciating detail. I’ve read it and I largely agree with his perspectives on modern-day product development team dynamics that lead to success. However, I’m not SVPG trained nor an expert in the approaches.
But that being said, the company I ran into illustrated a problem with EPT’s that I want to share so that others might reconsider the model and effectively implement it in the real world.
So, what did the company do? They—
John Kotter wrote a Harvard Business Review piece in 1995, over 25 years ago, entitled Leading Change: Why Transformation Efforts Fail. In it, he listed eight failure patterns or errors that often undermine organizational change and transformation efforts.
Now, at the time, agile ways of working were in their infancy and this was ~5-years before the writing of the Agile Manifesto. But when I came across it again, the article made me reflect on how many of these errors are still relevant and active today?
Error #1: Not Establishing a Great Enough Sense of Urgency
Error #2: Not Creating a Powerful Enough Guiding Coalition
Error #3: Lacking a Vision
Error #4: Under-communicating the Vision by a Factor of Ten
Error #5: Not Removing Obstacles to the New Vision
Error #6: Not Systemically Planning for and Creating Short-Term Wins
Error #7: Declaring Victory Too Soon
Error #8: Not Anchoring Changes in the Corporation’s Culture
If you’ve followed my writing, you know that I’m enamored with the wisdom often shared by John Cutler. Well, it’s happened again…
I found the following post on LinkedIn where John shared his thoughts around reframing retrospectives to be more positive. And that resonated deeply with my thoughts of late around the place for
In agile contexts.
I thought it was an interesting exercise to color-code them according to the following:
A few years ago, I promised myself that I wouldn’t write about (vent, rebut, defame, complain, rebuke, or otherwise whine about) SAFe any longer. It just frustrated me, made me an angry old curmudgeon, and significantly raised my blood pressure. And I realized that I needed to focus on more “positive” things in the agile community.
But dammit, it’s happened to me again. I’ve been SAFe’d…
Late last year I attended a meeting where a SAFe agilist and Fellow, presented a talk on finding purpose in SAFe. I’ll refer to them as Sam.
First Impressions
I don’t believe I’d met Sam before or at least not that I remembered. Sam seemed to be well-intentioned and principled. Sam was clearly a very smart and polished SAFe supporter and evangelist. And Sam also had a strong Kanban background and the lean side of that shined through the presentation.
I don’t want this to be interpreted as an opinion of Sam as a person. Instead, it’s an opinion (again) of SAFe and Sam representing SAFe as a Fellow.
Someone in my network sent me the following question the other day:
One question that's been surprisingly hard to answer is "Where did the concept of a long-lived team (vs a team that adjourns after a project is complete) first surface?"
And it started me to thinking about the notion.
Today, we talk a lot about moving from a Project focus to a Product focus, that is from:
Teams are formed and then disbanded or reorganized around the dimensions of a specific project. When the project is done, the team is done.
To
Teams are formed around a product area (or function) or around a functions area (infrastructure, architecture, etc.). The teams in this case are longer-lived in that there are no artificial closures based on their work.
Clearly, the latter strategy aligns better with the notion of a self-directed, cross-functional, high-performance agile team. But to the questioner’s point, when did that surface as an intentional focus, or even a directive or thing, in the agile community?
My friend & colleague Michael McCalla posted the following advice on LinkedIn:
Am I oversimplifying?
Whenever organizations come to us inquiring about Enterprise (or Business) Agility adoption, here is our advice:
1. Start with a thin horizontal slice across different units of an organization in which people collaborate to deliver value. Call it a value stream if you want:)
2. Engage each layer (Individual Contributors, Teams, Middle Management, and Senior Leadership) for all impacted parties and involve them in the change. Call this a vertical slice if you like:)
I read this article from Roman Pichler that took the perspective of a Product Owner working with an underperforming development team and trying to turn things around. While it’s a good article, it inspired me to look at other reasons that a team might not be performing well. Things outside of the team.
So, instead of the Product Owner looking at and trying to improve the team, what if they changed their focus to underperforming influences that surround the team?
I received this question from my friend Christopher Lee—
I have an existential and abstract question for you. How do we stop line managers from adopting micromanaging behaviors as it relates to artificial deadlines? Can deadlines co-exist with Agile? If so, how can line managers trust their people to make good decisions and execute those decisions autonomously? Is there an organization that exists with this ideal culture that I describe? Thanks.
Can deadlines coexist with “agile”?
I certainly think so. I think deadlines, milestones, delivery dates, etc. are a fundamental part of the real world. I think the key focus points for agile contexts include—
What is it about technology that inspires so much silver bullet syndrome? Or people jumping on bandwagons, hoping to get an easy fix or solution?
In 2014, I wrote a blog post about Bandwagon’s. At the time, I was venting a bit about how folks were modeling themselves after companies in the agile space. And that continues to this day. But another long-term trend is jumping on bandwagon’s related to frameworks.
Scaling frameworks seem to be one of the largest culprits in our space, but there are many others. Let’s explore some of the biggest silver bullets—
