I was on a plane recently, and ended up sitting next to a CEO of a medium-sized company. He was deep in the email-responding zone for most of the flight, but finally took a break to have a drink. He was obviously a seasoned leader; I immediately had that “this person can build alignment and inspire people” vibe. We chatted, mentioned “what we did”, and quickly the conversation turned to “product” and “Agile”.
What I was immediately struck by was how many pieces were missing in terms of his understanding of modern product development. Again, we are talking a very smart, passionate, and grounded executive here, who is extremely dedicated to the success of his team/company.
His first area of confusion was, unsuprisingly, Agile. Apparently they had “gone Agile” (using a consulting firm), and by “they” he meant his team of developers, their managers, and their manager’s managers. I gathered no change in how efforts were funded, their approach to product, or their approach to design. I sensed that this was how it had been sold to him — a silver bullet change in their approach to software development that would remedy “being slow” and “not being able to pivot to get important things done”. Here was a well-meaning CEO doing his job acting on incomplete information. What’s not to like? Faster. Agile! At Scale!
Four things stood out as missing (not just in his understanding, but in the understanding of his engineering leaders):
Teams having a direct connection with the external user/customer
Truly cross-functional teams (including designers, marketing, data science etc. not just developers) owning a product…not an Agile “build” phase in a predominantly waterfall process. Products not projects. Starting together. Working together.
Product management as part of the team…not external to the team passing requirements to a product owner.
The depth of design involvement in problem/solution exploration, and facilitating the team in its approach to design (#2 extended) Stepping back, however, he did get some of it! And good parts too…
Self-organizing teams reducing risk through frequent integration
The idea of “inspect and adapt” and continuous improvement
Some sense that the role of management changes (but lacking specifics) (Many of these things pre-date Agile, but that is beyond the scope of this post)
I have no doubt that someone internal was trying to explain how what they had done was “not enough”, but my guess is that they lacked a shared vocabulary. Additionally, I know (because he told me) that there was animosity between “the developers” and what existed in terms of design and product at the company. Design was being told that they had to “change to adapt to the new way of doing things” but were not actively consulted to mold and “design” the process. Product was considered “old school”. I’m guessing the same held true for testers and Ops team(s), but I didn’t verify this.
My point here is that even with the best intentions, it is very easy to simply graft on your existing mental models to some new way. In this CEO’s case, he very much cared about empowering his teams. That showed…he really cared. But his understanding of how that manifests in product development was weak. Same with his engineering leadership. They’re goal was to somehow “form an agreement” (his words) with the business to be more proactive and more….Agile!
None of these things — Agile, “product thinking”, design thinking, DevOps, LeanUX, etc. — mean anything without doing it or at least observing it first hand. And no successful team I know of is drawing exclusively from one tradition. That’s not convenient for those selling X as the be all, end all, but its true. All of these labels have been to some degree coopted to sell things, but that’s just how it goes.
Advice? If you’re considering some kind of shift/change, make a point to really get out there and sit with teams doing the work in a cross-section of organizations. Go deep. Hear stories. Go beyond what consultant X or Y says (or what your friend says). Figure out what is actually happening.
