My Job is hard, Yours is easy
I really enjoyed Agile 2010 this year. My workshop, “Feeding the Agile Beast”, and presentation, “Using Lean and Agile to Lead Business Transformation”, were both well received. We found good interest in the Agile Extension to the BABOK. ICAgile was a topic of conversation and for the most part we found an appetite for a solid certification model. I also got to spend time with people I consider to be in my tribes. Just to name a few – note: if I fail to mention someone it is not intentional, just tweet me and I will add you to the appropriate clan(s)
- The Agile Project Manager clan: Mike Cottmeyer, Pat Reed, Michelle Sliger, Brian Bozzuto, including ICAgile visionary Alistair Cockburn
- The Kanban clan: Karl Scotland, Chris Shinkle, Eric Willeke, Mike Cottmeyer, and Brandon Carlson
- The Enterprise Agile clan: Alan Shalloway, Dean Leffingwell, Jim Highsmith, Portia Tung and Mike Cottmeyer
- The Agile Business Analysis clan: Pascal van Cauwenberghe, Shane Hastie, Kevin Brennan, Steve Adoph, Ellen Gottesdiener, and Mary Gorman
- The Agile Testing / Quality Assurance clan: Liz Hendrickson and Lisa Crispin
While some of these people, like myself, may have come from coding backgrounds, none of these people are primarily heads down technical resources. All of these people have spent years – some of us decades – improving our craft. All of these people bring deep experience, passion and knowledge to an area that is deeply necessary to deliver Agile projects to organizations.
It isn’t just about code
I was rankled by comments that came out at the end of the conference from people that I deeply respect that there wasn’t enough technical content at the conference. It wasn’t so much the comments as the context that they were delivered in. The troubling perspective was encapsulated in a post that said, “too much of the content was not technical. It was simple content that could be easily understood and digested.” I have tremendous respect for developers. I used be one – and I was pretty good. But about 15 years ago or so I realized that I could create more value in organization’s by removing the organizational constraints that create difficult environments for developers.
When you get beyond pretty small organizations, just writing code is not enough. In fact, without the capabilities practiced by my Agile Project Management, Kanban, Enterprise Agile, Agile Business Analysis, and Agile Testing clans, you can’t deliver value to customers. And the craft of being great at these in organizations is just as challenging, evolving, and important as any line of code anyone ever wrote.
Excuse me, but are you kidding me
Does anyone really think that the work of these clans is easily understood and digested? Getting organization’s to focus on strategy, then translate the strategy into work that can be developed, then coordinate that development across functions, then ensuring that what is needed is what is delivered, and then implementing the changes necessary to ensure the business receives value is not easily understood and digested. As a matter of fact, I think it is at least as interesting and difficult a problem as writing good code. And I think in the context of leveraging Agile software development in organization’s it is just as valuable and not as well understood.
My Job is Hard, Yours is Easy
A common bias in organization’s is the fundamental attribution error. This is also known as the self-serving bias. This manifests itself when people attribute different circumstances to their experience than they do to the experience of others. I see this all the time when coaching organization’s. People devalue the contribution of others and overvalue their contribution. This attitude leads to bunkering down in silo’s, organizational conflict, and obstacles to improvement and flow of value.
I have written code in an organization. It is hard. But I have also been responsible for business analysis, project and program management, quality assurance, process improvements, training, organizational design, and change management aspects of projects. All of these are important, all of them are hard. Delivering value for the business requires cadence and flow among these disciplines. As you are making assessments of how simple and easily digestible non-technical content is remember this tendency. Just saying, “My job is hard, and yours is easy”, doesn’t make this assertion true. And it results in value destroying behavior.
Tags: Agile, Agile Business Analysis, Agile Project Management, Agile Quality Assurance, Enterprise Agile, Systems Thinking
I do believe that “My Work is most Difficult” attitude hampers the organization structure. My personal experience is we tester are look down upon by the developers. But we know our value in the organization.