Based on previous experiences, I would be hard pressed to join a team that has Scrum masters.

I expect that my previous experience was extreme, but not outside expectations for an organization that felt the need to officially embrace Agile(tm) and the concept of agile practitioners as part of the development process. It has been a bit over a year, and my frustration at the process has had a bit of time to settle, but I still feel my virtual hackles rise up when I think about the process.

A little history; I was at Fort Point Partners, a consulting firm, during dot.com bubble one-point-oh. While there, I learned about, and became fascinated with, the concept of eXtreme Programming (XP…not eXperience Points for the D&Ders our there). There were several concepts that directly contradicted the approach we took as a fixed-cost/fixed-scope bidding organization. Gone was the hundred page design documents. Instead, we would perform small iterations with constant feed back, and I loved the idea. I never quite figured out how to marry that concept with our business model, but it didn’t matter because the bubble burst and I ended up at a small firm with a much smaller team and the lee-way to make my own mistakes.

In eXtreme Programming, all software is written by pairs of programmers. While I love the idea, it did not work in practice. Certain people could not pair, including one of my start coders. Leave him alone, he’d produce a masterpiece. If I paired with him, he’d shut down. So, I learned to modify the practices into what worked for my team.

Test driven development has been the most important XP practice during the following years of my career. When writing code, I have easily written 3-4 times as much test code as I have production code. The volumes of code in Keystone/test show just how heavy the emphasis was during the OpenStack development process. And, with copious Tests, we could safely refactor code.

This is agile. This is the software development process at its heart: teamwork, testing, refactoring, iterative development.

If you are a scrum master, and you do not understand this, you are going to be a liability, probably a fatal one, to the project. What happened on my last team was that we had one programmer writing most of the code (not me) who was safely tucked away in a different time zone. We had 2-3 people coming up to speed, and we had 3 agile-practitioners and a program manager and a team manager. This was extreme, and very much not eXtreme Programming.

Each morning we’d have our scrum. When it came my term to talk, I would be told to take any technical conversations to one-on-one meetings after the scrum was over.

It. Still. Makes. Me.Mad.

Why? Why was this little custom such an irritant? Lets start with the obvious: I am a ham, and I like to perform, and want to be out in front. Being cut off is jarring. This is directly opposite to how I am wired to operate. But I know this. I am very aware at how this tendency has worked against me in the past. I self edit ruthlessly (maybe not enough for my co-workers, sorry about that) and I try to keep my parts focused on the problem at hand.

The real issue was that we were all remote, and this was the one time we got the team together. And we were a SMALL TEAM! If you remove all of the overhead, there were 3-4 programmers. When we were told to stop talking technical, I would ask why? Because we don’t want to waste the time of everyone in the meeting.

They should not have been there. There was no need for anyone but the technical people to be in our daily meeting. We were all very experience programmers, capable of self regulating.

No, more than capable. We were used to getting code written, projects completed, and products out the door. We were professionals. We knew what we were doing, and we could work with each other to make the team perform.

The scrum masters were all just scrum masters. They did not understand the business problems we were trying to solve, did not understand QA processes and they certainly were not able to understand the requirements of a build system for the Linux kernel and distribution for real-time operations. And they outnumbered the coders. I started thinking of them as political officers.

Who were these people? In general, they seemed to be project managers in education. I remember thinking back then that someone had, “sold them a bill of goods.” As such, I did not really fault them for trying to do their job. I did fault the organizational leadership that had told them that this was an acceptable way to do their job, and that had embraced this approach in the first place. However, it should have become apparent to them fairly quickly that this was an unhealthy approach. Why would you stay in a job like this? My understanding was that it is hard to leave a bad job that pays good money while it is easy to rationalize away the problems. The fundamental problem was that multiple someone’s were being deceived.

Ritual serves to comfort, but it is format for format’s sake. The actions taken may reflect original purpose, but they do not affect the desired changes. A quick standup meeting of the technical team each morning is a great way to prime the pump for a long technical process, especially when everyone is remote. I f one person is making the meeting go to long, the team members can appeal to a team leader to rein m—er that person in. This is easy stuff. It is normal group development. It is unavoidable.

If you are leading a development process, you should be able to do the job of everyone on that process. Now, in technical fields, sometimes you have a giant that is the only person that really knows that stuff, but they tend to end up leaders anyway. But you should be able to code it anyway. The same is true for QA, SQL, or any other technical aspect of code building. If you can’t, please don’t expect to “lead” me. You might influence me, but it might not t be in the direction you desire.