Some thoughts on Agile/Scrum…

I’ve just ended a project where I was working in an Agile/Scrum based environment, with sprints, stories, and deadlines. I kinda liked it, because you collaborate closely with your colleagues, and you pick your own tasks. Things can move potentially very fast, but there are some very glaring downsides. I’ll list them below:

The burndown.

The holy and sacred burndown. People care way too much about getting a Sprint completely burned down. It sometimes makes Agile feel more like a panic room, than a flexible way of working. Especially when you have to wait for third parties. Other squads can really shit in your cereal by letting you wait days for a request to be fulfilled and things get blocked.

Yes, you should make your best effort to finish your burndown, but it really isn’t the end of the world if you don’t make it.

 

Refinements and retrospectives

Basically meetings without an agenda.

I thought I would have fewer meetings with an Agile workflow, but you get interrupted by refinements and retrospectives. It’s understandable that people want as many eyeballs as possible to refine something, but for crying out loud, let people work uninterrupted!

Many a time I sat a refinement, wondering what the hell I was doing there except for filling up a chair. Where I worked, the entire squad would be expected to sit in, while just a couple of people that are working in the problem domain would have sufficed.

And then there are the Agile coaches. They sit in on some of the standups, refinements and the retrospectives, but I wonder if that’s absolutely useful. Yes, they give some input on agile workflow and sometimes play moderator. But they don’t really contribute to the product. I don’t have anything against Agile coaches personally, but I would consider them overhead, akin to project managers.

Standups

I specifically left out the standup in the former part, because, well, that’s the only ‘meeting’ that I personally need. Basically just outline the stories you are working on, what is blocking you and what you will pick up next. That’s it. Also, frequently standups take too long because some people treat it like a full-blown goddamn meeting. Yeah, I get standing up is healthy, but the whole point of standing up is to add a physical constraint to ensure meetings don’t take too long.

Next Agile project I work at I will just introduce a damn egg timer. You get three minutes. That’s it.

Access, or the lack thereof.

Granted, this is not really related to Agile workflow, but it is a source of impediments. Yes, I get security is important. Yes, there must be due diligence and least access, but ideally, it shouldn’t get in the way of your work and be as transparent as possible.

The last project I worked at, they had a monstrosity of an Excel spreadsheet to outline all the rights and access a user or application has. It was a nightmare. Typical old-world holdover. Such information you should pull from the systems or from an automatically updated single point of truth (SPOT) that reflects reality in real time. It saves a lot of time and hassle. You can just look up what someone/something can do and limit/grant accordingly.

The other way around is also possible (and I’ve been in such an environment). Just give everyone full access, even on production. Let people own their mistakes and security incidents (you break it, you figure out how to fix it and who can help you, no blame shifting), implement strict code review (e.g. Gerrit), and pentest the crap out of everything. Funnily enough, it worked fine. People were careful, but mistakes weren’t punished. The environment was fluid enough to just redeploy a known working state and to sequester broken things for post mortem.

Conclusion

Agile is an interesting way of working, but it becomes awful when there are too many rigid processes attached (think of ITSM/ITIL or Prince2) and if people are too set in their ways. The whole point of Agile is to try lots of new things in rapid succession and to fail/learn a lot so you have a fast turnaround. You don’t want many extra things attached. Sure, include parts of ITIL that make sense (Incident/Problem tickets, continuous improvement, the Deming cycle), but don’t try to bolt on Agile onto something rigid. It won’t work well.

The whole point of Agile is to try lots of new things in rapid succession and to fail/learn a lot so you have a fast turnaround. You don’t want many extra things attached. Sure, include parts of ITIL that make sense (Incident/Problem tickets, continuous improvement, the Deming cycle), but don’t introduce Agile into your company as an afterthought. It won’t work well.

If you want to do Agile well, reorganize everything to facilitate it, don’t try to fit Agile in afterward. It’s like trying forcing a square peg into a round hole. It can be done through force, but it won’t be pretty, or useful.

Full disclosure or GTFO

I also posted this on my LinkedIn, but just to have some coverage I have posted it here as well.

