Agile is not agile

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.

4 thoughts on “Agile is not agile

  1. (Fr)agile has been an incredible irritant – because it’s masquerading as the RealThing and gives an actual Agile process a bad name. I just took the Scrum Master training because I’m supposed to (it was very interesting and I can see the benefits of it in many circumstances), but I agree that forcing the process to fit a tool is a bad way to do things. I’ve done DSDM PM training as well as other Agile training and worked on implementing agile practices as much as possible inside of otherwise non-agile teams just because it uplifts morale to have a little bit of control and freedom of your own direction.

    I overcome the specific situation you mentioned by forcing the first 5 minutes to deal with status stuff (I get the notes I need), and then I leave the call open for whomever and whatever they need to talk about and I ensure that the team knows that they are free to leave at that point, or to stick around to discuss what needs to be discussed. It generally works well for my team. Also, since I’m still a techie and wear multiple hats (haha – pun not originally intended) I need those long chats as much as anyone else – plus I don’t pretend that I know how everything really ought to be.

    However, any tradition that is merely there for tradition’s sake needs to die a quick death. If it no longer serves a purpose, dump that tradition like a F/OSS enthusiast dumps proprietary software.

  2. Good approach. I think that a good practitioner could make it work. I just think that a place that is strictly Agile is likely to have many non-agile practitioners. It would definitely be a red flag for me in the future.

    And don’t get me started on Jira….

  3. I have just been through an full agile project for the first time and it was really big team. Only one scrum master who didn’t function fully as it is defined in the methodology but once we had the rhythm it worked pretty well. A scrum master is described as a servant leader. Their job is to help and not hinder communication and remove any blocks. I got certified a few years ago and still haven’t had the opportunity to be the scrum master, but it sounds like your experience was really bad. I would like to go through it again and apply to infrastructure.

  4. I’m sure it can work. But it’s neither necessary nor sufficient to be formally Agile. If it works, it is due to the maturity of the team. Not the formalism of the process.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.