At a Product Owner Community of Practice event a few months ago I had a very interesting conversation with some great folks. We were discussing the topic of testing on an Agile team. During the discussion, someone mentioned a recent coder comment along the lines of, “I was hired as a developer, not a tester.”
Hell, I’ve heard this comment numerous times in my career! Agilists are crying. The DevOps folks are considering a jump! Call the police! Heresy!
I pointed out that as an “evil” Scrum master I would want to comment to this “developer” that, “what I am hearing is that you are a programmer, not a developer.” Now, we shouldn’t let our own emotions drive our behavior in this way so I wouldn’t recommend saying this to anyone. There are constructive ways to address bad philosophy and behavior in the system. Moving on from the shock and awe…
An attendee named Bob said, “Yes, we need to move away from acting like a ‘mob of programmers’ to behaving like a ‘community of software engineers.'” Wow! I was blown away by his observation. There is a ton to dissect in the expression! Now, this is not meant to disparage mob programming. Mob programming does not mean “MOB thinking” with regard to systems development.
As “Agilists” we teach the concepts of Extreme Programming (XP) amoung other bodies of knowledge/concepts. In XP, the concept of “shared or collective ownership” is perhaps one of hte most powerful aspects of what Agile could potentially deliver to an organization. We’ve all experienced the negative effects of silos or locked down domains within an organization that result in more grenade throwing than excellence in product development. I imagine the mentality of the “developer” that made that comment was trained through his or her experience with traditional waterfall systems development process and control based leadership. You know the story, “I completed the coding it’s not my problem that it doesn’t work in the solution because it worked on my desktop machine.”
The Crazy
If one were to step back, it seems crazy that this type of attitude could exist in a creative knowledge worker? Where are the pride and craftsmanship? The nature of every great coder that I have ever known/experienced was one where he or she would never submit code that wasn’t thoroughly tested at the unit and system levels, at a minimum. Great coders understand Systems Thinking.
The Crash
I say “crash” because that is the best way to describe the train wreck the code will cause that is coded in a vacuum. Frequent integration or not, where there is complexity we should always err on the side of increased learning cycles. Organizational boundaries cause friction in the system too and when the problem of untested code is introduced across the interfaces between silos, a CRASH occurs.
Complex systems demand more than a programmer mindset. A collective mindset focused on improvement and Systems Thinking is necessary to build usable, valuable complex systems for the world.
blogagility.com 