I have a pet peeve. When recruiters/headhunters try to pitch me for a position at a certain client, they are always so skimpy with information. It is always generic terms like “a client” or “a big player in <some industry>” and some vague and incomplete description of the typical work involved, and usually some namedropping of some big clients. This does not entice me at all. In fact, I really wonder how this trend of withholding information came about. You are pitching me, so provide me with information. I will not tell other recruiters, honest. Not giving me all the information tells me that you don’t trust me, and that is no way to start a relationship if you ask me.

Here’s a worthwhile tip for you headhunters and recruiters out there. Provide full disclosure. If you want to really show that you are serious about trying to entice me to leave my current position for another one, you will have to provide at least the following information:

  • Who are you trying to recruit for? No vague statements. Name company names. I know how to Google, you don’t have to provide a complete bio for a company. I might know of them already, and otherwise, I will look them up.
  • What is the work? Tell me what they have and what they want. What would your client need me for? Give me specifics.
  • For how long? What is the initial time frame that they need extra FTEs for? Is there a possibility for a fixed contract? Again, specifics
  • What’s in it for me? What is the salary bracket you are recruiting for? What are the fringe benefits? How about insurances, compensations and the like?

Yes, I will treat all information I receive with the utmost confidentiality. I have worked with NDAs my whole career, so I know how to keep a lid on something. Instead of trying to entice me with summary information, just come out with it. When it comes to prospective new jobs, I don’t like surprises.

I hope this helps the recruiters and headhunters amongst you in finding valuable new people for your clients. The engineers you are trying to recruit will thank you for your candour.

PS: If you are worried that I (or someone else) will go to your client directly, well, I won’t. You are the guy with the “in” and the lead, so I will respect that. I won’t speak for someone else, but that is again dependent on something called “trust”. Most people will reward it, like yours truly. I am certainly not alone.

PPS: If you do send me mail, those 20-line signature blocks filled with disclaimers and whatnot are not doing you any favours. They are legally untenable, and not enforceable. So why bother.

Pushy recruiters

Yes, I do put myself out there. I have profiles on networking sites like branded.me, LinkedIn and probably some others. Usually, the recruiters and headhunters there behave themselves and don’t pester me that much. They send me messages through LinkedIn or whatever, but lately some of them have become REALLY pushy. Pushy insofar that they somehow found my personal mail address and are now reminding me through my personal mailbox to respond to some job I don’t want.

Let me give you some advice. Don’t do it. My profile states CLEARLY that I am already happy with my current job and that I AM NOT LOOKING FOR ANOTHER ONE (unless you have a solid offer). Second, the recruiter in question is not being open about who she is recruiting for. I wrote an entire article about it here (which I might repost here for safe keeping): “Full disclosure or GTFO“. Read that. It’s one of my major pet peeves about the whole recruiting/headhunting thing. If you are recruiting for your client, name your goddamn client. Fuck the secrecy. Transparency for the win.

Oh, am I using foul language? I warned you about that in my profile, too.

Work

I have to pay the bills to be able to pursue what I like, so I work. Preferably I like to work at a place where I actually like working. This is taken from my LinkedIn profile, it’s there too. But it can’ t hurt to post it here as well.

Imagine, for a moment, that you could create your own job with ideal conditions for you to work in. What would it be? This question I get asked sometimes during job interviews. My answer is usually the same, but I thought it would be worthwhile to share this and expound on it a bit. This way I could also elaborate on why this would be ideal for me, and hopefully, some enterprising person has this exact job for me (unlikely, but I like to be surprised).

I will start with soundbite-like sentences and I will elaborate on these. First, a little background on myself and how I like to work. First of all, I am a creative and curious person, and this has been the greatest contributing factor in myself being quite a generalist when it comes to skills. When someone asks me if I know anything about a certain thing (be it operating systems, technology, products, protocol, APIs, frameworks or what have you) I haven’t encountered before, I usually respond with “not yet”. If it tickles a certain fancy, I will dive into it in my free time. This also makes my work seem chaotic, but there is a certain method to my madness. When I have to come from an unknown angle, the work takes longer, but I will learn a lot in the process. This enriches my tool chest of tricks I can later employ. Needless to say, I have built up quite a war chest of knowledge that way in my career.

So, what would my ideal work environment look like? Well, the job itself would be a combination of system administration, engineering, slacking and playing with new technology (preferably open source). Inspiration was gleaned from the things I liked when I worked at several companies. More after the jump.

Continue reading “Work”